G-code magic for advanced homing?

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?

dc42

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

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)

GCode meta commands are not yet supported by DSF, so for now on Duet 3 they only work in standalone mode. You need one of the RRF 3.01 release candidates to use them, but you are running 3.0. That's also why your m409 command doesn't work.

monster

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

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

Well, this is good question ofc
Answers rather "creative"

Let's say I powered printer up, pushed home button.
After that a print would like to re-home it before starting - that is reasonable.
Or I simply ordered heads to move and now want to re-park them

There might be few more ideas why but of course you may say that they are not very needed and can be worked around, that is true.
So I guess best answer I could give is - why not? :)))) Just for sake of exercise on printer control

monster

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

GCode meta commands are not yet supported by DSF, so for now on Duet 3 they only work in standalone mode. You need one of the RRF 3.01 release candidates to use them, but you are running 3.0. That's also why your m409 command doesn't work.

Is there a good way not to miss actual release?

dc42

Yes, go to https://github.com/dc42/RepRapFirmware and click on Watch.