Z switch on expansion board, latency issue??
-
@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.
Frederick
