My device will have a long cable from the control to the Y axis. so SPI noise may be problematic, dunno. Cable will be over 12 feet. When you say “move a bit”, can you elaborate on “a bit”. 2 encoder steps, 2 revolutions of the motor, how much? I need to know if I need to plan for a vibration at my tool or a move that must be dealt with to prevent a crash.
I need to read up on encoders, I’ve only ever used plain step motors and encoders are new to me. I appreciate you sharing that detail.
If you use an incremental encoder without an index, the motor will have to move roughly 2 revolutions to calibrate the offset between the encoder and motor phases. With an incremental encoder that has an index pin, like the AMT102-V in the store, the motor only has to rotate until the index position is hit. That will always be less than 1 whole revolution.
For your application, something like a CNC xy gantry, the startup sequence might look like this:
This only happens at the Odrive board’s power-up, right? What happens if the BLDC motor can’t move, due to machine limits, I assume it’s gonna keep trying. A stepper would just give that horrible lost step noise, while it applies a lot of force. I have no experience with the BLDC.
In the case of a machine limit being reached, is there any way to trigger a limit switch and have ti try to calibrate in the other direction? Or at the least cause a reset/stop.
ODrive does support some limit switch functionality, but I’m not sure if it’s integrated into the calibration sequence. If the motor hits a limit during calibration, the ODrive will just error out and stop. The calibration doesn’t happen automatically on startup unless you configure the ODrive to do so, so the comments about the Arduino are a way for you to have some control over that process based on if the machine is ready for calibration or not.
Thanks. Sounds like I need to get one to play with.
You can hook up a limit switch to the Z pin to pretend to be the index pin, as long as there’s no slippage.
Not following how this would work?
When the axis attempts to find the index pin, it would run into the limit switch which is connected to the Encoder Z pin on the Odrive. The ODrive thinks this is the index from the encoder. This works as long as the relative position between the motor angle and homing switch never changes (i.e. no belt slippage)
Ah. I think I get it now. And I’d wire in parallel so if the system did a startup away from the switch it would find the index pin first and that becomes it’s reference. But if it hit he limit switch subsequently, it would think it was off track and that could be a problem.
The device I’m moving is a 3rd party machine, I have limited control over it directly. It has 3 states, 1. engaged (with workpiece) and idle, 2. disengaged and idle, and 3. ready to operate upon movement (engaged). So, it could be in the worst case which is engaged but idle state, at startup, so that fact may make using the BLDC a non-starter anyway. Unless I can find a way to ensure it is in a disengaged state before this required homing routine, which may not be possible.
Assuming I cannot mechanically detect the engaged state, if the system does a worst case 99% turn to a index point, something will break or be damaged. So that’s no good. Unless the system can operate at very low torque for this startup routine? I mean low enough that it would slip with the tinyest of resistance and fail initialization if the state was engaged. Possible?
You want to use one or the other, not in parallel. It should always hit the reference at the exact same electrical angle every time.
The torque needed is surprisingly high during the “lockin” movement, actually. It sounds like you need an absolute encoder, though, if it can’t move a little bit during startup. We are working on a solution that should work for long-distance (your 12 foot wire won’t be a problem) encoder setups. You’ll just need an ethernet cable.
I can make a CAT6 shielded cable, not problem. That, I know how to do LOL. But I thought the absolute encoder needed a couple of revolutions for startup, worse in my case than the indexed encoder.
From above: 'If you use an incremental encoder without an index, the motor will have to move roughly 2 revolutions to calibrate the offset between the encoder and motor phases. "
I’m misunderstanding something maybe.
For me, it’s fundamental that the machine ONLY moves when I direct it to move. Ever.
My bad there, I might not have been clear when I said that. There are three good options: Incremental encoder without index signal (worst case for amount of motion required before the motors will accept commands), incremental encoder with index signal (less movement), absolute encoder (no movement).
Thanks guys. Yes I missed the absolute encoder as a no move option. Had to go look up the differences but now I understand. And boy are they proud of those encoders LOL. ($$$) Have any recommendations for one similar to your CUI indexed encoder?
Unfortunately all of the encoder options that work with ODrive natively are susceptible to noise, except the one we’re putting together. What’s your timeline?
In product development stage. Timeline depends on success at prototyping.
Hi, gonna jump in here since this thread is similar to what we need…
Been away from this project for a little while - is absolute position control now implemented with the new FW and something like AMT23 encoder? We have a short (< 1m) cable run from encoder to ODrive so noise maybe not an issue for us?
My company (Systematic Creation) will purchase dozens of these systems if we can get it working nicely without too much dev work.
Thanks!
Yes, absolute encoders are working, but I strongly recommend a differential transceiver for off-board SPI comms
Thanks very much for your advice, Wetmelon.