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?

[prof7bit]

And my motor configuration for motor 4 seems to be ok also, for testing purposes I have temporarily remapped this motor along with the corresponding limit switch to axis Y and on this axis I can home it just fine, so my limit switch is working and connected, motor polarity and everything else seems ok for this motor.

And I am still on the edge branch btw.

This is because I have made my own branch based on edge with my own changes to be able to later merge updates from edge, I am not sure if I can just rebase this to edge-preview without breaking too many things here, so I am a bit hesitant towards switching branches now. I still hope it has a simple fix that can be applied to edge.

[prof7bit]

It is always moving with maximum feedrate 4000, even when I use G1

g1 u100 f100
g2core[mm] ok> 
Line number:         0
X position:          0.000 mm
Y position:          0.000 mm
Z position:          0.000 mm
A position:         12.490 mm
B position:          0.000 mm
C position:          0.000 mm
� position:          0.000 deg
 position:          0.000 deg
Feed rate:         100.000 mm/min
Velocity:         4000.000 mm/min
Units:               G21 - millimeter mode
Coordinate system:   G54 - coordinate system 1
Distance mode:       G90 - absolute distance mode
Arc Distance mode:   G91.1 - incremental distance mode (default mode)
Feed rate mode:      G94 - units-per-minute mode (i.e. feedrate mode)
Motion mode:         G1  - linear feed
Machine state:       Run
A position:         29.172 mm
A position:         45.854 mm
A position:         62.537 mm
A position:         79.219 mm
A position:         95.902 mm
Velocity:         3999.793 mm/min
A position:        100.000 mm
Velocity:            0.000 mm/min
Machine state:       Stop

So maybe the error is not in the homing code, there must be something broken elsewhere with this axis.

[justinclift]

@prof7bit I'll take a look at this in a bit. Need to get sleep first, so it'll be after that. 😄

[giseburt]

@prof7bit What branch are you on?

Edge has a few missing parts for the UVW to work. In particular, I believe this one is getting you:

g2/g2core/plan_line.cpp

Line 642 in 72e49fb

feed_time = sqrt(axis_square[AXIS_X] + axis_square[AXIS_Y] + axis_square[AXIS_Z]) / bf->gm.feed_rate;

Vs edge-preview where it's corrected:

g2/g2core/plan_line.cpp

Lines 563 to 567 in b3e0e9e

	#if (AXES == 9)
	feed_time = sqrt(axis_square[AXIS_X] + axis_square[AXIS_Y] + axis_square[AXIS_Z] + axis_square[AXIS_U] + axis_square[AXIS_V] + axis_square[AXIS_W]) / bf->gm.feed_rate;
	#else
	feed_time = sqrt(axis_square[AXIS_X] + axis_square[AXIS_Y] + axis_square[AXIS_Z]) / bf->gm.feed_rate;
	#endif

[prof7bit]

ok, the feed_time fix now makes it run with the correct velocity, it will accept the specified feedrate in G1, but it is still not working correctly. It is still freezing when trying to home the axis.

[prof7bit]

Can somebody please confirm that the edge-preview branch does indeed work with UVW-axes and these axes can be homed before I start porting my settings and all the stuff over to edge-preview?

[justinclift]

@prof7bit I've been working on getting my development system up to scratch. It's now connected up to a small 4-axis test bed, and hardware breakpointing (using edge-preview, though not on a Due) is technically functional. 😄

I still need to work through some issues before it's really "ok" to develop on though. 😦

Should be ok to look into the UVW axes sometime today or tomorrow, unless someone else is able to jump in earlier. 😄

[prof7bit]

I'm getting compile errors with the edge-preview branch:

$ make BOARD=gShield

...

In file included from ./settings.h:54:0,
                 from ./board/ArduinoDue/hardware.h:33,
                 from g2core.h:62,
                 from spindle.cpp:28:
./settings/settings_default.h:89:37: error: 'SPINDLE_ACTIVE_HIGH' was not declared in this scope
 #define SPINDLE_ENABLE_POLARITY     SPINDLE_ACTIVE_HIGH  // {spep: 0=active low, 1=active high
                                     ^
spindle.cpp:483:79: note: in expansion of macro 'SPINDLE_ENABLE_POLARITY'
     { "sp","spep", _iip, 0, sp_print_spep, sp_get_spep, sp_set_spep, nullptr, SPINDLE_ENABLE_POLARITY },
                                                                               ^~~~~~~~~~~~~~~~~~~~~~~
