End stops and limit switches
-
I posted this in the Duet section of the RepRap forums a few days ago but haven't had a response so I thought I'd try here.
I have a few questions about the duet and end stop switches which I haven't been able to find the answers on the wiki (but maybe I just wasn't looking in the right place).
1. Are end stop switches used purely for homing? i.e. if a switch was triggered during any other operation, would it be acted on to prevent movement beyond normal travel?
2. If I use DC42 IR probe for X or Y axis homing (as well as Z) would a switch fitted to the same axis be ignored or could it be used as a second stage safety switch?
The reason I'm asking is that I am likely to be using high torque stepper motors and fast print speeds so I'm trying to fathom ways to limit damage in the event of something going horribly wrong. I don't like to use the term "fail safe" but that is gist of it. I did think of fitting limit switches to the extremities of all axes and wiring the 24v in series through all the normally close contacts. Then if any switch contact was broken it would completely cut the power. The bed heater will be AC via a SSR so the 24V DC current wouldn't be huge. It'd probably work but it's not a very elegant solution so I'd greatly appreciate any advice. Thanks in advance.
-
1. The switches are normally used purely for homing. However, there is nothing to stop you setting up M581 triggers on them as well. You could also add NC switches at the other ends of each axis if you wish, wire them in series to a spare endstop input, and set up a M581 trigger on that input too.
2. A switch fitted to an axis that you normally use the IR probe for homing would be ignored unless you set up a M581 trigger on it.
If you decide to use M581 triggers to provide extra protection, please check that the response time is fast enough for you when printing. If it isn't, then there is probably scope to make it respond faster when the requested action is emergency stop.
-
David,
Apologies if you have this elsewhere and have not yet had time to respond but in case your eyes didn't get that far, I have a bit of an issue that I haven't been able to resolve. I've put NC switches at the other ends of each axis, wired them in series and set up an M581 trigger, all as per your suggestion in 1 above. On testing it, it seems to work fine when the machine is in a idle state as reported by DWC. That is to say that pressing any of the switches results in the machine going to "halted" and the LED on the Duet board changes state. However, it doesn't work when doing something like a large Z move and the machine state is reported as "Busy". The Emergency Stop on DWC will stop the move, even though the printer is "busy" but the switches have no effect.
Sorry to bother you with this - I know you must be very busy but if you can find time to respond at some point, it would be very much appreciated.
Ian
-
Execution of triggers that occur during execution of a macro are delayed until the macro completes. Other than that, trigger 0 should be executed immediately. In the next major firmware release I intend to make an exception for trigger 0 so that it always executes immediately. Unfortunately I will not be able to do any firmware work for a couple of weeks.
-
Hi David,
Thanks for taking the time - I appreciate that you have a life outside of reprap - don't know how you fit it all in.
I've done some more testing and this is really weird. I've discovered that if I do a move using the buttons on the web interface -i.e. press "Z+100" then open any of the NC switches while the move is being executed, the trigger does not work. However, if I do (what I think is) exactly the same thing by typing the G code command in the box at the top left of DWC i.e. G1 Z100 F180 and hit send, then open one of the switches while the move is in progress, the trigger works exactly as it should.
It is repeatable every time. It's as if pressing a move button on the web interface is being treated as a macro. Does that make sense? If so, is it something I should be talking to Chris Ham about?
Thanks
Ian
-
Pressing one of the move buttons sends several gcode commands and I think it may be using the macro stack to save and restore state. That would look like a macro being executed to the trigger handling code.
-
Ah OK. Now it's making sense. Guess I'll have to try and not do anything stupid until you get around to doing the next firmware release. Thanks for the help.
