Homing on U,V or W axis is not possible

[prof7bit]

Now after I have spent the whole day wiring up everything I ran across a show stopper bug :-(

I have x,y,z as usual, a rotary axis (a) and an additional linear axis (u).

They are mapped to the motors as follows:
m1 - x
m2 - y
m3 - z
m4 - u
m5 - a

All axes are configured and moving properly when moved with g0 or g1.

using the g28.2 command I can home all axes except the additional linear axis u (and also v and w won't work):

g28.2 u0
g2core[mm] ok> 
Homing error - Bad or no axis(es) specified
Machine state:       Stop

[justinclift]

Oh, that definitely sounds like a bug. That one shouldn't be too hard to fix though, and I've actually done stuff with the homing code before.

If you're ok to wait until tomorrow (I'm desperately in need of sleep atm), I should have had a chance to figure out and fix the problem.

[giseburt]

I know this bug. I'll handle it. I'll have to follow up with more info later.

[justinclift]

Ahhh. In that case, it's definitely yours. 😄

[prof7bit]

No need to lose sleep over it, I can't continue to work on my machine for the next seven days anyways, the most important thing is to know that it can be fixed, so I don't have to worry about my choice of motion controller.

I very much like the idea of being able to use g2core, its actually a perfect fit for my project, there are not many open source alternatives that offer such flexibility, I wonder why it is not massively more popular among the maker scene. With that many axes I can potentially control almost any machine I might ever happen to build in the future and once I have invested time in understanding its configuration and implementing the protocol on the PC side then I will certainly continue using it, even for smaller machines instead of grbl.

[giseburt]

Ok, so this will be fixed more accurately in a new version in edge-preview (it's mixed up with other homing changes where we support multi-motor on the same axis homing to square up an axis, but that's a longer discussion), so for now, here's where this issue exists:

g2/g2core/cycle_homing.cpp

Lines 442 to 581 in 72e49fb

	static int8_t _get_next_axis(int8_t axis) {
	#if (HOMING_AXES <= 4)
	if (axis == -1) { // inelegant brute force solution
	if (hm.axis_flags[AXIS_Z]) {
	return (AXIS_Z);
	}
	if (hm.axis_flags[AXIS_X]) {
	return (AXIS_X);
	}
	if (hm.axis_flags[AXIS_Y]) {
	return (AXIS_Y);
	}
	if (hm.axis_flags[AXIS_A]) {
	return (AXIS_A);
	}
	if (hm.axis_flags[AXIS_B]) {
	return (AXIS_B);
	}
	if (hm.axis_flags[AXIS_C]) {
	return (AXIS_C);
	}
	return (-2); // error
	} else if (axis == AXIS_Z) {
	if (hm.axis_flags[AXIS_X]) {
	return (AXIS_X);
	}
	if (hm.axis_flags[AXIS_Y]) {
	return (AXIS_Y);
	}
	if (hm.axis_flags[AXIS_A]) {
	return (AXIS_A);
	}
	if (hm.axis_flags[AXIS_B]) {
	return (AXIS_B);
	}
	if (hm.axis_flags[AXIS_C]) {
	return (AXIS_C);
	}
	} else if (axis == AXIS_X) {
	if (hm.axis_flags[AXIS_Y]) {
	return (AXIS_Y);
	}
	if (hm.axis_flags[AXIS_A]) {
	return (AXIS_A);
	}
	if (hm.axis_flags[AXIS_B]) {
	return (AXIS_B);
	}
	if (hm.axis_flags[AXIS_C]) {
	return (AXIS_C);
	}
	} else if (axis == AXIS_Y) {
	if (hm.axis_flags[AXIS_A]) {
	return (AXIS_A);
	}
	if (hm.axis_flags[AXIS_B]) {
	return (AXIS_B);
	}
	if (hm.axis_flags[AXIS_C]) {
	return (AXIS_C);
	}
	}
	return (-1); // done
	#else
	if (axis == -1) {
	if (hm.axis_flags[AXIS_Z]) {
	return (AXIS_Z);
	}
	if (hm.axis_flags[AXIS_X]) {
	return (AXIS_X);
	}
	if (hm.axis_flags[AXIS_Y]) {
	return (AXIS_Y);
	}
	if (hm.axis_flags[AXIS_A]) {
	return (AXIS_A);
	}
	if (hm.axis_flags[AXIS_B]) {
	return (AXIS_B);
	}
	if (hm.axis_flags[AXIS_C]) {
	return (AXIS_C);
	}
	return (-2); // error
	} else if (axis == AXIS_Z) {
	if (hm.axis_flags[AXIS_X]) {
	return (AXIS_X);
	}
	if (hm.axis_flags[AXIS_Y]) {
	return (AXIS_Y);
	}
	if (hm.axis_flags[AXIS_A]) {
	return (AXIS_A);
	}
	if (hm.axis_flags[AXIS_B]) {
	return (AXIS_B);
	}
	if (hm.axis_flags[AXIS_C]) {
	return (AXIS_C);
	}
	} else if (axis == AXIS_X) {
	if (hm.axis_flags[AXIS_Y]) {
	return (AXIS_Y);
	}
	if (hm.axis_flags[AXIS_A]) {
	return (AXIS_A);
	}
	if (hm.axis_flags[AXIS_B]) {
	return (AXIS_B);
	}
	if (hm.axis_flags[AXIS_C]) {
	return (AXIS_C);
	}
	} else if (axis == AXIS_Y) {
	if (hm.axis_flags[AXIS_A]) {
	return (AXIS_A);
	}
	if (hm.axis_flags[AXIS_B]) {
	return (AXIS_B);
	}
	if (hm.axis_flags[AXIS_C]) {
	return (AXIS_C);
	}
	} else if (axis == AXIS_A) {
	if (hm.axis_flags[AXIS_B]) {
	return (AXIS_B);
	}
	if (hm.axis_flags[AXIS_C]) {
	return (AXIS_C);
	}
	} else if (axis == AXIS_B) {
	if (hm.axis_flags[AXIS_C]) {
	return (AXIS_C);
	}
	}
	return (-1); // done
	#endif // (HOMING_AXES <= 4)
	}

It's not the most succinct code, but it's clear what it does, so there's that at least.

The HOMING_AXES part is defined here:

g2/g2core/g2core.h

Line 68 in c8223c5

#define HOMING_AXES 4 // number of axes that can be homed (assumes Zxyabc sequence)

It should be wrapped in an ifndef like (or with) AXES but currently it's not.

In any case, that if statement tree in cycle_homing should (but doesn't) have else if (axis == AXIS_Y) for axes A, B, and C, as well as U, V, and W (you may want to check for AXES == 9), then I believe it will work.

I don't know if anyone has tested homing U, V, and W, or at least they didn't report back AFAIK, so I'm excited to hear how it goes.

[giseburt]

I forgot to mention, the g2core.h ifdefs rely on the hardware overriding values. For example, in the board-specific hardware.h AXES is defined:

g2/g2core/board/ArduinoDue/hardware.h

Line 64 in 423c83f

#define AXES 6 // axes to support -- must be 6 or 9

That's also the file where MOTORS is defined, but you also have to define structures for each motor in board_stepper.h and board_stepper.cpp, for example:

g2/g2core/board/ArduinoDue/board_stepper.h

Lines 35 to 97 in 404106b

	extern StepDirStepper<Motate::kSocket1_StepPinNumber,
	Motate::kSocket1_DirPinNumber,
	Motate::kSocket1_EnablePinNumber,
	Motate::kSocket1_Microstep_0PinNumber,
	Motate::kSocket1_Microstep_1PinNumber,
	Motate::kSocket1_Microstep_2PinNumber,
	Motate::kSocket1_VrefPinNumber>
	motor_1;
	extern StepDirStepper<Motate::kSocket2_StepPinNumber,
	Motate::kSocket2_DirPinNumber,
	Motate::kSocket2_EnablePinNumber,
	Motate::kSocket2_Microstep_0PinNumber,
	Motate::kSocket2_Microstep_1PinNumber,
	Motate::kSocket2_Microstep_2PinNumber,
	Motate::kSocket2_VrefPinNumber>
	motor_2;
	extern StepDirStepper<Motate::kSocket3_StepPinNumber,
	Motate::kSocket3_DirPinNumber,
	Motate::kSocket3_EnablePinNumber,
	Motate::kSocket3_Microstep_0PinNumber,
	Motate::kSocket3_Microstep_1PinNumber,
	Motate::kSocket3_Microstep_2PinNumber,
	Motate::kSocket3_VrefPinNumber>
	motor_3;
	extern StepDirStepper<Motate::kSocket4_StepPinNumber,
	Motate::kSocket4_DirPinNumber,
	Motate::kSocket4_EnablePinNumber,
	Motate::kSocket4_Microstep_0PinNumber,
	Motate::kSocket4_Microstep_1PinNumber,
	Motate::kSocket4_Microstep_2PinNumber,
	Motate::kSocket4_VrefPinNumber>
	motor_4;
	// extern StepDirStepper<
	// Motate::kSocket5_StepPinNumber,
	// Motate::kSocket5_DirPinNumber,
	// Motate::kSocket5_EnablePinNumber,
	// Motate::kSocket5_Microstep_0PinNumber,
	// Motate::kSocket5_Microstep_1PinNumber,
	// Motate::kSocket5_Microstep_2PinNumber,
	// Motate::kSocket5_VrefPinNumber> motor_5;
	// extern StepDirStepper<
	// Motate::kSocket6_StepPinNumber,
	// Motate::kSocket6_DirPinNumber,
	// Motate::kSocket6_EnablePinNumber,
	// Motate::kSocket6_Microstep_0PinNumber,
	// Motate::kSocket6_Microstep_1PinNumber,
	// Motate::kSocket6_Microstep_2PinNumber,
	// Motate::kSocket6_VrefPinNumber> motor_6 {};
	#if HAS_LASER
	#include "laser_toolhead.h"
	#include "kinematics_cartesian.h"
	typedef LaserTool<BASE_KINEMATICS, LASER_FIRE_PIN_NUMBER> LaserTool_used_t;
	extern LaserTool_used_t &motor_5;
	#endif
	extern Stepper* const Motors[MOTORS];

and

g2/g2core/board/ArduinoDue/board_stepper.cpp

Lines 33 to 97 in 404106b

	StepDirStepper<Motate::kSocket1_StepPinNumber,
	Motate::kSocket1_DirPinNumber,
	Motate::kSocket1_EnablePinNumber,
	Motate::kSocket1_Microstep_0PinNumber,
	Motate::kSocket1_Microstep_1PinNumber,
	Motate::kSocket1_Microstep_2PinNumber,
	Motate::kSocket1_VrefPinNumber>
	motor_1{M1_STEP_POLARITY, M1_ENABLE_POLARITY};
	StepDirStepper<Motate::kSocket2_StepPinNumber,
	Motate::kSocket2_DirPinNumber,
	Motate::kSocket2_EnablePinNumber,
	Motate::kSocket2_Microstep_0PinNumber,
	Motate::kSocket2_Microstep_1PinNumber,
	Motate::kSocket2_Microstep_2PinNumber,
	Motate::kSocket2_VrefPinNumber>
	motor_2{M2_STEP_POLARITY, M2_ENABLE_POLARITY};
	StepDirStepper<Motate::kSocket3_StepPinNumber,
	Motate::kSocket3_DirPinNumber,
	Motate::kSocket3_EnablePinNumber,
	Motate::kSocket3_Microstep_0PinNumber,
	Motate::kSocket3_Microstep_1PinNumber,
	Motate::kSocket3_Microstep_2PinNumber,
	Motate::kSocket3_VrefPinNumber>
	motor_3{M3_STEP_POLARITY, M3_ENABLE_POLARITY};
	StepDirStepper<Motate::kSocket4_StepPinNumber,
	Motate::kSocket4_DirPinNumber,
	Motate::kSocket4_EnablePinNumber,
	Motate::kSocket4_Microstep_0PinNumber,
	Motate::kSocket4_Microstep_1PinNumber,
	Motate::kSocket4_Microstep_2PinNumber,
	Motate::kSocket4_VrefPinNumber>
	motor_4{M4_STEP_POLARITY, M4_ENABLE_POLARITY};
	// StepDirStepper<
	// Motate::kSocket5_StepPinNumber,
	// Motate::kSocket5_DirPinNumber,
	// Motate::kSocket5_EnablePinNumber,
	// Motate::kSocket5_Microstep_0PinNumber,
	// Motate::kSocket5_Microstep_1PinNumber,
	// Motate::kSocket5_Microstep_2PinNumber,
	// Motate::kSocket5_VrefPinNumber>
	// motor_5 {M5_STEP_POLARITY, M5_ENABLE_POLARITY};
	// StepDirStepper<
	// Motate::kSocket6_StepPinNumber,
	// Motate::kSocket6_DirPinNumber,
	// Motate::kSocket6_EnablePinNumber,
	// Motate::kSocket6_Microstep_0PinNumber,
	// Motate::kSocket6_Microstep_1PinNumber,
	// Motate::kSocket6_Microstep_2PinNumber,
	// Motate::kSocket6_VrefPinNumber>
	// motor_6 {M6_STEP_POLARITY, M6_ENABLE_POLARITY};
	#if HAS_LASER
	// laser_tool is defined over in hardware.cpp
	extern LaserTool_used_t laser_tool;
	LaserTool_used_t &motor_5 = laser_tool;
	Stepper* const Motors[MOTORS] = {&motor_1, &motor_2, &motor_3, &motor_4, &motor_5};
	#else
	Stepper* const Motors[MOTORS] = {&motor_1, &motor_2, &motor_3, &motor_4};
	#endif

[prof7bit]

How about rewriting the above function like this?

static int8_t _get_next_axis(int8_t axis) {
    const int8_t homing_order[9] = {AXIS_Z, AXIS_X, AXIS_Y, AXIS_U, AXIS_V, AXIS_W, AXIS_A, AXIS_B, AXIS_C};

    if (axis == -1) {
        // search the first axis in the order whose flag is set
        for (int i=0; i<9; i++) {
            if (hm.axis_flags[homing_order[i]]) {
                return homing_order[i];
            }
        }
        return -2; // no existing axis flag was set

    } else {
        // search the next axis in the order whose flag is set
        for (int i=0; i<9; i++) {
            if (axis == homing_order[i]) {
                for (int j=i+1; j<9; j++) {
                    if (hm.axis_flags[homing_order[j]]) {
                        return homing_order[j];
                    }
                }
                return -1; // no more axes, we are done
            }
        }
        return -1; // called with non-existing axis, should never happen (but compiler insists on some return value)
    }
}

I am currently testing it, it seems to work as before, but the U axis now makes a rapid g0 move if I try to home it, the error message is gone (very strange, must further check my axis and motor configurations, something seems wrong still)

[prof7bit]

It moves with U_FEEDRATE_MAX until it hits the limit switch, then the motor stops and the machine is frozen, homing sequence is stuck at this point and never ends, needs reset.

[justinclift]

Ouch. Sounds like that function might not be returning correctly. 😦

Hmmm, since you seem to be ok with C, do you have a hardware debugger handy? eg a Segger J-Link or similar

Asking because those are really helpful for debugging stuff like this. eg setting breakpoints in the firmware, stepping through functions, etc, to figure out what's wrong. We have things pretty well set up for people using MS Code + that Segger J-Link, if that's useful. 😄

[prof7bit]

The function above seems to return correctly, if I do for example g28.2 x0 z0 u0 it will correctly home z, then x, then start moving u (but with the wrong velocity) and then it is stuck.

I initially suspected a typo or copy-paste error where it is setting up the configuration arrays but it seems its internal structures know the configuration for this axis correctly:

$u
[uam] u axis mode                 1 [standard]
[uvm] u velocity maximum       4000 mm/min
[ufr] u feedrate maximum       4000 mm/min
[utn] u travel minimum            0.000 mm
[utm] u travel maximum          300.000 mm
[ujm] u jerk maximum           5000 mm/min^3 * 1 million
[ujh] u jerk homing           10000 mm/min^3 * 1 million
[uhi] u homing input              4 [input 1-N or 0 to disable homing this axis]
[uhd] u homing direction          0 [0=search-to-negative, 1=search-to-positive]
[usv] u search velocity         200 mm/min
[ulv] u latch velocity        20.00 mm/min
[ulb] u latch backoff             4.000 mm
[uzb] u zero backoff              2.000 mm
g2core[mm] ok> 

It should begin searching with 200mm/min but starts moving toward the limit switch with 4000mm/min, then stops and freezes.

I have a J-Link but no IDE that is set up for Atmel/Arduino and also not the connectors/adapters to plug it into the arduino, I am normally only working with chinese GD32 controllers and for these I have configured Eclipse with GNU-ARM-Plugin and J-Link. I have never used J-Link with vscode (although I am using vscode as my text editor for everything outside of eclipse)

But this problem should be reproducible for any of you who has already set up a working debug environment, even if you don't have 4 axis: Just map any of your existing motors to the U-Axis, configure its limit switch for U also and then try to home U.

[prof7bit]

This is the output (in text mode) when I am trying to home U

g28.2 u0
g2core[mm] ok> 
A position:        -13.737 mm
Feed rate:         200.000 mm/min
Velocity:         4000.000 mm/min
Coordinate system:   G53 - machine coordinate system
Distance mode:       G91 - incremental distance mode
Motion mode:         G1  - linear feed
Machine state:       Homing
A position:        -30.432 mm
A position:        -47.128 mm
A position:        -63.823 mm
A position:        -80.519 mm
A position:        -97.214 mm
A position:       -113.910 mm
A position:       -130.606 mm
A position:       -147.301 mm
A position:       -163.997 mm
A position:       -180.692 mm
A position:       -197.388 mm
A position:       -214.084 mm
A position:       -230.779 mm
A position:       -247.475 mm
A position:       -264.170 mm
A position:       -279.566 mm

Note that it is also reporting the positions with the wrong axis name. And it correctly says "Feedrate 200mm/min" but then accelerates to 4000mm/min

[justinclift]

@giseburt Do you have time to look into this in the near future, or should I have a go at it?