Z switch on expansion board, latency issue??

  • Running latest firmware (3.1.1), duet gen 3 main board plus three expansion boards.

    I have a simple switch for homing Z. It has an associated LED so I can see when it is triggered. The switch is connected to an expansion board.

    I have recently experienced a few instances where the switch change of state isn't being recognised when homing Z and the motor tries to continue to raise the bed beyond Z=0. The LED indicates that the switch has triggered. I have to hit emergency stop (I run reduced motor currents for homing so no physical damage ensues).

    This is coincidental with my increasing the initial fast Z homing speed from 300 to 600 mm/minute. So I'm wondering is this could be due to some sort of latency issue due to the switch being connected to an expansion board.

    If that is the case, is there anything I can do other than reducing the homing speed or wiring the switch to the main board?

    Edit. I've just had a thought. Because this is a simple switch, and because the nozzle itself is the "probe" with no offset between the probe trigger point and Z=0, then I'm homing Z just like any other axis by using G1 with H1. Would changing to using G30 help?

  • administrators

    The latency is a little higher for switches and Z probes connected to expansion boards, but it should still be low (1ms or less) provided that the switch hasn't changed state very recently. If it changes state very often - for example, because of contact bounce - then the firmware will limit updates to once every few tens of milliseconds, to prevent it from generating too much CAN traffic.

    I would not expect changing form G1 H1 to G30 to make any difference.

  • @dc42 I've done a lot of testing today. I can home reliably and consistently at 300mm/minute (5mm/sec) for the first pass. But it frequently misses the switch trigger if I increase that speed to 600mm/minute (10mm/sec).

    Is it correct that the firmware reacts to the changing state (i.e a rising edge or a falling edge) rather than checking to see if the switch is open? Because that's what seems to happen. If it misses that event, then it'll never stop the motor. Whereas, if it was just a little late in "seeing" that the switch was open, the motor would stop but at a slightly incorrect position. But then the second, slow pass would be accurate.

    As it is, there is no point in doing a fast homing at more than 5mm/sec followed by a slow second pass because the faster move will never stop.

  • Is there any other way that I can check the state of a pin while doing the initial fast homing move? I looked at M581 but that seems to work by detecting either a rising edge or falling edge, so I'd guess that would miss the trigger too. I just want to sort of poll the endstop pin and stop the Z motor whenever the firmware detects if the switch is open circuit. At 10mm/sec Z travel speed, even 100ms poll frequency should stop the motor 1 mm beyond the trigger point, which would be a whole lot better than never stopping.
    The problem is that my Z max is 750mm so homing after printing a tall object with the speed limited to 5mm/sec takes 2 1/2 minutes.

  • So the switch is triggered in passing?

    If its not possible to mechanically lengthen the triggered state a diode and a capacitor might help stretch the pulse, or if the issue is bounce then just a lonely capacitor might do the trick.

    Back to software; i doubt daemon.g has the frequency you're after, but i suppose you could tell it to echo state.upTime and take a look. Alternatively if a trigger macro runs in parallel with any other g-code you could perhaps connect an input to ground and check its state with M582 to launch the triggern.g file; in which you could loop over G4 and if sensors.gpIn[n].value ?

  • @bearer Not sure what you mean by lengthening the trigger state. The switch is as simple as they come. It is a brass plate and a brass bolt. The plate is bolted to the carriage, the bolt is fixed to the hot end. One lead is connected to the plate, the other is connected to the bolt. So the switch is normally closed. The hot end is on a hinged mount. When the bed rises, it touches the nozzle which causes the hot end to lift, which breaks the circuit. The circuit remains in that state until the bed is moved away from the nozzle. But the firmware does not react to the change in switch state of that happens at 10 mm/ sec.

  • @deckingman ok, nothing to be done mechanically then, but debouncing it electronically might help. Seems all the inputs have a footprint for a capacitor on the inputs but its not been populated. Not sure what size the pad is, guessing 0402?

    Given the Duet already has the series resistance and pull up, that would affect the time constants for adding another series resistance and capacitor before the Duet. It might be easier to just throw some gates, a flip flop or a dedicated denounce chip on it if fitting the unpopulated capacitor isn't an option.

  • I tested similar configuration Ian uses with brass ball and brass plate pressed with a spring and pushrod detaching them and there is very small if any bouncing that I could catch on my 1GHz scope. On the other hand, retracting the pushrod for the ball & plate to make a contact is rather noisy. IIRC Ian is triggering on the opening of the contact so there should be no significant noise involved. Dunno how this changes over time as both brass surfaces oxydise and catch dirt.

    Adding a simple SR latch (SR flipflop) made from 2 nands 74xx00


    you can of-course do something like this, solder directly in-line on the wires...


    but I'd personally try to keep all the switches on the main board if possible

  • I can pretty much guarantee there is no mechanical bounce. The switch is normally closed and held in place with a spring. As soon as the bed touches the nozzle, it lifts off it's seat and that breaks the contact. It works fine at 300mm/minute (5mm/sec) but not at 600mm/min (10mm/sec).

    What I can't get my head around is that even if there is some sort of "electrical bounce", why does the firmware never detect any of those bounces? I could understand it if the switch triggered albeit a bit late. But if the homing speed is >5m/sec then more often than not, the switch state is simply ignored. The bed continues to rise after the switch is fully open and even after the hot end has lifted by about 10mm to the point where the bed is hard up against the carriage and the motor is still trying to lift the bed further until I kill it with emergency stop.

    At the start of homing, if the switch is already triggered then one gets a warning to that effect. So at that point, it (the firmware) must look at the switch state rather be looking for a change of state. Is there no way I could use conditional gcode or some such to poll the switch state every few ms during that initial fast(ish) homing move so that it will stop the motor, albeit some number of ms after the switch becomes open circuit? Then the second slow move would do a more accurate homing. As it is, all I can do is slow homing of Z.

    And why don't I get the problem with XY and U which all have cheap micro-switches connected to expansion boards and which I do the initial coarse homing at 1200 mm/sec? Why won't Z work at half that speed?

    Sure I could wire everything back to the main board but then I might as well revert back to Duet 2 with my 40 plus conductors going to the gantry via a big fat cable chain. (At least if I did that, I'd be able to PID tune my remote hot end heater which I still can't do after nearly a year because the firmware doesn't support it).

    Sorry - I needed to vent - rant over...........

  • @deckingman said in Z switch on expansion board, latency issue??:

    switch state is simply ignored. The bed continues to rise after the switch is fully open

    That makes no sense 😞

    If the detection is by SW so checking if the switch is open in a loop it must detect the open switch at some point. If the detection is by interrupt where the transition (edge) is detected, again, bouncing or not one of the edges must be detected.

    @dc42 said:

    it changes state very often

    During the move it should not change at all, when the switch is hit it might bounce and change "offten" but the first change should already be reported so ? Will the "first time it detects bouncing" board switch that output to "slow update forever" (till the board is restarted) or there's a timeout?

    end has lifted by about 10mm

    But still, even with 1ms delay at 600mm/min that's 0.01mm error, not 10mm

    So I doubt this has anything to do with bouncing of the contact 😞

  • Its odd indeed. How far is it from the expansion to the main board? I.e. could running a temporary wire add more signal issues, or help isloate the problem to the switch or the expansion board?

    (or if you have a scope to view the actual signal that'd be great, or maybe you can bribe/threaten a neighbor to help you out?)

  • @bearer The CAN IN lead is about 100mm from board 1 and CAN OUT is about 750mm to board 3, but like I said, the X,Y and U microswitches are all on expansion boards, albeit not the same expansion board, and they all work fine at 1200 mm/sec. The X micro switch is on board 1, Y is on board 3, U is on board 1, and Z is on board 2 (so the middle one of a chain of 3). A, B and V are all on the man board.

    The end stop wires from the switch to the board are about 200mm long max. I can't see it would make any difference but there is an LED across that Z switch, wired with a series resistor and as per DC's instructions. Wiring diagram can be found here https://somei3deas.wordpress.com/2020/04/18/my-6-input-mixing-hot-end-part-7/. Is there anything there that could cause the problem?

  • @arhi said in Z switch on expansion board, latency issue??:

    That makes no sense 😞

    Glad you think so too.

    But still, even with 1ms delay at 600mm/min that's 0.01mm error, not 10mm

    So I doubt this has anything to do with bouncing of the contact 😞

    That's what I was thinking. Although according to some, I'm just an old fart so what do I do I know?

    It seems that during a G1 Z-nn move, if it doesn't detect the switch at the exact time that it opens, then it will never detect that the switch is open, no matter how long it remains in that state.

  • @deckingman said in Z switch on expansion board, latency issue??:

    That's what I was thinking. Although according to some, I'm just an old fart so what do I do I know?

    they call me the same although I think I'm a lot younger than you 😄

    It seems that during a G1 Z-nn move, if it doesn't detect the switch at the exact time that it opens, then it will never detect that the switch is open, no matter how long it remains in that state.

    The weird part is your XY works ok at higher speed. So questions arise

    • how are your XY and Z switched configured?
    • if you move your X to the same board where your Z is will it work?
    • if you move your Z switch to the same board where X/Y are will it work?

    And also one easy experiment

    1. run the Z home (from far away from bed)
    2. manually open the switch (press with something)

    do [2] at different speeds (I know you cannot measure speed your hand is opening it but..)

    when you open the switcch and it does not stop, release it to close and open again to see if it will detect it then

  • @deckingman said in Z switch on expansion board, latency issue??:

    LED across that Z switch

    it'll discharge any capacitance faster, but but without any rc filter it'll be negligible i recon (but I'm more comfortable with outsourcing my analouge electronics tbh)

    in any case its more likely to be related to the switch than the expansion board/can interface imho, and running the wires back to the main board was the simple test for that. but it won't be a apples to apples test with the additional wiring so idk. visualization would be awesome - can you do a high speed video of the z switch led?

  • @bearer said in Z switch on expansion board, latency issue??:

    visualization would be awesome - can you do a high speed video of the z switch led?

    This is the video that is embedded in the blog post I linked too. It's not high speed as such (50fps). This is homing at 300mm/min first pass, then backing off 5 mm and doing 60mm/min second pass. https://www.youtube.com/watch?v=NbgS-Kh53nQ

    It's a composition using PIP to start with, then separate clips.

    The video should work but I'm not sure what permissions I set up for it. If it doesn't, run it from the blog post.

    Edit. At 600mm/min for the first pass, the bed just keeps rising until it jams up against the carriage.

    Edit 2. Let me know if you can actually see any movement of the nozzle when the contact breaks - nobody has as yet. 🙂

  • @deckingman said in Z switch on expansion board, latency issue??:


    had a look, but thats probaly far too slow to be helpful - I was hoping you had some sort of camera with higher fps support, some do as mostly a gimmick but can be usefull when you don't need the resolution.

  • can't see anything move when it triggers

    bunch of modern mobile phones has the high fps capability (have not find use if it yet)

    btw when I was building my first printer long time ago I was checking out the CNC endstops and 99% of them are made so that whatever is moving can pass on and is not in any way blocked by the end switch... I was thinking about using similar switch like that for my XYZ to do a super fast move to a proximity switch and then go slowly to the actual endstop but gave up as the cubebot finally had to be destroyed .. might not be a bad thing to setup for your machine irrelevant to this bug

  • @bearer I might be able to speed it "digitally" (or rather stretch that event so it spans a longer time frame), but natively it's still 50 fps. Not sure what you are hoping to see. When homing fails at 600mm/min (10mm/sec), the LED lights and stays lit while the Z motor grinds away at trying to bend my rails (I always reduce the motor currents for homing, so no physical damage occurs).

  • @deckingman said in Z switch on expansion board, latency issue??:

    Not sure what you are hoping to see

    (hoping to not see) multiple flashes; but you'd need actual higher frame rate for that; it was just a thought as its more common for cameras (and phones) to have high fps functions at the cost of resolution today. and maybe, just maybe it could catch electrical bounce if it was severe enough.

  • @bearer ....and of course, that video was with the switch working normally. I just stepped through the video and a single flash last about 2 frames which I guess is the time it takes for the motor to stop, change direction and then move the bed away from the nozzle. But surely, even if there were multiple flashes, faster than 50 Hz, indicating some sort of bounce, wouldn't the firmware eventually catch on to the fact that the switch had triggered? David indicated that if there was bounce, then the update frequency might be reduced to 10s of ms. I could live with that. But I'd guess I've left it grinding away at the carriage, with the LED fully lit, for about 10 seconds before I hit emergency stop.

    It just seems that the firmware is looking for a fast low-high transient (or high-low) and if it doesn't see that transient, then it doesn't stop the motor (regardless of the fact that the switch might have changed state while it wasn't looking). I'm just wondering if the firmware does something different for Z homing because that often uses a probe and it needs to be more precise than the other axes. That would explain why the other axes work fine at double the speed at which the Z axis fails.

  • OK. So me being a (retired) mechanical engineer, I came up with a mostly mechanical solution. I made a pivoting arm with a micro switch at one end and a spring at the other. Like this


    When the bed gets to within about 60mm of the nozzle, a plate on the bed hits the switch. Any further bed movement simply pushes the pivoting arm up against the spring.

    Then I use a "Fast Jog Z" macro which will be the first part of my home Z. So basically, if the bed is >60 mm below the nozzle, the macro will jog it up 50mm at 900mm/min and repeat that fast(ish) 50mm move, until the switch triggers. After that, my normal "slow" (300mm/min) Z homing macro will complete as normal. 900mm/min is 3 times faster than I had before but (slightly less with the slow down between moves). I might push it up even more (although less than a minute for the full 750mm travel is reasonable).

    The macro is detailed in this thread https://forum.duet3d.com/topic/17438/more-conditional-gcode-help-required-solved/6

  • My solution involved two "beam break" detectors space 30 mm apart mounted on the frame (near Z min) and a 30 mm tall "blade" mounted to the bed that broke the beams.

    Fast movement until the lower beam was broken, slower movement until the upper beam was broken.

    This was on v2 until the setting (being able to specify the input being used for the Z end stop) that allowed it to work was removed. I think that setting is back in v3.


Log in to reply