Improving homing & safety

Discussion in 'Getting Started' started by Beat, Nov 25, 2019.

  1. Beat

    Beat Active Member

    Joined:
    Apr 2, 2016
    Messages:
    31
    Likes Received:
    5
    The current implementation makes it possible to drop a tool or ram it into the bed when Z-homing, which is not really satisfactory. Therefore I would like to implement the following improvements:

    A. Make the system aware of whether and which tool is mounted. This could be done using electrical continuity between the carriage and the respective tool (works fine here, requires one additional wire for the carriage and each tool) or with an additional microswitch on each tool (two additional wires per tool) and the 4 GP IOs on the DueX, for instance.

    B. Change the homing sequence and rules to:
    1. Home Y
    2. If Y is homed, home X
    3. {If tool#N is mounted, move to the respective docking position} home C
    4. {If If tool#N is mounted, move to the respective docking position and home C}, move to bed centre, home Z
    • moving to absolute X and Y positions requires implicitly that these axes are homed
    • homing C at the docking position unmounts the tool
    What do you think? Does this make sense?
    Would anybody be able to make the changes in the FW/configs? (I'll do it myself but I will have to learn how to first.)
     
    #1 Beat, Nov 25, 2019
    Last edited: Nov 25, 2019
    garethky likes this.
  2. Amr

    Amr Well-Known Member

    Joined:
    Jun 2, 2019
    Messages:
    130
    Likes Received:
    30
    Theoretical this is doable. M581 and M582 are what you need. you can use M581 to set a trigger on an end-stop say you mount one end stop on the tool changer head itself and hook it up to E0 Stop or E1 Stop, then in config.g you would set up the trigger like "M581 E1 S1 T2" create a triger2.g in sys with T-1 and add "M582 T2" to all homing files ie: homec.g, homex.g, homey.g, and homez.g that way if you try to home any axis or all of them and the end-stop is high it will drop the tool to its location first. now the hard part is designing a holder for the end stop on the tool changer head to be triggered when a tool is mounted. I think the best place to start this is redesigning the cable management part on the tool changer head to allo for mounting an end stop then this should be a no issue any more. I will try my hand in redesigning this cable management part if I get some where useful will definitely share
     
  3. Beat

    Beat Active Member

    Joined:
    Apr 2, 2016
    Messages:
    31
    Likes Received:
    5
    Thanks Amr. Yes, it looks like M581&582 is exactly what I need for this. It's clear to me now how this can be implemented. Much easier actually than what I suspected.
    Re-designing the parts will be the easy part actually (CAD is a major part of what I do for a living :) ), so you can leave that part to me if you like.
    BTW, the unmounting sequence is only required for homec.g and homez.g, not for homex.g and homey.g. On the contrary, the X and Y axes must be homed in order to unload the tool.
     
  4. Beat

    Beat Active Member

    Joined:
    Apr 2, 2016
    Messages:
    31
    Likes Received:
    5
    So I got the hardware setup and triggering the tool parking scripts using M581/M582 works nicely, too, except for one major problem. How do I get the homing script to pause until the triggered parking script finishes? At the moment, it looks like both are running in a threaded fashion somehow. So does anybody know how a script can be set to pause all other scripts until it has finished? (I asked the same question over in the Duet forum but haven't received a useful answer yet.)
     
  5. Amr

    Amr Well-Known Member

    Joined:
    Jun 2, 2019
    Messages:
    130
    Likes Received:
    30
    can you elaborate on how you set this up, My understanding is that you should have the trigger setup in config.g and for that trigger you create a trigger2.g in the sys folder where it has T-1. and in the homez.g files you add M582 in the beginning to check for the trigger state before homing. is that what you have or did you do it differently.
     
  6. Beat

    Beat Active Member

    Joined:
    Apr 2, 2016
    Messages:
    31
    Likes Received:
    5
    No that wouldn't work. I don't really want any genuine triggering to happen, because triggers react to changes, e.g. when an endstop is hit. I just abuse the triggers for conditional branching depending on a state (tool#x being mounted) not on a change of state. Also, I wanted to modify the original scripts as little as possible. So here is how it works or should work:
    homec.g first calls tparkcurrent.g, which looks like this:
    Code:
    ; tparkcurrent.g
    ; assign triggers 2-5 to endstops 2-5 and check each
    ; if active (=tool mounted), trigger[2-5].g will be called, which shall call tpark[0-3].g in turn
    
    M118 S"tparkcurrent.g - start"
    
    M400        ; wait for queued moves to finish
    
    M581 E2 T2 S0   ; set trigger T2 to by activated by rising flank (S1) of endstop E2
    M582 T2         ; actively check state of T2
    M581 E2 T2 S-1  ; deactivate trigger
    
    M581 E3 T3 S0
    M582 T3
    M581 E3 T3 S-1
    
    M581 E4 T4 S0
    M582 T4
    M581 E4 T4 S-1
    
    M581 E5 T5 S0
    M582 T5
    M581 E5 T5 S-1
    
    M118 S"tparkcurrent.g - end"
    So I use M581 E2 T2 S0 to assign T2 to E2 (E2 being the microswitch on tool#0).
    Then I use M582 T2 to poll the state of E2.
    If E2 is depressed, trigger2.g starts.
    Then I have M581 E2 T2 S-1 in both tparkcurrent.g and trigger2.g to make sure, trigger2.g. is not invoked erroneously again
    Then tparkcurrent.g does the same for the remaining 3 tools. But let's assume tool#0 was mounted when homec.g got called. tparkcurrent.g got called and trigger2.g was triggered. Now trigger2.g should proceed to moving to the parking position #0. Only then, C should be homed whereby the tool would be parked and the machine would be in a defined state.
    The problem is that while trigger2.g is running, tparkcurrent.g does the same in parallel (obviously because trigger2.g was not called by tparkcurrent.g using M98, but was invoked through the trigger mechanism). So the homing of C and the parking happen in parallel and the tool falls off on the way to the parking position.
    What I need is a way to make the triggered scripts pause all other script execution until they finish.
     
  7. Amr

    Amr Well-Known Member

    Joined:
    Jun 2, 2019
    Messages:
    130
    Likes Received:
    30
    have you tried putting M400 in the homec.g that should tell duet don't start the homec until the buffer is clear.
     
  8. Beat

    Beat Active Member

    Joined:
    Apr 2, 2016
    Messages:
    31
    Likes Received:
    5
    Yes, I actually put 20 there because somebody in the Duet forum who had the same problem (and couldn't get it solved properly) said it seemed that one M400 per G1 would be required. Didn't really help in my case, though.

    If there is no easy way, I'll resort to...
    • ...putting just a general stop (M0, M1 or M112, I'll have to find out what's most appropriate) into the trigger scripts to make homing C and Z safer. I can then call tparkcurrent.g as a macro manually. Not quite as elegant but functionally equivalent, for the time being.
    • ...waiting for the new Duet firmware which will allegedly will have conditional G-code. That will allow me to do this kind of things properly, i.e. without abusing triggers for conditional branching.
     
  9. Beat

    Beat Active Member

    Joined:
    Apr 2, 2016
    Messages:
    31
    Likes Received:
    5
    So, for those who are interested, I have implemented it as follows:
    • When trying to home C, Z, or all with a tool mounted, the Duet will abort by resetting itself (M999)
    • Afterwards, you can just run the "Park tool & home all" macro. This macro will only home X and Y if no tool is mounted, so it can't replace the homeall.g script.
    In essence, the printer is now safer, but the implementation will become more elegant once we get conditional G-code with the next release of Duet firmware.

    upload_2019-12-1_1-59-13.png
     
    Spoon Unit and Killercds like this.
  10. Jai Stanley

    Jai Stanley Well-Known Member

    Joined:
    Aug 28, 2019
    Messages:
    115
    Likes Received:
    60
    Excellent work! I had heard conditional g-code was coming for the Duet 3; but not the Duet 2. If so, I have a lot of good ideas, one including a bowden head that cuts filament near the hot end heatsink and a Prusa MMU style filament changer. I like the idea of multi colour prints; but wouldn't want to change tools just for aesthetics. It's too valuable to me to be able to switch tool-types.

    This closed loop system of knowing which tool is loaded is VERY useful. Personally I'd rather have a single microswitch on the tool head and one on each parking position. That way you could conditionally know which tool is loaded, OR if any tool has failed to load/park and put the machine into exception condition.
     
  11. Beat

    Beat Active Member

    Joined:
    Apr 2, 2016
    Messages:
    31
    Likes Received:
    5
    Thanks for the kind words @Jai Stanley
    Allegedly, the Duet V3 firmware is backwards compatible, i.e. it can be used for the Duet2 series also.
    You're quite right about the arrangement of microswitches . That hadn't occurred to me :rolleyes:. It would probably be good to have a laterally actuated roller-lever microswitch because I'd rather not introduce any outwards pushing force in the dock.

    How about a 2D filament mux, making it possible to feed any out of 20 filaments or so to be fed to any of the tools? :D
     
  12. Andy Cohen

    Andy Cohen Well-Known Member

    Joined:
    Aug 23, 2019
    Messages:
    217
    Likes Received:
    57
    One thing I see that you should at least note... Your design assumes you are going to stay with the current setup at the top of the extruder. Based on my experience all the Bowdens gotta go which in turn will mean the parts at the top of each tool will change.
     
    Beat likes this.
  13. Beat

    Beat Active Member

    Joined:
    Apr 2, 2016
    Messages:
    31
    Likes Received:
    5
    No the conditional G-code is here in RRF3.01(rc11) I want to check if a tool is on the carriage before homing Z. But I can't figure out what the expression of the if-statement needs to look like. Does anybody know how to query the state of a pin (which is not an endstop to any axis) in this context?
     
  14. dc42

    dc42 Well-Known Member

    Joined:
    Aug 16, 2016
    Messages:
    458
    Likes Received:
    206
    1. Use M950 with the J parameter to assign a GPIn number to that pin.
    2. Query it in the object model using: sensors.gpIn[n] where n is the GPin number you assigned.
     
    Beat likes this.
  15. Beat

    Beat Active Member

    Joined:
    Apr 2, 2016
    Messages:
    31
    Likes Received:
    5
    Thanks, that was the missing link.
     
  16. Beat

    Beat Active Member

    Joined:
    Apr 2, 2016
    Messages:
    31
    Likes Received:
    5
    Everything works fine now ... almost :)

    1. It appears that upon executingG28 [axis], the homing state of the respective axis is cleared even before home[axis].g is called. That makes it impossible for homec.g or homey.g to execute a T-1 to unload a tool, even if the system is aware of which tools is loaded and all axes where homed before. Why is it necessary to clear the homing state at all?
    2. In summary, I have homec.g check if some tool is mounted using the microswitches. If so, it calls tparkcurrent.g, which homes X and/or Y if necessary, checks which tools is mounted and calls tpark[x].g, which force-unmounts the tool at its dock. Then C is homed. homez.g also checks and calls homec.g if a tool is present. All of that works just beautifully if a tool remains on the carriage during a reset for example. Upon G28, the tool is unmounted and all axes get homed. However, when I execute G28 Z during normal operation with a tool mounted, the tool gets force-unmounted (remember, T-1 doesn't work) just fine but homez.g subsequently fails (at G30, it seems) saying Error: G0/G1: insufficient axes homed although X, Y and C are all homed (as verified by echo "homed", move.axes[0].homed, move.axes[1].homed, move.axes[2].homed, move.axes[3].homed just before the first G30 command) . The only way to get Z homed again is a reset.

    @dc42 , do you think 1. could be changed/fixed and do you have an idea what's going on in 2.?
     
  17. Beat

    Beat Active Member

    Joined:
    Apr 2, 2016
    Messages:
    31
    Likes Received:
    5
    ....for completeness sake, here is how I define the microswitches in config.g:
    Code:
    ; Tool microswitches
    M950 J0 C"!^duex.e2stop"
    M950 J1 C"!^duex.e3stop"
    M950 J2 C"!^duex.e4stop"
    M950 J3 C"!^duex.e5stop"
    and attached are the the files involved (for one tool)
     

    Attached Files:

  18. Nibbels

    Nibbels Well-Known Member

    Joined:
    Dec 12, 2019
    Messages:
    165
    Likes Received:
    32
    This topic became high priority this night.

    My T1 tool dropped.
    The print continued, the Y-axis got some shift -> so no tool was working afterwards.
    I guess this happened because loose filament might have blocked one tools dock.

    In case the tool does not get grabbed at all
    then my printer has to be paused or stopped.

    Because I park my nozzles ontop of a razor blade
    the razorblade had all the molten filament ontop and around
    and the hotend was totally covered in filament. *bäh*

    For my case the single cable on the coupler would be enough
    but I will closely read this thread again within the next days.
     
  19. Beat

    Beat Active Member

    Joined:
    Apr 2, 2016
    Messages:
    31
    Likes Received:
    5
    Implementing a tool-on-carriage check point would be easy. All you need for this is available and working today.

    Assuming you have the tool-detecting microswitch on the carriage connected to duex.e2stop, all you need to do is add
    Code:
    M950 J0 C"!^duex.e2stop" ; assign duex.e2stop pin to sensors.gpIn[0], inverted and pull-up activated
    
    at the end of config.g
    and
    Code:
    if sensors.gpIn[0].value = 0  ;if the microswitch is not pressed...
        abort "Failed to grab tool"
    at the end of each of the tpost[tool#].g files

    And while you're at it, you could put a checkpoint at beginning of tpre[tool#].g to make sure the carriage is not trying to pick up a tool while another one is still mounted (e.g. because the unmounting failed).
     
    Nibbels likes this.
  20. Sylvain

    Sylvain Active Member

    Joined:
    Nov 18, 2019
    Messages:
    32
    Likes Received:
    3
    Assuming I use a two wires switch (like the Z proble one), could you please tell me where to plug each wire ?

    One wire to VCC or GND ?
    the other wire to which pin ? Duex5 or Duet Ethernet/Wifi ?

    Thanks !
     

Share This Page