Minor problem with access to object model after G1... commands

[hlwerschner]

I just switched to 3.50-rc1 from previous 3.46 release and followed needed changes in my macros (change to macro parameters...) until I again was able to start my 3d printer.

But some spurious abort in a few macros (home*.g, G32 ...) forced me to look closer into my code to isolate a new behaviour in the (MB6HC in SBC mode with a PI 3B):
In several macros a use of a G1 move command for any axe(s), followed by a M400 command to wait for the movement completion and directly follwed by an access to the object model variables to check for the recorded coordinates was not always OK. The code looks something like:

G1 H1 Z{var.totalZ} F300           ; slowly touch again
M400                               ; wait for command completion
var currentZ = move.axes[var.axis].machinePosition

In Rel 3.46 (and before) this code worked fine and "currentZ" did reliably hold the actual coordinate (assuming that no hardware error had happened).

In the new release, the use of M400 obviously does NOT suffice to allow a secure access to the correct synchronized values in the move.axes[*].machinePosition values!
A workaround was to add another "G4 P500" after the M400 command to wait for another 500msecs (a guess which worked) ... but this is akward and just a strange workaround.

My questions:
1/ is this behaviour of 3.50 something that is already known and worked on?
2/ is there a solid and secure solution to access the machinePosition programmatically AND RELY on the correct value?
3/ if there is not a ready-to-use solution, is it feasible to look/wait for another command line M400/G4 (or a variant of it with special parameter(s)) that allows to "wait for the objectmodel to be in sync"?

I expect that some of you do not see the need for a solution to this behaviour of the software but believe me, I discovered that most of my problems to achieve good printing results were solved when I assured that the power up, initialisation and CALIBRATION of my printer were done with checking all possible missbehaviour in start-up macros and hardware-wrong-use/processing until EVERYTHING was checked and running properly. I may be a bit overcautious with my macro coding and error handling but more than 45 years of software development have proven me that this is the only way to have software that has a looooong lifetime and works as required. As long as the object model provides an access within the macro coding and is not only a documentary help to clearify how the RRF may work, a reliable access to its values is mandatory (or at least an indicator/semaphore flag should show if the model is in sync with the board/hardware or when it is not). I do understand that the RRF software is a multitasing thing where the object model is somehow handled independently fromt kernel GCode processing, but this is nevertheless something that can be handled properly!

I hope for some positive feedback

[dc42]

@hlwerschner thanks for your report. Does the following also give you incorrect results:

G1 H1 Z{var.totalZ} F300           ; slowly touch again
M400                               ; wait for command completion
echo move.axes[var.axis].machinePosition,var.totalZ

i.e. does it sometimes echo two different values, assuming no tool Z offset or workplace coordinate offset?

[dc42]

@hlwerschner I confirm this is a problem. The Z axis machine position reported in the object model is out of date during a move that includes Z. It's also not updated to the final position until a short time after the move is completed. I will investigate it.

Edit: created https://github.com/Duet3D/RepRapFirmware/issues/921 and https://github.com/Duet3D/RepRapFirmware/issues/922.

dc42 created this issue in Duet3D/RepRapFirmware

closed Machine Z axis position report incorrect #921

dc42 created this issue in Duet3D/RepRapFirmware

closed Axis machine position is not reported live when using an expansion board #922