object model not synchronized with command execution

hlwerschner

Yesterday I stepped into a confusing macro problem when I wanted to check for proper Z postion before doing a "G30..." command. I wrote something like ```
var startProbeZ = 5.0
var currentZ = move.axes[2].machinePosition ; this is my Z axis
if var.startProbeZ != var.currentZ
; M564 S0
G1 H0 {var.startProbeZ} F1000
; M564 S1
set var.currentZ = move.axes[2].machinePosition
echo "... moved print bed to Z = " ^ {var.currentZ}
if var.currentZ != var.startProbeZ
abort ">>> could not move to Z = " ^ {var.startProbeZ}

echo "OK, we are at Z = " ^ {var.currentZ} ```
but the macro when executed, always aborted and the reported machinePosition was not the correct Z position (when looking at the displayed dashboard coords).
I finally found out that I had to insert a M400 command IMMEDIATELY after the G1 (in this case) to produce some "wait for command completion" to make this macro working correctly.
In summary I think that there seem to be some (many ?) GCodes in the RepRap firmware that have mirrored values in the object model but there also seems to be some(?) timing gap - caused by "multitasked execution" perhaps - that causes the objectmodel to exhibit wrong values (at least for some time/milliseconds after gcode execution that could affect those values.
I can live with that knowledge and add some defensive M400 commands at relevant places in my macros but I would like to propose:
1/ it should be documented in commands which object model values may be affected (and how long it takes to be in sync again)
2/ Even better would be if the objectmodel uses some "dirty" flags to mark values which (may be)/are out of sync because of a gcode execution AND provides a re-sync command / BETTER does the re-sync automatically when an access to such values happens.
I have spent almost half a day to wonder why my code did not properly do what I wanted, therefore I think others should benefit from my experience.

chrishamm

@hlwerschner I am not sure why you are trying to use H0 there - you can really omit it because H0 is the default (see here). If you want to perform a homing move, use H1 instead. Homing moves always block as long as they're executed so you can expect userPosition or machinePosition to be up-to-date when it finishes. This isn't feasible for regular moves, though, so M400 is needed for them.

I'll update the object model docs of userPosition and machinePosition.

hlwerschner

@chrishamm yes, I did know about the H0, it was just while testing and trying to isolate the cause. I even tested with M564 Sx as I sometimes have a negative Z coord as starting position and wanted to react properly - as G1 then would not do anything at all. Adding comments to the docs is really welcome...what is with sensors (endstops) when G0/G1 are involved?
Nevertheless I a ma a great fan of the DUET + RepRap (currently at RRF 3.4) and appreciate the fantastic community!