Z motor auto shut down.
Opened this issue · 19 comments
Not sure if I’m GC or firmware. Bar as we discussed to save the parts on the ridgid z control or future Z setups. Write an auto stop feature that will detect either no movement, or a voltage to trigger an auto shutdown in case of a runaway motor or accidental request to move the Z past the physical limitations of the device in order to save parts.
On my Ridgid 22000, the motor keeps on turning after the sacrificial part has broken. What to use to detect the error condition? Upper and lower limit switches?
Would a stiffer mount and torque detection make this easier to deal with?
What about a sacrificial conductive piece of circuit board tied to the stepper control?
I know mine was a bit tricky to set up properly to support a 0.75" cut along with proper retraction + default safety retractions. I had to use the STOP button a few times before I could trust it.
The mount (motor shaft attached directly to motion screw) is as stiff as possible. The issue is trying to drive beyond the physical limit. A pair of conductive touchpoints to mount at the extremes of travel and a way to make the traveler contact them would do, but would be difficult to make universal.
I discussed with Bar about this. I am almost finished with a new Z set up and using the motor provided with the Maslow. I know a few times, my fault, I put in inches instead of 10ths and send the Ridgid to the limit. A software detection of the motor voltage or stop of the movement, because it tops out, would send a stop to the motor control and limit damage to the router base parts and the motor.
Normally closed reed switches could also be mounted inline on one of the wires effectively cutting the signal if it's easier to detect.
Another idea is to support calibrating z axis limits if it would be feasible to enforce them. We would just need to have an additional setup flow in GC, and monitor in the FW, then setup is really the only time you could overdrive them.
"reed switches could also be mounted inline on one of the wires effectively cutting the signal" The reed switches would need to interrupt motor current, probably too great for a reed switch. I don't think interrupting an encoder signal would stop the motor, I could rig up some wiring to find out, though 😀.
Would the software limit would need to be an absolute position not affected by changing the zero setting, or would it be a maximum travel above or below the zero position?
"software detection of the motor voltage or stop of the movement, because it tops out" I don't think we have a way to monitor motor current, and the motor and screw keep turning after the sacrificial part has lost its threads. A software reality check in the z-axis panel might help that source of trouble, but I've seen the z-motor run into the stops when the connector on it came partially loose, interrupting one of the encoder signals. Firmly attaching the z cable to the motor mount has prevented that from reoccurring...
My idea of the auto shut off comes from the calibration routine when the motors pull against each other until there is a sufficient "something measured" to stop the pulling as to not tear off the arms. My idea was the same for the Z motor detecting the same thing and stopping to not tear up the z bracket on the router.
When the motors pull tight against each other, the right motor has been commanded to move at speed 100 for one second. CNC_Functions.h dealing with gcode 'B11'.
The H-bridge chips we're using just don't give us access to the motor current 😟
Off-topic, could this be the source of the 10 degree error in this thread?
I see 3 viable options, each with it's own merits and drawbacks...
-
Hardware Z limit switches
Just a NC switch that would use an AUX. Simple or as complex as warranted. pause? stop? just ignore further Z movement? support 2 NC switches in serial, and memoize current Z direction? 2 Aux? etc... -
Explicit Software Limits
An advanced option toggle "Enable Z Limits". This would enable 2 more Z index buttons for setting min/max on the Z popup. -
Default/Configurable Software Limits - The previously tossed around idea. Allow setting the limits based on Zero position. ie: zero -/+ 2 inch and ignore any movement past these limits. The defaults should work out of the box for the majority of users, but should be adjustable for people that want to run a different spindle or Z control. (ie: 3" hand drill for making pegboards?), or simply disable it. This would need to be done on the firmware size too, so any Gcode based Z movement can also be clipped.
I would be happy to investigate any of these options if there is enough interest.
Option #3 with separate up- and down- values makes the most sense to me. The zero point is rarely at the center of the lead screw for me - it depends on how the bit is loaded.
I don't think we want to alter any gcode, though. Maybe halt (temporary) cutting and put up a warning dialog with Stop/Continue choices?
I think the original goal was to add detection for when the motor is stalled so we could stop it if it hit something. The same behavior would be useful on the main motors to detect if the chain has become caught. Didn't you look into this at one point @blurfl and determine that it was difficult to do?
We don't have any current feedback, so an automatic system would have to look at the PWM value and stop the motor if no or very little change in encoder values was seen. I don't think the implementation is that hard.
This would work well for a disconnected motor.
And probably works ok for the main motors as the system generally can't tear itself apart that fast.
But, I question how easy it is to break that little orange clip. If it gives only minor resistance, it will be tough to tell the difference between that and a dull bit on hardwood.
The motor has enough torque that I don’t think the change would be noticeable. The damage can be caused by hitting the end stops or by having the latch too thought, though. Hard to guard against that.
@krkeegan, I think I've seen routines to report speed and location and if I remember, you're the one to thank 😊. I'm not sure how to call them, could those be useful in this?
In a different issue, I was looking to track the number of encoder pulses a motor had seen - actually I wanted to send a motor 10mfull rotations by pulse count to see whether it came to rest at the same location. Is there a way to use them in that way?
Umm, both of those concepts are a little complicated as they are very low level functions that really did not envision direct access.
For speed, I would use the values returned by
leftAxis.motorGearboxEncoder.cachedSpeed()
As for the 10 rotations by pulse count. It might be helpful to know what you are attempting to test as I think you want to try and use as much of the stack as possible as the low level function probably isn't where the problem is. What you could try is to use the B09 command which moves the axes a fixed distance. So if you made a macro like:
G91 (Use Relative Units)
B09 R100 F500
This would move the right axis 100mm. the F value sets the feedrate (1000 is the max). Then calculate what ten rotations should be in distance and use that number. This will mimic at least some normal like use.
I see, thanks. We were troubleshooting a question about accuracy when feeding chain in this thread . madgrizzle found that the sprocket travelled a half-tooth farther than he expected when he issued B09 R635 and that this was cumulative and reversable. I can see that we should have been using G91 relative mode, thanks for clarifying.