./settings/settings_default.h:89:37: note: suggested alternative: 'IO_ACTIVE_HIGH'
 #define SPINDLE_ENABLE_POLARITY     SPINDLE_ACTIVE_HIGH  // {spep: 0=active low, 1=active high
                                     ^
spindle.cpp:483:79: note: in expansion of macro 'SPINDLE_ENABLE_POLARITY'
     { "sp","spep", _iip, 0, sp_print_spep, sp_get_spep, sp_set_spep, nullptr, SPINDLE_ENABLE_POLARITY },
                                                                               ^~~~~~~~~~~~~~~~~~~~~~~
make: *** [../Motate/MotateProject/motate/Motate.mk:538: build/gShield/./spindle.o] Fehler 1

(will try to fix the missing defines manually for now)

[prof7bit]

getting even more errors about missing defines and defines that have been moved into other files after fixing this one, the preview branch does not seem to be meant for the arduino due board at this time yet.

Seems I really need a fix for the edge branch until edge-preview is ready to be used.

I suggest removing any mention of 9 axis and UVW from the wiki at this time.

[justinclift]

For the SPINDLE_ACTIVE_HIGH compilation error, the simple 1 line patch here should fix it: #483

Would you be ok to cut-n-paste here the follow on errors you're getting with it?

Hmmm, as a rough idea, maybe try grabbing the branch I've been doing stuff in here?

https://github.com/justinclift/g2/tree/justin-edge-preview-studiomill-v2

I'm using a different (non-Due) board though, so it might not be all that much better (not sure). 😇

[prof7bit]

edge-preview branch:

After fixing the spindle polarity I get this:

board/ArduinoDue/0_hardware.cpp:44:2: warning: #warning SPINDLE_ENABLE_OUTPUT_NUMBER is defaulted to 4! [-Wcpp]
 #warning SPINDLE_ENABLE_OUTPUT_NUMBER is defaulted to 4!
  ^~~~~~~
board/ArduinoDue/0_hardware.cpp:45:2: warning: #warning SPINDLE_ENABLE_OUTPUT_NUMBER should be defined in settings or a board file! [-Wcpp]
 #warning SPINDLE_ENABLE_OUTPUT_NUMBER should be defined in settings or a board file!
  ^~~~~~~
board/ArduinoDue/0_hardware.cpp:50:2: warning: #warning SPINDLE_DIRECTION_OUTPUT_NUMBER is defaulted to 5! [-Wcpp]
 #warning SPINDLE_DIRECTION_OUTPUT_NUMBER is defaulted to 5!
  ^~~~~~~
board/ArduinoDue/0_hardware.cpp:51:2: warning: #warning SPINDLE_DIRECTION_OUTPUT_NUMBER should be defined in settings or a board file! [-Wcpp]
 #warning SPINDLE_DIRECTION_OUTPUT_NUMBER should be defined in settings or a board file!
  ^~~~~~~
board/ArduinoDue/0_hardware.cpp:56:2: warning: #warning SPINDLE_PWM_NUMBER is defaulted to 6! [-Wcpp]
 #warning SPINDLE_PWM_NUMBER is defaulted to 6!
  ^~~~~~~
board/ArduinoDue/0_hardware.cpp:57:2: warning: #warning SPINDLE_PWM_NUMBER should be defined in settings or a board file! [-Wcpp]
 #warning SPINDLE_PWM_NUMBER should be defined in settings or a board file!
  ^~~~~~~
board/ArduinoDue/0_hardware.cpp:69:108: error: 'SPINDLE_SPEED_CHANGE_PER_MS' was not declared in this scope
 ESCSpindle esc_spindle {SPINDLE_PWM_NUMBER, SPINDLE_ENABLE_OUTPUT_NUMBER, SPINDLE_DIRECTION_OUTPUT_NUMBER, SPINDLE_SPEED_CHANGE_PER_MS};
                                                                                                            ^~~~~~~~~~~~~~~~~~~~~~~~~~~
board/ArduinoDue/0_hardware.cpp:69:108: note: suggested alternative: 'SPINDLE_SPEED_MAX'
 ESCSpindle esc_spindle {SPINDLE_PWM_NUMBER, SPINDLE_ENABLE_OUTPUT_NUMBER, SPINDLE_DIRECTION_OUTPUT_NUMBER, SPINDLE_SPEED_CHANGE_PER_MS};
                                                                                                            ^~~~~~~~~~~~~~~~~~~~~~~~~~~
                                                                                                            SPINDLE_SPEED_MAX
