Hi there, I’m attempting to make a small CNC lathe, and before I place an order, I’d like to know if odrive can the situation that I have here.
In short, I want to run a bldc motor with an odrive, then use a gear reduction to the main spindle shaft, and then run an optical encoder on that main shaft. The bldc motor and spindle shaft are linked with a PJ belt to reduce noise. The ratio of the motor and encoder is chosen so that i get a nice integer CPR.
I’ve had this setup with a NEMA-34 stepper motor running, but apparently the belts can slip just a tiny bit when I’m doing stainless steel and crazy things like that. That makes threading impossible. If it slips, I would like ODrive to handle the situation - or if things get terrible in a short amount of time, issue an alarm because then I probably pushed the thing too much…
I’ve read the information in the docs, but can’t figure out how ODrive would handle slippage. Is that just a recipe for disaster or will it be corrected?
With some constraints, this is totally feasible on ODrive Pro/S1, as both support dual encoder feedback
In short, you’d have the optical encoder on the motor, set up as the “commutation encoder” - that’s the encoder that the ODrive uses to commutate the motor, and must be directly linked to the ODrive. However, you’d then add an encoder to the main spindle shaft, and set that up as the “load encoder.” After which, all pos/vel control on the ODrive would operate off of the load encoder output – so it’ll compensate for belt slippage.
Three things to note here:
You’ll want a high-resolution load encoder - the higher the resolution, the quicker that deviations in desired pos/vel can be caught
You’ll have to switch over from velocity control while turning to position control while tapping, synchronized with your lathe’s z-axis
If your belt can’t handle the torque, then there’s nothing the ODrive can do
Other than those considerations, I don’t know why this couldn’t work! On your main motion controller, you could poll pos_setpoint vs pos_vel_mapper.pos_rel and throw an error (and shutdown the system) if things deviate past a margin you feel comfortable with.
Note that when transitioning from velocity to position control, you’ll need to read pos_rel to get the current position, and then set your position setpoints while tapping as an offset from that position. Alternatively, if your load encoder is an absolute encoder or has an index, you could set up circular position control. I’d generally recommend that latter method.
Note that only ODrive Pro has support for two quadrature encoders - on S1 you could use a quadrature encoder for the load encoder and an RS485 encoder for the commutation encoder (such as the RS485 encoder sold in our shop) - that way you additionally don’t have to run an encoder offset calibration on system startup (as you would with an incremental / non-absolute commutation encoder).
Switching over from position to velocity control is not a problem for me. I wrote a large part of the cnc firmware that I work on (fluidnc) so I’m perfectly happy to write a bit of code that switches between modes to get it up and running. I could even work with just position control and do the math in the planner. At the end of the day I probably need to compensate the feed rate with the position anyways.
“You’ll want a high-resolution load encoder - the higher the resolution, the quicker that deviations in desired pos/vel can be caught” – what’s the max rate that odrive can capture? I mean, the motor can spin up to 4k rpm; given the x4 quadrature and x1.8 gear, a simple 500 cpr will already yield 28.8 * 500 = 240kHz. What’s the limit that odrive supports for encoder frequency?
As for the motor itself, it already comes with “honeywell hall sensors” whatever that might mean. Unfortunately these are not precise. And unfortunately they used shear-off bolts during the fabrication, just to make my life miserable. I’m going to give it a shot to replace the encoder, but I’m not sure that’s viable in this case. That also means I’m very space limited in what I can do with encoders on the motor itself; spi consumes so little space that it might work I suppose. I’m not sure if that’s preferable due to lag.
“If your belt can’t handle the torque, then there’s nothing the ODrive can do” – heh. Life’s tough.
Switching over from position to velocity control is not a problem for me. I wrote a large part of the cnc firmware that I work on (fluidnc) so I’m perfectly happy to write a bit of code that switches between modes to get it up and running
Awesome!
what’s the max rate that odrive can capture?
2.5MHz on each line, which makes 10 MHz count per second with 4x quadrature decoding. Something like the AMT102 sold on the shop could work - it can do 7500 RPM at a 2048 PPR setting - so that’s about 136kHz on the line at 4000 RPM, with a total resolution of 8192 CPR.
If your motor has hall sensors, you’re probably fine as long as your load encoder is decent. SPI lag is pretty negligible though, and it’s all compensated in the ODrive – so if you can toss something on the motor’s shaft then I wouldn’t dissuade you. The OA1 or AMT212-V-OD either could work fine too, depending on what sort of mounting works best (end of shaft or through bore).
What motor is it specifically? Could have an idea based on that.
Thanks, I can work with that. Any 5k ppr quadrature encoder would work fine I suppose.
This is an industrial Nema-34 BLDC motor, part number JK86BLS84. They are also sold by other vendors with different type numbers. I removed the SS41f hall sensors today since they won’t do me much good.
I made some code earlier for AS5047 SPI encoders, so I’m just going to see if that works first. The thing I’m worried most about here is the EMI caused by the big fat motor, which could very well interfere with the 3.3v SPI interface. I would be a bit scared of using rs485 here for the same reason, but since BLDC’s all have that problem I suppose that’s well tested. That being the case, AMT212B just won’t fit the 12.7mm shaft. Only one way to find out I suppose.
