Stall Detection as a Backup
-
Stall detection during homing doesn't work at the moment. But really that part is kind of superfluous, since if you tune the motor current sufficiently well, you can have the motors stall naturally in the event of a crash, no software detection needed really.
-
@Phaedrux said in Stall Detection as a Backup:
Stall detection during homing doesn't work at the moment. But really that part is kind of superfluous, since if you tune the motor current sufficiently well, you can have the motors stall naturally in the event of a crash, no software detection needed really.
So I am am reading this right, if I simply reduce the stepper amperage during homing, that would be sufficient to accomplish what I am trying to do, since the steppers will be driven at a low enough current as to not be able to overcome the stall and cause any collision damage...?
-
Yes. It can be a bit tricky with multiple motors, but if you can find the current required to just move reliably without stalling during the movement, but also low enough so that any physical resistance is enough to safely stall the motor.
-
@Phaedrux said in Stall Detection as a Backup:
Yes. It can be a bit tricky with multiple motors, but if you can find the current required to just move reliably without stalling during the movement, but also low enough so that any physical resistance is enough to safely stall the motor.
Excellent. Thank you.
-
@br7408 I'll just add that it's common practice to reduce motor current at the start of homing and restore it back at the end.
Something else you might want to consider is to check the status of each homing switch prior to homing the associated axis. If a switch fails in the homed state, then the axis will get flagged as homed before any physical movement takes place. So for example, if the print head was at X=100 and the switch was in a failed state, then X=100 will be interpreted as X=0. So if you then command the print head to go to X max, it'll crash into the frame.
The easiest way to do that check is to use conditional gcode. I'm on my phone right now but I'd be happy to share the code that I use when I get to a computer. Let me know
-
Thank you. I would definitely be interested to see what you have.
-
@br7408 said in Stall Detection as a Backup:
Thank you. I would definitely be interested to see what you have.
This sort of thing...........
;****check if an end stop is already triggered because it might be a wire has fallen off ; X=0,Y=1,Z=2,U=3,V=4,A=5,B=6 if sensors.endstops[0].triggered abort "X endstop already triggered at the beginning of the homing move - aborting"This was from a CoreXYUVAB so I had 7 such commands and that particular line is what I had just before homing the X axis. As per the annotation, endstop[0] is usually the X axis, 1 is the Y axis and 2 is the Z axis etc. See here for an explanation of the "abort" command https://docs.duet3d.com/en/User_manual/Reference/Gcode_meta_commands
-
You might want to extend @deckingman suggested code to include a short move if the end stop is triggered and then check again.
That would ensure that the axis is not simply parked at zero.
Of course is the endstop were actually faulty you could be at max limit and this move would cause a crash, albeit probably not significant.if sensors.endstops[0].triggered = true ; if we're hard against the endstop we need to move away G1 H2 X5 F1200 M400 if sensors.endstops[0].triggered = true abort "X Endstop appears to be faulty. Still in triggered state." -
@OwenD That's an interesting idea. Although if one considers the likelihood of an axis being parked at min, then there is an equal likelihood that it could be parked at max. One could catch that by using end stops at high end as well as low end but would that be worth the additional complexity? And of course, there is an equal likelihood of an axis max end stop failing as an axis min. Personally I do use axis maximum end stops and have them all wired in series and connected to a spare io pin such that if any one gets activated, it triggers an emergency stop. But that's only because I tend to do stupid things without first homing the machine. On the other hand, we almost invariably move Z away from the nozzle by a small amount before homing X or Y, without any check if Z is already at max. So maybe an easier way would be to extend that initial small G1 Z move at the start of homeall, to include X and Y. Who knows? Essentially there is no 100% failsafe way of moving an axis before the machine has been homed.
-
@deckingman
No there's no foolproof way short of absolute encoders, however if you command an move away from the end stop and the stop is still triggered then it's safe to assume a fault on the stop regardless of the actual position.
Either that or the axis isn't actually moving. We can't check that.
Either way an abort seems appropriate. -
@OwenD Here is another random rambling from an old man................One can fairly easily adopt working practices that will ensure the print head is never hard up against an end stop just before it is turned off. Most of do this anyway by moving the head away from the print when it's finished. So as long as that position isn't at an axis minimum, then about the only way one could start homing with a gantry at axis minimum would be if it was moved to that position manually while power was turned off. The mechanical engineer in me says that one could fit a lightly sprung buffer - just enough spring pressure to push the gantry away from the end stop when power is not applied, but which would easily be overcome by an energised motor.
-
@deckingman
Between the two of us I think we've added a significant amount of complexity to solve a rare event that is easily handled by proper care and attention by the operator.
Feels like I've been to another OHSA meeting
