Hello dear community. I am a new member here and am happy to have found the very special and unique project that is ODrive.
This topic is meant as a place to think about the implications and consequences of using ODrive as a servo drive system for CNC machine tools that machine materials. This may be CNC milling machines, lathes, grinders and planing or shaping systems. This topic is specifically concerned with mechanically overconstrained machine tools of high stiffness, low compliance and high rigidity and mass as opposed to desktop “CNC routers” that can be lifted by one person, which I am not talking about here.
The general concept here would be the ODrive being controlled by a step/dir pulsetrain from a motion controller. A typical high-performance example for this motion controller would be the Ethernet Smooth Stepper by Warp9. Let us assume that the ODrive has its power devices watercooled and that all motors are properly cooled as well.
One important aspect that I would like to hear some thoughts about is reliability and also - to a certain degree - safety.
The type of machine that cuts dense and high-strength materials such as metals is often times going to machine parts of relatively high material cost. One example scenario would be a large block / “billet” of high-strength Aluminium being milled out to create a complex final part and if at some point during the process that may take several hours or even days for super complex 3D-contours, the drive would have a certain glitch or bug that causes movement error, the entire material could be wasted, not mentioning the machine time of course and possibly a failure of the tool that may also very well be quite costly.
Since we are dealing with encoders that transmit singals in a single-ended signal configuration, we would have an obvious source of such errors and we could mitigate that by using a balanced line-driver run, but I am more interested in your concerns and thoughts that may be unique to the ODrive and its behavior that a person that has not as much experience with it may not be aware of.
A main worry of mine is the idea of the drive going out of control and thus disrepecting the end-of-pulsetrain state that a triggered limit switch would cause through the motion control hardware. A second-level “far edge” limit switch at the ultimate limit after the normal limit switch that, when triggered, opens a contactor to cut DC power input to the ODrive is an option to think about, but there is another major concern:
Some machine tool configurations make it necessary to drive a single ultra stiff axis with two motors either for increased power, for backlash optimization (for example two pinions slightly preloaded against each other driving a large gear or rack) or for balancing of forces (for example a large swiveling rotary axis that has to be driven from both sides to avoid torsional twisting of the structure).
In these situations, we have a potential for a really serious failure mode where the entire machine may be destroyed in a very violent way that may become even a safety hazard.
Also, the startup sequence and its offset calibration is a problem here to consider. As I understand it, an encoder with an index / Z-channel would enable a more streamlined process that does not move the motors as much and we can also set the direction of the calibration to be in sync, but could there still be a mismatch in motion profile of the motors when the system starts up? An extreme measure would be to implement a mechanical decoupling of the motors (a variant of a clutch or other disengagement) that allows the motors to spin freely and let them calibrate and afterwards reengage the motors mechanically to the main structure. But of course this is a high-complexity mechanical solution and thus costly.
I am very aware of the fact that ODrive is not a closed-source proprietary servo drive system that was designed specifically for the tasks I am describing here. I just want to hear some of your thoughts on these aspects and how you would view the ODrive under these aspects.
Any input is greatly appreciated. Thank you very much.
Shouldn’t be a problem. Might need a slightly customised firmware but it can easily be done.
Is the twist axis so weak that it would fail catastrophicaly if the motors opposed each other? Isn’t it more about reducing the (micro-radians of) elastic deflection?
Have you read the numerous other threads on here about CNC machines, E-stops etc? For example you don’t necessarily need a contactor for E-Stop. You could just pull the RESET line of thge chip low and it will stop (freewheel). If you need more than that then I’d suggest waiting for the v4 board, which (i think) might have STO. ask @madcowswe
As I’ve said a few times, step/dir is not the best command source for the ODrive as it’s inherently incremental, so it potentially suffers from the same issues you describe above. If you can find a CAM software that outputs absolute axis positions, that would be much better.
I think a multi-axis motion controller might also be in the works for v4.
Thank you so much for taking the time and replying, which I appreciate very much. I have been looking at numerous topics all loosely related to these considerations but have not found a thread that specifically looks at the concept of reliability in a heavy and costly machine tool that may sometimes be run in a production-level sense where the machine 1. runs for hours and hours without pause and 2. where significant costs may be involved because of machine mechanical component cost and material cost. Also the machine would be custom-made and custom-designed so maybe there would be parts built into it that were very difficult to source and would be a real challenge to replace if they get destroyed in a drive-induced crash.
I wanted to hear if somebody runs a machine like this and what their true experiences are with ODrive under this aspect, which is more specific than the general idea of using ODrive for CNC at all.
Yes, you are correct. This would be considered mostly because of this. The U-shape of a deep swivel base can be an odd shape for effectively transferring torque between the drive/bearing flanges. It can be designed to work well with one driven side, but the high end machines usually drive them from left and right which I find just a good design practice in general. It is not that I am concerned about the weak structure but more about the high force of a speed-reduced motor. Here, we may encounter torques in the range of 1000 Nm and above added to possibly high inertia situations and while the structure itself will most likely not fail, there could be severe damage to the aforementioned expensive parts such as gearboxes or other precision transmission elements.
If we had a short flying gantry riding on top of a ‘box’ structure machine that has not a lot of depth support with linear carriages placed closely to each other on each side of the gantry, a dual-ballscrew drive each able to reach 5 to 10 kN could also severely damage the linear carriages and the entire gantry if the motors were violently driven out of sync.
Generally, a situation where a dual-motor axis is going out of sync with very high torque on the motors, we have serious issues and it is just not fun.
You mentioned the AS5047p SPI sensor or a similar unit in another thread. Would you say you recommend this type for a CNC machine tool application, especially since a dual-motor axis could be started up without any startup calibration? With this encoder, is there no drive-induced movement of the motors at startup, or ever, at all?
When it comes to far-edge limit switches, A type of ‘category 2 stop’ would be achieved with pulling the nRST pin low on J2 it appears while there is a bit of uncertainty left. If contactors are used, I guess I would have a category 0 true E-stop. So there are options, which is great.
If you read this forum a bit you’ll find that odrive still suffers from issues like runaway motors and unintended movement, which are a huge issue when it comes to any sort of machinery. There’s also no hardware on the board to physically disable the gate drivers(for example) to safely shut down the motors, which means any stop pin can still result in unintended movement due to some software or hardware error. Thus the only really safe way to stop the board is to cut the main power.
If reliability and safety are your main concerns you’re better off looking elsewhere.
No, it’s certainly not a category 2 stop, because the drive completely shuts down in reset so it cannot be used for a powered stop. It would be closest to a category 0 stop where the motors coast to a halt, but it is NOT safety qualified or SIL rated. v4 might have STO, but highly doubtful that it will come with a certificate from TUV! Use is entirely at your own risk. As roiki said, if that’s a problem, you should be looking for industrial suppliers. Elmo are good, but expensive.
Correct - with this encoder (and any other absolute encoder) you can set the motor to pre_calibrated which means it does not make any movement on start-up. You only calibrate it once, and save the config to non-volatile memory. If the machine moves while it’s offline, that’s completely fine.
You could use the ‘mirrored’ controller mode for this- it would ensure that the second axis copies the movements of the first. Because it’s done in firmware, it’s unlikely to go wrong. A communication error won’t cause “crabbing” of your gantry.
I think I remember someone running ODrive successfully in a high-availability industrial setting, but I can’t find their post.
Thank you for the reply. Yes, I am with you and have the same concerns. I just really like the idea of the ODrive and am tempted to look into this option because it is very interesting and exciting to me. I would say reliability, while important, is not my primary concern, but I take it seriously if something I would build with great personal expense and value breaks or is severely damaged because of some glitch, that would be really depressing.
I think if I could limit the worst-case spectrum to tool destruction (for example endmills breaking) and workpiece loss, it would be more acceptable than machine damage.
When it comes to dual-motor axes, it may be an option to mechanically couple two motors with a defined compliance design (connecting shaft that may be sized for a certain twist at a certain torque to not upset the encoders but still make larger values of unsynced movement impossible) at the BLDC motor-shaft level and then proceed individually with any transmissions on the motors after this.
I disagree - I think using the reset pin (or STO when it becomes available) would be better and safer.
Imagine if you built a gantry crane, with the winch on one axis and the gantry on others… If the power failed, the load would drop, and the back-EMF from the winch motor could keep other axes active and the system wouldn’t even know that it was supposed to stop!
Unless you shorted the bus out (which would be likely to damage something) it could still run.
Whereas if there was a STO input (usually this is an opto-isolated current loop input that needs to be driven with >5mA or the drive will stop) then you could program that to do a category 0, 1 or 2 stop.
Of course, it would still have no certificate for your insurance company. But the design could be the same as an industrial drive.
You cannot have category 0 stop without physically cutting power to the motors. One way for this is to ensure mechanically that in an estop situation the gate drivers lose power and the mosfets fail to a closed position. Currently there are no hardware for this so the only way is to physically cut the power to either to board or its power supply. You can always program different failure options, resetting it via a pin is a good option but it’s not a viable failure state since the drive may perform erratically after reboot unless the board starts I a fail-safe state. This would need hardware were the microcontroller can control the power and state of the gate drivers so the motors cannot get power without being enabled first.
And you should always have a brake on a winch and never trust the motor alone. It’s the only way it can fail safely.
Nope. This is true for brushed DC motors, but NOT for synchronous (brushless) motors.
The reason being, brushed DC motors can run simply because of a short circuit to the power rail (because they have a mechanical commutator) so the only way to guarantee that they stop is to cut the power entirely.
Whereas 3 phase synchronous motors CANNOT MOVE without an electronic micro controller to do the commutation, based on an encoder input (at least, not without Hall sensors). No short-circuit is going top make them run away.
I have used 5 different brands of industrial servo drive from Elmo, Kollmorgen, Moog, Copley Controls and Siemens, and all of them had opto-isolated STO inputs rated up to SIL 3. All of them could do a category 0 stop according to IEC 60204. Some of them could do category 1, and a couple could do category 2.
And yes, I know that a “real” robot has fail-safe brakes, and a gantry crane has several oversized brakes to a new meaning of “fail-safe”, it was an illustrative example.
Oh, I forgot to say. If you hold the reset pin low (or fail to assert it high with a pull-up resistor), the microcontroller will stay off, in its most extreme low-power state. Not even the clock will be running.
It’s not edge triggered.
You also have the EN_GATE pin of the MOSFET driver chip, which will lock out the power transistors.
Then you could make a circuit which pulls the rst pin low to control the reset of the controller. If you want to anyway. I’dont see how this solves the problem. You need something more substantive to make the system safe against software issues.
I went through the manual for kollmorgen drives. Concidering the drive has separate logic input, I’d guess the drives separate the gate drivers from the controller if STO is not pulled high by external safety controller. In odrive something like this could be done by simply putting a relay on the EN_GATE pin and having the MCU check that the pin is pulled high to enable the driver ic. This way it can also be disconnected by an external safety system. Like on many servo drives. Right now none of these are an option.
If you want to do this is another question as odrive has no safety features as of now.
Well, I was thinking more along the lines of removing the pull-up resistors from RESET and EN_GATE, and connecting them to 3.3V via an e-stop button.
It wouldn’t achieve a SIL rating, but it’d be a lot better than nothing.
Like I say, hopefully the v4 board has proper STO functionality.
No, most drives (e.g. Elmo) simply disable the mosfets via the gate driver (i.e. disconnecting the EN_GATE pin) to achieve a freewheeling (cat. 0) stop. Some (Copley) disable only the high side, leaving the low-side FETs active to perform braking (i.e. cat. 1 stop) and others like Kollmorgen leave the entire bridge active, PWM running, to do a fully powered cat. 2 stop with features like “safe position”.
Therefore in Kollmorgen I believe the inputs are software driven but with a separate supervisor logic controller which will lock out the drive by more severe means (i.e. EN_GATE) and probably a mains contactor also, if they fail to stop in a given time.
