G-code magic for advanced homing?

monster

Hi,

Is it bay any chance possible that homing script would be able to know if an axis was homed before?
Why I want it? Because if an axis was homed before and homing requested - then I can go quickly to X10 Y10 quick and then slowly move last one cm to until end switches trigger. If not homed before - then ofc slowly move in relative mode backward until end switch triggered.

For now if use same logic

G90               ; absolute positioning
G1 H1 X10 F1800
G91               ; relative positioning
G1 H1 X-290 F600  ; move slowly to X axis endstop once more (second pass)
G90               ; absolute positioning

works just fine when it was homed before. But if not it actually first moves 10mm away from end switches and then does -290 move, which in case heads were already on the edge of its max X makes terrible skipping drama noses.
And so I had to comment out "G1 H1 X10 F1800"

bot

I think you could simply tell the toolhead to go to the X10 Y10 position at the beginning of the homing script. If insufficient axes are homed, an error will be generated and it will be ignored (and I think the rest of the homing script will be completed). If sufficient axes are homed, you'll get the desired movement and then the rest of the homing script.

However, if a motor has lost position, the command to go to X10 Y10 could cause a crash.

littlehobbyshop

https://duet3d.dozuki.com/Wiki/GCode_Meta_Commands#Section_Examples_of_use

There is an example of homing at the bottom of the article, you'll probably only want the first few lines, this will tell you if the axes are already homed:

if !move.axes[0].homed || !move.axes[1].homed || !move.axes[2].homed

You will need firmware version 3.0.1 or later to run conditional gcode.

monster

Thank you both of you guys!

deckingman

@monster It looks like you are sorted but yet another alternative is to do a coarse homing move at high(ish) speed, back off a few mm , then do a second fine homing move at slow speed. So something like:

G91
G1 H1 X-290 F1800
G1 X10 F600
G1 H1 X-20 F600.

monster

@deckingman I actually seen that 2 pass homing technique, yes it is quick but feels not ideal What seems to be not ideal here is bounce back. I kinda see more enjoyable fast way forward with slowing down when close to expected home switch

monster

@monster said in G-code magic for advanced homing?:

@deckingman I actually seen that 2 pass homing technique, yes it is quick but feels not ideal What seems to be not ideal here is bounce back. I kinda see more enjoyable fast way forward with slowing down when close to expected home switch

Or actually!!! What I could do is if previous homing detected that it will be one way, else 2 pass technique

deckingman

@monster said in G-code magic for advanced homing?:

@monster said in G-code magic for advanced homing?:

@deckingman I actually seen that 2 pass homing technique, yes it is quick but feels not ideal What seems to be not ideal here is bounce back. I kinda see more enjoyable fast way forward with slowing down when close to expected home switch

Or actually!!! What I could do is if previous homing detected that it will be one way, else 2 pass technique

Yes, why not? Sounds like a plan to me..........

monster

@monster said in G-code magic for advanced homing?:

Or actually!!! What I could do is if previous homing detected that it will be one way, else 2 pass technique

Something doesn't seem as I'd expect...

; quickhomexy.g
G90
if move.axes[0].homed && move.axes[1].homed && move.axes[2].homed
	M98 P"quickhomexy_singlepass.g"
else
	M98 P"quickhomexy_doublepass.g"
G90                    ; absolute positioning

Strange both M98 P"quickhomexy_singlepass.g" and M98 P"quickhomexy_doublepass.g" get called.
If construction doesn't work for some reason.

bot

I'm not sure about in RRF 3, but in RRF 2, the moment you press home, the axis is flagged as unhomed (at least, it shows as such in DWC). Perhaps, the axes are all flagged as unhomed right before your conditional statement is called?

littlehobbyshop

@monster What version of DWC are you running?

It may be you have an older version of DWC. Initially when pressing tab it was putting in the wrong indentation. In that case you either need to update DWC and redo those indented lines with the tab key or replace those tabbed indents with 4x spaces.

monster

@littlehobbyshop
Version:
Board: Duet 3 MB6HC (MB6HC)
DSF Version: 1.2.4.0
Firmware: RepRapFirmware for Duet 3 MB6HC v0.6 or 1.0 3.0 (2020-01-03b3)

@bot
That axis gets unhomed I did figure out. That is sad.
But hey, how come both parts of IF are executed - that is quite a feature
I tested it now with messages (which aren't working correctly them-self) and with sounds. Seems like IF is out of scope
I guess what is left is what you said "tell the toolhead to go to the X10 Y10 position at the beginning of the homing script."
But then again once home requested it might be invalidated by unhoming all. I need to test it...

bot

@monster Ha! You're right, it might not be able to make any move whatsoever because of the unhomed flag.

littlehobbyshop

@monster did you try replacing those indents with 4 spaces?

monster

@bot hold on a sec! This part I already know! Basically if it homed before that my command in homing subroutine go to X10 Y10 works! So perhaps it is unhomed but still knows where is 10,10....
Bit weird though.

bot

@monster That is very interesting. So it moves to X10 Y10 if homed, and then continues with the script? But it omits the X10 Y10 movement if not homed?

Perhaps, as you say, it's not getting flagged as unhomed right away, and you need to indent the script as @littlehobbyshop says.

monster

@littlehobbyshop said in G-code magic for advanced homing?:

@monster did you try replacing those indents with 4 spaces?

Nope:

if !move.axes[0].homed || !move.axes[1].homed || !move.axes[2].homed
    M300 S300 P200 
else
    M300 S100 P200

This plays (via webui) S100 sound

if !move.axes[0].homed || !move.axes[1].homed || !move.axes[2].homed
    M300 S300 P200 
;else
;    M300 S100 P200

and this plays S300 sound

monster

@bot said in G-code magic for advanced homing?:

@monster That is very interesting. So it moves to X10 Y10 if homed, and then continues with the script? But it omits the X10 Y10 movement if not homed?

Perhaps, as you say, it's not getting flagged as unhomed right away, and you need to indent the script as @littlehobbyshop says.

Not exactly.
If homed before then it goes to 10,10 and then by relative moving goes to 0,0
if not homed then (i believe) it takes that X10 Y10 to move 10mm in opposite direction (away from end swithces) and then by relative moving still gets parked on 0,0

monster

@littlehobbyshop is there way to see a value of variable?
display it in message?
or much better would be to display it in log?
something like
"log move.axes[0].homed"
by anychance?

edited
found this https://duet3d.dozuki.com/Wiki/Gcode#Section_M409_Query_object_model
but

deckingman

@monster This does beg the question, if an axis is homed, why do you want to home it again? Or am I missing something?