G-code magic for advanced homing?



  • 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"



  • 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.



  • 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.



  • Thank you both of you guys!



  • @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.



  • @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 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 😉



  • @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 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.



  • 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?



  • @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.



  • @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...



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



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



  • @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.



  • @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.



  • @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



  • @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



  • @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
    Capture.PNG



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


  • administrators

    @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.



  • @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 😛



  • @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?


  • administrators

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


Log in to reply