IF meta-command testing

hlwerschner

I currently have a DUET 2 WiFi with RepRap Firmware 3.1.1 installed and running nicely.
To add some "intelligence" to my home***.g scripts I started with homex.g :

G91                  ; relative positioning
if !move.axes[2].homed 
  G1 H2 Z5 F600        ; lift Z 5mm relative to current position
;
G1 H1 X-500 F1400   ; move quickly to X axis endstop and stop there (first pass)
G1 H2 X5 F1300       ; go back a few mm
G1 H1 X-15 F800      ; move slowly to X axis endstop once more (second pass)

G1 H2 Z-5 F600       ; lower Z again
;
G90                  ; absolute positioning
G92 X0

As far as I did understand the syntax, I have indented line 3 for the IF-true-block.

What happens is that the Z movement is never done, either if Z-coord == 0.0 or Z > 0 (perhaps 50). What is wrong with my syntax? Btw: axes are X:0, Y: 1, Z:2

Is it better to check for coord-values instead the "homed" state?

hlwerschner

...just to add after doing an M409 command:
a/ the machine status shows "triggered" for all 3 axes, the displayed coords are 0.0, but M409 K"move.axes" prints "...homed: false..." in all 3 cases.

Btw . in config.g I have defined all 3 endstops to be M574 X1 S1 P"!xstop" etc. I believe that the "homed state should be correct (i.e. "true") in this case also.

dc42

That looks OK to me. Are you definitely running firmware 3.1.1 ? Use M115 to check.

OwenD

Do you have
M564 S0 H0 ;allow movement before homing
Somewhere before the IF statement?

hlwerschner

Hi,
I did a snapshot of the version+ m564 state and afterwards, via webconsole, issued a "Home X" ---> G28 X. You can see 3 messages from the homex.g script (partial below):
![alt text]( image url)

this is the script with some debug echo commands:

.... dropped a few comments 
; CAUTION: the homed states are INVERTED because of M574 X1 S1 P"!xstop" in config.g (nonsense semantics) !!!
M119
echo "X: homed state = "^{move.axes[0].homed}^" , position = "^{move.axes[0].machinePosition}
if !move.axes[0].homed
  echo "X: already homed, set position to min : "^{move.axes[0].min}
  G92 X{move.axes[0].min}
else
  echo "X: set position to "^{move.axes[0].min+10}
  G92 X{move.axes[0].min+10}
if !move.axes[2].homed
  echo "Z: homed, set max position : "^{move.axes[2].max}
  G92 Z{move.axes[2].max}
;
G91                  ; relative positioning
if move.axes[2].machinePosition < move.axes[2].max
  echo "Z: retract"
  G1 H2 Z5 F600      ; lift Z 5mm relative to current position
;
if move.axes[0].machinePosition > move.axes[0].min
  echo "X: position > min, retract axis to min"
  G1 H1 X{-move.axes[0].max} F1400    ; move quickly to X axis endstop and stop there (first pass)
  G1 H2 X5 F1000       ; go back a few mm
  G1 H1 X-15 F800      ; move slowly to X axis endstop once more (second pass)
;
.... more lines follow for final moves etc

when you look at the first output line (from M119) you can verify that the X-endstop is activated. in config.g there is

M574 X1 S1 P"!xstop"
M574 Y1 S1 P"!ystop"
M574 Z2 S1 P"!zstop"

The 2nd output is from the echo command in line 4. The homed state given via "move.axes[0].homed" is "false" but (a) the endstop LED is ON, and (b) M119 also shows "at end-stop".

Btw: I may be wrong, but after moving the X-axis away from the endstop (LED is OFF) and doing the Home X command again, will show M119 correct but move.axes[0].homed stays "false".

What am I doing false here?

Just one additional question: After reset/powering up, the coord values are reset to min/0.00 regardless of their "real" state (including a check of endstops). Is there a flag/property to look at to interpret the positions as "unverified" instead of believing that X == 0.00 is really correct? With that information I may engance my scripts to differentiate between (1) endstop and position are consistent or (2) when !endstop then position is unknown. As long as the ***.homed state is not usable, I do not know how to avoid stepper crashing into min positions after powerup.

hlwerschner

@hlwerschner said in IF meta-command testing:

M574 X1 S1 P"!xstop"

I just did that 2nd test with the X-axis moved away from the endstop:
![alt text]( image url)

You see that the ***.homed stays at "false" whereas M119 correctly reports "not stopped".

fcwilt

@hlwerschner said in IF meta-command testing:

if !move.axes[0].homed
echo "X: already homed, set position to min : "^{move.axes[0].min}
G92 X{move.axes[0].min}
else
echo "X: set position to "^{move.axes[0].min+10}
G92 X{move.axes[0].min+10}

Hi,

What is it you are trying to do here?

As I under it the homed state being true simply means that at some point that axis has been homed.

Why would you set the current position to min or min+10?

Color me confused. Thanks.

Frederick

dc42

@fcwilt said in IF meta-command testing:

As I under the homed state being true simply means that at some point that axis has been homed.

Correct. It means that either the homing sequence for that axis has been run successfully, or G92 has been used to set the axis position. It has nothing to do with whether the endstop switch (if any) for that axis is triggered.

hlwerschner

@dc42: thank you for that clarification. I simply could not guess from that "homed" name that it is only some kind of a historical state kept from some time of controller activities. I have done some more tests with reduced homing scripts and power down/reset actions and got results which verified your statement. Together with the fact that machinePosition itself is also a value that might not be "in sync with the real stepper position", the OM and its use in scripts is (for my project use !) not useful. Perhaps a future version may consider to model the real world states (with event handling also) to allow to react to potentially harmful events on a machine. So far, I will fall back to trivial scripts and basci endstop handling.

Thank you again for your excellent work!!

hlwerschner

to all: I have to apologize for an unneccessary discusion caused by several missunderstandings from my side. I found that the information I was looking for is already in the OM. To access the current state of the endstops, I have to use "sensors.endstops[0..].triggered" and NOT "move.axes[0..].homed". I can only explain my wrong use from having seen a mentioning of the ***.homed property and no hint to the actual state property for endstops.

I changed my scripts for homing to shortcut the movements when the home position is already active and all axis now work nicely.

Thanky you all for your understanding and help!

A Former User

@hlwerschner said in IF meta-command testing:

I found that the information I was looking for is already in the OM.

for future reference if you state what you want to achieve instead of how, you might get some input you hadn't considered.

if you intend to skip homing if the endstop is already triggered then you could have some variable error as the motors could snap to different full step positions when energized, for x and y it will probably not not matter, it could matter for z and first layer adhesion.

hlwerschner

@bearer : hmm, taking your last sentence, is this a problem when I home the Z axis to the max-position (i.e. far away from the printing bed) and before print start, do some z-probe process to get the first layer levelling done independent of the homing?
To state it in the "what" format: When I do Z-axes Home, I want to move the Z-axes to the highest possible position relative to the printing bed for a "safest position". I do not want to use Z-axis homing to level down to the printing bed for some Z-coordinate = 0.0

A Former User

its not a problem if you probe the bed, or back off the switch and do a short G1 H1 move; its just a potential problem if you power on, detect the switch is triggered and apply G92 instead of homing.