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