Z switch on expansion board, latency issue??
-
@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
- run the Z home (from far away from bed)
- 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??:
50fps
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.
Frederick