board/ArduinoDue/0_hardware.cpp:69:135: error: no matching function for call to 'ESCSpindle::ESCSpindle(<brace-enclosed initializer list>)'
 ESCSpindle esc_spindle {SPINDLE_PWM_NUMBER, SPINDLE_ENABLE_OUTPUT_NUMBER, SPINDLE_DIRECTION_OUTPUT_NUMBER, SPINDLE_SPEED_CHANGE_PER_MS};
                                                                                                                                       ^
In file included from board/ArduinoDue/0_hardware.cpp:68:0:
device/esc_spindle/esc_spindle.h:234:1: note: candidate: ESCSpindle::ESCSpindle(uint8_t, uint8_t, uint8_t, float)
 ESCSpindle::ESCSpindle(const uint8_t pwm_pin_number, const uint8_t enable_pin_number,
 ^~~~~~~~~~
device/esc_spindle/esc_spindle.h:234:1: note:   conversion of argument 4 would be ill-formed:
In file included from board/ArduinoDue/0_hardware.cpp:68:0:
device/esc_spindle/esc_spindle.h:52:7: note: candidate: ESCSpindle::ESCSpindle(const ESCSpindle&)
 class ESCSpindle : public ToolHead {
       ^~~~~~~~~~
device/esc_spindle/esc_spindle.h:52:7: note:   candidate expects 1 argument, 4 provided
device/esc_spindle/esc_spindle.h:52:7: note: candidate: ESCSpindle::ESCSpindle(ESCSpindle&&)
device/esc_spindle/esc_spindle.h:52:7: note:   candidate expects 1 argument, 4 provided
board/ArduinoDue/0_hardware.cpp: In function 'stat_t set_pulse_duration(nvObj_t*)':
board/ArduinoDue/0_hardware.cpp:243:5: error: 'laser_tool' was not declared in this scope
     laser_tool.set_pulse_duration_us(nv->valuetype == TYPE_FLOAT ? nv->value_flt : nv->value_int);
     ^~~~~~~~~~
board/ArduinoDue/0_hardware.cpp:243:5: note: suggested alternative: 'cm_get_tool'
     laser_tool.set_pulse_duration_us(nv->valuetype == TYPE_FLOAT ? nv->value_flt : nv->value_int);
     ^~~~~~~~~~
     cm_get_tool
board/ArduinoDue/0_hardware.cpp: In function 'stat_t get_pulse_duration(nvObj_t*)':
board/ArduinoDue/0_hardware.cpp:248:21: error: 'laser_tool' was not declared in this scope
     nv->value_int = laser_tool.get_pulse_duration_us();
                     ^~~~~~~~~~
board/ArduinoDue/0_hardware.cpp:248:21: note: suggested alternative: 'cm_get_tool'
     nv->value_int = laser_tool.get_pulse_duration_us();
                     ^~~~~~~~~~
                     cm_get_tool
board/ArduinoDue/0_hardware.cpp: In function 'stat_t get_min_s(nvObj_t*)':
board/ArduinoDue/0_hardware.cpp:254:21: error: 'laser_tool' was not declared in this scope
     nv->value_flt = laser_tool.get_min_s();
                     ^~~~~~~~~~
board/ArduinoDue/0_hardware.cpp:254:21: note: suggested alternative: 'cm_get_tool'
     nv->value_flt = laser_tool.get_min_s();
                     ^~~~~~~~~~
                     cm_get_tool
board/ArduinoDue/0_hardware.cpp: In function 'stat_t set_min_s(nvObj_t*)':
board/ArduinoDue/0_hardware.cpp:259:5: error: 'laser_tool' was not declared in this scope
     laser_tool.set_min_s(nv->value_flt);
     ^~~~~~~~~~
board/ArduinoDue/0_hardware.cpp:259:5: note: suggested alternative: 'cm_get_tool'
     laser_tool.set_min_s(nv->value_flt);
     ^~~~~~~~~~
     cm_get_tool
board/ArduinoDue/0_hardware.cpp: In function 'stat_t get_max_s(nvObj_t*)':
board/ArduinoDue/0_hardware.cpp:264:21: error: 'laser_tool' was not declared in this scope
     nv->value_flt = laser_tool.get_max_s();
                     ^~~~~~~~~~
board/ArduinoDue/0_hardware.cpp:264:21: note: suggested alternative: 'cm_get_tool'
     nv->value_flt = laser_tool.get_max_s();
                     ^~~~~~~~~~
                     cm_get_tool
board/ArduinoDue/0_hardware.cpp: In function 'stat_t set_max_s(nvObj_t*)':
board/ArduinoDue/0_hardware.cpp:269:5: error: 'laser_tool' was not declared in this scope
     laser_tool.set_max_s(nv->value_flt);
     ^~~~~~~~~~
board/ArduinoDue/0_hardware.cpp:269:5: note: suggested alternative: 'cm_get_tool'
     laser_tool.set_max_s(nv->value_flt);
     ^~~~~~~~~~
     cm_get_tool
board/ArduinoDue/0_hardware.cpp: In function 'stat_t get_min_ppm(nvObj_t*)':
board/ArduinoDue/0_hardware.cpp:274:21: error: 'laser_tool' was not declared in this scope
     nv->value_flt = laser_tool.get_min_ppm();
                     ^~~~~~~~~~
board/ArduinoDue/0_hardware.cpp:274:21: note: suggested alternative: 'cm_get_tool'
     nv->value_flt = laser_tool.get_min_ppm();
                     ^~~~~~~~~~
                     cm_get_tool
board/ArduinoDue/0_hardware.cpp: In function 'stat_t set_min_ppm(nvObj_t*)':
board/ArduinoDue/0_hardware.cpp:279:5: error: 'laser_tool' was not declared in this scope
     laser_tool.set_min_ppm(nv->value_flt);
     ^~~~~~~~~~
board/ArduinoDue/0_hardware.cpp:279:5: note: suggested alternative: 'cm_get_tool'
     laser_tool.set_min_ppm(nv->value_flt);
     ^~~~~~~~~~
     cm_get_tool
board/ArduinoDue/0_hardware.cpp: In function 'stat_t get_max_ppm(nvObj_t*)':
board/ArduinoDue/0_hardware.cpp:284:21: error: 'laser_tool' was not declared in this scope
     nv->value_flt = laser_tool.get_max_ppm();
                     ^~~~~~~~~~
board/ArduinoDue/0_hardware.cpp:284:21: note: suggested alternative: 'cm_get_tool'
     nv->value_flt = laser_tool.get_max_ppm();
                     ^~~~~~~~~~
                     cm_get_tool
board/ArduinoDue/0_hardware.cpp: In function 'stat_t set_max_ppm(nvObj_t*)':
board/ArduinoDue/0_hardware.cpp:289:5: error: 'laser_tool' was not declared in this scope
     laser_tool.set_max_ppm(nv->value_flt);
     ^~~~~~~~~~
board/ArduinoDue/0_hardware.cpp:289:5: note: suggested alternative: 'cm_get_tool'
     laser_tool.set_max_ppm(nv->value_flt);
     ^~~~~~~~~~
     cm_get_tool
board/ArduinoDue/0_hardware.cpp: At global scope:
board/ArduinoDue/0_hardware.cpp:294:95: error: 'LASER_PULSE_DURATION' was not declared in this scope
     { "th2","th2pd", _iip,  0, tx_print_nul, get_pulse_duration, set_pulse_duration, nullptr, LASER_PULSE_DURATION },
                                                                                               ^~~~~~~~~~~~~~~~~~~~
board/ArduinoDue/0_hardware.cpp:295:78: error: 'LASER_MIN_S' was not declared in this scope
     { "th2","th2mns", _fip,  0, tx_print_nul, get_min_s, set_min_s, nullptr, LASER_MIN_S },
                                                                              ^~~~~~~~~~~
board/ArduinoDue/0_hardware.cpp:296:78: error: 'LASER_MAX_S' was not declared in this scope
     { "th2","th2mxs", _fip,  0, tx_print_nul, get_max_s, set_max_s, nullptr, LASER_MAX_S },
                                                                              ^~~~~~~~~~~
board/ArduinoDue/0_hardware.cpp:296:78: note: suggested alternative: '__SHRT_MAX__'
     { "th2","th2mxs", _fip,  0, tx_print_nul, get_max_s, set_max_s, nullptr, LASER_MAX_S },
                                                                              ^~~~~~~~~~~
                                                                              __SHRT_MAX__
board/ArduinoDue/0_hardware.cpp:297:82: error: 'LASER_MIN_PPM' was not declared in this scope
     { "th2","th2mnp", _fip,  0, tx_print_nul, get_min_ppm, set_min_ppm, nullptr, LASER_MIN_PPM },
                                                                                  ^~~~~~~~~~~~~
board/ArduinoDue/0_hardware.cpp:298:82: error: 'LASER_MAX_PPM' was not declared in this scope
     { "th2","th2mxp", _fip,  0, tx_print_nul, get_max_ppm, set_max_ppm, nullptr, LASER_MAX_PPM },
                                                                                  ^~~~~~~~~~~~~
make: *** [../Motate/MotateProject/motate/Motate.mk:538: build/gShield/./board/ArduinoDue/0_hardware.o] Fehler 1

[prof7bit]

edge branch questions:

It is crashing or freezing when the limit switch is hit

• How/where is the limit switch evaluated during a move, where is this, is it an interrupt, is it polled?
• Can I instrument the code to output debugging info on the serial connection, which function would I need to call?
• Is there a document that outlines how the control flow is organized and architected, what is controlling what, which interrupts, which state machines, how do the different threads/interrupts communicate (queues? shared memory?), how the pulses are generated, etc?

[prof7bit]

edge-preview:

I have now applied the following quick hacks/changes to get rid of all compile errors and it compiles now:

diff --git a/g2core/board/ArduinoDue/0_hardware.cpp b/g2core/board/ArduinoDue/0_hardware.cpp
index a3443cba..6721c79d 100644
--- a/g2core/board/ArduinoDue/0_hardware.cpp
+++ b/g2core/board/ArduinoDue/0_hardware.cpp
@@ -236,7 +236,7 @@ stat_t hw_flash(nvObj_t *nv)
 constexpr cfgSubtableFromStaticArray sys_config_3{};
 const configSubtable * const getSysConfig_3() { return &sys_config_3; }
 
-#else
+#elif HAS_LASER
 
 stat_t set_pulse_duration(nvObj_t *nv)
 {
@@ -301,6 +301,11 @@ constexpr cfgItem_t sys_config_items_3[] = {
 constexpr cfgSubtableFromStaticArray sys_config_3{sys_config_items_3};
 const configSubtable * const getSysConfig_3() { return &sys_config_3; }
 
+#else
+
+constexpr cfgSubtableFromStaticArray sys_config_3{};
+const configSubtable * const getSysConfig_3() { return &sys_config_3; }
+
 #endif
 
 /***********************************************************************************
diff --git a/g2core/board/ArduinoDue/board_gpio.cpp b/g2core/board/ArduinoDue/board_gpio.cpp
index b43baca3..66dd5fb9 100644
--- a/g2core/board/ArduinoDue/board_gpio.cpp
+++ b/g2core/board/ArduinoDue/board_gpio.cpp
@@ -112,6 +112,7 @@ const int16_t ain_sample_freq = 2;
 int16_t ain_sample_counter = ain_sample_freq;
 Motate::SysTickEvent ain_tick_event{
     [] {
+        /*
         if (!--ain_sample_counter) {
             ai1.startSampling();
             ai2.startSampling();
@@ -124,6 +125,7 @@ Motate::SysTickEvent ain_tick_event{
 
             ain_sample_counter = ain_sample_freq;
         }
+        */
     },
     nullptr
 };
diff --git a/g2core/settings/settings_default.h b/g2core/settings/settings_default.h
index 013a3588..0ce901d1 100644
--- a/g2core/settings/settings_default.h
+++ b/g2core/settings/settings_default.h
@@ -86,7 +86,7 @@
 #endif
 
 #ifndef SPINDLE_ENABLE_POLARITY
-#define SPINDLE_ENABLE_POLARITY     SPINDLE_ACTIVE_HIGH  // {spep: 0=active low, 1=active high
+#define SPINDLE_ENABLE_POLARITY     1       // {spep: 0=active low, 1=active high
 #endif
 
 #ifndef SPINDLE_DIR_POLARITY
@@ -138,6 +138,10 @@
 #define COOLANT_MIST_POLARITY       1       // {comp: 0=active low, 1=active high
 #endif
 
+#ifndef SPINDLE_SPEED_CHANGE_PER_MS
+#define SPINDLE_SPEED_CHANGE_PER_MS 1
+#endif
+
 #ifndef COOLANT_FLOOD_POLARITY
 #define COOLANT_FLOOD_POLARITY      1       // {cofp: 0=active low, 1=active high
 #endif

I hope I did not break anything. Now I need some time to re-apply my settings (regarding the missing motors and get_next_axis function) to see whether this will work.

[justinclift]

Sounds like you're making solid progress. 😄

Sorry I haven't been able to help more yet. 😦

[prof7bit]

I have the edge-preview branch compiled and running with my own settings and the same bug is still there. When I try to home the U-axis it stops and freezes as soon as it hits the limit switch.

Here are the changes I made:

• applied the diff I posted in my previous post to make it compile for BOARD=gShield
• uncommented the 2 missing motors in board/ArduinoDue/board_stepper.cpp and .h and changed MOTORS to enable all 6 motors
• replaced the _get_next_axis() function with my version from above (here: Homing on U,V or W axis is not possible #482 (comment)) to enable homing on all axis
• applied my own settings (motor steps, speeds, axis and switch assignment)

Everything is behaving as before with the edge branch, including the messed up axis names on the console output:

g0 u 42
g2core[mm] ok> 
Line number:         0
X position:          0.000 mm
Y position:          0.000 mm
Z position:          0.000 mm
A position:         27.811 mm
B position:          0.000 mm
C position:          0.000 mm
▒ position:          0.000 deg
Feed rate:           0.000 mm/min
Velocity:        11184.437 mm/min
Units:               G21 - millimeter mode
Coordinate system:   G54 - coordinate system 1
Distance mode:       G90 - absolute distance mode
Arc Distance mode:   G91.1 - incremental distance mode (default mode)
Feed rate mode:      G94 - units-per-minute mode (i.e. feedrate mode)
Motion mode:         G0  - linear traverse
Machine state:       Run
A position:         42.000 mm
Velocity:            0.000 mm/min
Machine state:       Stop
$pos
X position:          0.000 mm
Y position:          0.000 mm
Z position:          0.000 mm
A position:         42.000 mm
B position:          0.000 mm
C position:          0.000 mm
� position:          0.000 deg
g2core[mm] ok> 

where it is reporting the U-axis as A and the A-axis position is not reported at all. (But this can be discussed in a separate bug report, iirc in json mode it was reporting the positions correctly, so this is not a priority right now, I am only using text mode currently while I am interacting with it manually in a serial terminal).

[justinclift]

iirc in json mode it was reporting the positions correctly

Oh, that's interesting. I was under the impression it shouldn't be possible for those to be different, but I guess this is another case of theory != reality. 😉

[prof7bit]

In json mode it is reporting all axes correctly. So this won't affect me later in my application, its only cosmetic while I am still using it in text mode:

$ej 1
{"r":{"ej":1},"f":[1,0,6]}
g0 a23 u42
{"r":{},"f":[1,0,11]}
{"sr":{"posu":21.76362,"posa":11.91817,"vel":13130.17,"momo":0,"stat":5}}
{"sr":{"posu":42,"posa":23,"vel":0,"stat":3}}
$pos
{"r":{"pos":{"x":0,"y":0,"z":0,"u":42,"v":0,"w":0,"a":23,"b":0,"c":0}},"f":[1,0,5]}
$ej 0
[ej]  enable json mode            0 [0=text,1=JSON,2=auto]
g2core[mm] ok> 
$pos
X position:          0.000 mm
Y position:          0.000 mm
Z position:          0.000 mm
A position:         42.000 mm
B position:          0.000 mm
C position:          0.000 mm
  position:          0.000 deg
� position:          0.000 deg
g2core[mm] ok> 

I'm going to make a different bug report for this later or tomorrow to not distract attention from the main problem.

[prof7bit]

Has anybody of you made any progress regarding the homing problem? I don't know enough about the architecture of this code to have the slightest idea where to even begin to look for the reason of the freeze, so I need your help!

[justinclift]

Ahhh, sorry. I have all the equipment needed here for doing stuff, but have been taking a few weeks out to have a bit of a break from most IT stuff in general. eg recover from burn-out 😦

[prof7bit]

So can we then conclude that g2core is abandoned and no longer actively developed? The wiki should mention it!

[prof7bit]

Has someone of you even reproduced this error or does it home the U axis on all your builds and I am the only one having problems with the U axis?

[prof7bit]

I have begun instrumenting the code to do some rudimentary printf debugging, I have calls like this rpt_exception(STAT_GENERIC_EXCEPTION_REPORT, "_homing_error_exit"); (is there a better way to debug print?) at the top of all functions in cycle_homing.cpp to see which functions get called in which order as the state machine progresses through its states and when I am homing the X axis (which is working fine) it will print this in the console:

g28.2 x0
g2core[mm] ok>
{"er":{"fb":101.03,"st":29,"msg":"Generic exception report - _homing_axis_start"}}
{"er":{"fb":101.03,"st":29,"msg":"Generic exception report - _get_next_axis"}}
{"er":{"fb":101.03,"st":29,"msg":"Generic exception report - _set_homing_func"}}
{"er":{"fb":101.03,"st":29,"msg":"Generic exception report - _homing_axis_clear_init"}}
{"er":{"fb":101.03,"st":29,"msg":"Generic exception report - _set_homing_func"}}
{"er":{"fb":101.03,"st":29,"msg":"Generic exception report - _homing_axis_search"}}
{"er":{"fb":101.03,"st":29,"msg":"Generic exception report - _homing_axis_move"}}
{"er":{"fb":101.03,"st":29,"msg":"Generic exception report - _set_homing_func"}}
{"er":{"fb":101.03,"st":29,"msg":"Generic exception report - mp_runtime_command"}}
{"er":{"fb":101.03,"st":29,"msg":"Generic exception report - mp_runtime_command"}}
{"er":{"fb":101.03,"st":29,"msg":"Generic exception report - _motion_end_callback"}}
{"er":{"fb":101.03,"st":29,"msg":"Generic exception report - _homing_axis_clear"}}
{"er":{"fb":101.03,"st":29,"msg":"Generic exception report - _homing_axis_move"}}
{"er":{"fb":101.03,"st":29,"msg":"Generic exception report - _set_homing_func"}}
X position:         -1.198 mm
Y position:          0.000 mm
Z position:          0.000 mm
A position:          0.000 mm
Input in10 state:     0
Input in11 state:     0
Input in12 state:     0
Machine state:       Homing
{"er":{"fb":101.03,"st":29,"msg":"Generic exception report - mp_runtime_command"}}
{"er":{"fb":101.03,"st":29,"msg":"Generic exception report - _motion_end_callback"}}
{"er":{"fb":101.03,"st":29,"msg":"Generic exception report - _homing_axis_latch"}}
{"er":{"fb":101.03,"st":29,"msg":"Generic exception report - _homing_axis_move"}}
{"er":{"fb":101.03,"st":29,"msg":"Generic exception report - _set_homing_func"}}
X position:          0.367 mm
X position:         -0.467 mm
X position:         -1.301 mm
{"er":{"fb":101.03,"st":29,"msg":"Generic exception report - mp_runtime_command"}}
{"er":{"fb":101.03,"st":29,"msg":"Generic exception report - _motion_end_callback"}}
{"er":{"fb":101.03,"st":29,"msg":"Generic exception report - _homing_axis_setpoint_backoff"}}
{"er":{"fb":101.03,"st":29,"msg":"Generic exception report - _homing_axis_move"}}
{"er":{"fb":101.03,"st":29,"msg":"Generic exception report - _set_homing_func"}}
X position:         -1.624 mm
{"er":{"fb":101.03,"st":29,"msg":"Generic exception report - mp_runtime_command"}}
{"er":{"fb":101.03,"st":29,"msg":"Generic exception report - _motion_end_callback"}}
{"er":{"fb":101.03,"st":29,"msg":"Generic exception report - _homing_axis_set_position"}}
{"er":{"fb":101.03,"st":29,"msg":"Generic exception report - _set_homing_func"}}
{"er":{"fb":101.03,"st":29,"msg":"Generic exception report - _homing_axis_start"}}
{"er":{"fb":101.03,"st":29,"msg":"Generic exception report - _get_next_axis"}}
{"er":{"fb":101.03,"st":29,"msg":"Generic exception report - _set_homing_func"}}
{"er":{"fb":101.03,"st":29,"msg":"Generic exception report - _homing_finalize_exit"}}
{"er":{"fb":101.03,"st":29,"msg":"Generic exception report - mp_runtime_command"}}
X position:          0.000 mm
Machine state:       Stop

But when I try to home the U axis it prints this:

g28.2 u0
g2core[mm] ok>
{"er":{"fb":101.03,"st":29,"msg":"Generic exception report - _homing_axis_start"}}
{"er":{"fb":101.03,"st":29,"msg":"Generic exception report - _get_next_axis"}}
{"er":{"fb":101.03,"st":29,"msg":"Generic exception report - _set_homing_func"}}
{"er":{"fb":101.03,"st":29,"msg":"Generic exception report - _homing_axis_clear_init"}}
{"er":{"fb":101.03,"st":29,"msg":"Generic exception report - _homing_axis_move"}}
{"er":{"fb":101.03,"st":29,"msg":"Generic exception report - _set_homing_func"}}
{"er":{"fb":101.03,"st":29,"msg":"Generic exception report - mp_runtime_command"}}
{"er":{"fb":101.03,"st":29,"msg":"Generic exception report - mp_runtime_command"}}
{"er":{"fb":101.03,"st":29,"msg":"Generic exception report - _motion_end_callback"}}
{"er":{"fb":101.03,"st":29,"msg":"Generic exception report - _homing_axis_search"}}
{"er":{"fb":101.03,"st":29,"msg":"Generic exception report - _homing_axis_move"}}
{"er":{"fb":101.03,"st":29,"msg":"Generic exception report - _set_homing_func"}}
A position:          3.731 mm
Machine state:       Homing
{"er":{"fb":101.03,"st":29,"msg":"Generic exception report - mp_runtime_command"}}
{"er":{"fb":101.03,"st":29,"msg":"Generic exception report - _motion_end_callback"}}
A position:          0.076 mm

When it hits the limit switch it correctly ends the move and calls _motion_end_callback() which in turn clears the waiting_for_motion_end flag but then it (what?) won't ever call into the state machine ever again.

Whatever is responsible for polling the state machine just stops. Where do I proceed from here? What is calling the state machine and how would I debug this, given that I cannot connect a debugger and am restricted to this kind of printf-debuging?

[prof7bit]

I have also inserted a rpt_exception at the beginning of cm_homing_cycle_callback(), this will flood my console with hundreds of lines (so I removed it again) but it clearly shows that the call to _motion_end_callback() is the very last call ever, after that it stops.

{"er":{"fb":101.03,"st":29,"msg":"Generic exception report - cm_homing_cycle_callback"}}
{"er":{"fb":101.03,"st":29,"msg":"Generic exception report - cm_homing_cycle_callback"}}
{"er":{"fb":101.03,"st":29,"msg":"Generic exception report - cm_homing_cycle_callback"}}
{"er":{"fb":101.03,"st":29,"msg":"Generic exception report - cm_homing_cycle_callback"}}
{"er":{"fb":101.03,"st":29,"msg":"Generic exception report - cm_homing_cycle_callback"}}
{"er":{"fb":101.03,"st":29,"msg":"Generic exception report - cm_homing_cycle_callback"}}
{"er":{"fb":101.03,"st":29,"msg":"Generic exception report - cm_homing_cycle_callback"}}
{"er":{"fb":101.03,"st":29,"msg":"Generic exception report - cm_homing_cycle_callback"}}
{"er":{"fb":101.03,"st":29,"msg":"Generic exception report - cm_homing_cycle_callback"}}
{"er":{"fb":101.03,"st":29,"msg":"Generic exception report - cm_homing_cycle_callback"}}
{"er":{"fb":101.03,"st":29,"msg":"Generic exception report - cm_homing_cycle_callback"}}
{"er":{"fb":101.03,"st":29,"msg":"Generic exception report - mp_runtime_command"}}
{"er":{"fb":101.03,"st":29,"msg":"Generic exception report - _motion_end_callback"}}
A position:          0.026 mm

The yellow LED is still slowly blinking.

The position report "A position: 0.076 mm" is also arriving after the call to _motion_end_callback() but I have no idea who is producing these outputs, whether this happens later the same interrupt or somewhere else.

How do I proceed from here?
Do any of these symptoms maybe ring a bell with someone? What might be happening?

[prof7bit]

I found the reason:

The attached patch will fix both: the probing and the homing problems for U,V,W,

Please merge.

diff --git a/g2core/cycle_probing.cpp b/g2core/cycle_probing.cpp
index 3f3db80f..f8ab9423 100644
--- a/g2core/cycle_probing.cpp
+++ b/g2core/cycle_probing.cpp
@@ -138,6 +138,7 @@ uint8_t cm_straight_probe(float target[], bool flags[], bool trip_sense, bool al
 
     // error if no axes specified
     if (!(flags[AXIS_X] | flags[AXIS_Y] | flags[AXIS_Z] |
+          flags[AXIS_U] | flags[AXIS_V] | flags[AXIS_W] |
           flags[AXIS_A] | flags[AXIS_B] | flags[AXIS_C])) {
         return(cm_alarm(STAT_AXIS_IS_MISSING, "Axis is missing"));
     }
diff --git a/g2core/util.cpp b/g2core/util.cpp
index 61f4c4b0..952bb0fe 100644
--- a/g2core/util.cpp
+++ b/g2core/util.cpp
@@ -76,6 +76,9 @@ float get_axis_vector_length(const float a[], const float b[])
     return (sqrt(square(a[AXIS_X] - b[AXIS_X]) +
                  square(a[AXIS_Y] - b[AXIS_Y]) +
                  square(a[AXIS_Z] - b[AXIS_Z]) +
+                 square(a[AXIS_U] - b[AXIS_U]) +
+                 square(a[AXIS_V] - b[AXIS_V]) +
+                 square(a[AXIS_W] - b[AXIS_W]) +
                  square(a[AXIS_A] - b[AXIS_A]) +
                  square(a[AXIS_B] - b[AXIS_B]) +
                  square(a[AXIS_C] - b[AXIS_C])));