Do you mean because of major changes the calibration sequence I use might be different and Arduino uart communications might not work without modifying code?
not sure I understand, would using “odrive tool dfu” revert to the 5.0.4 I’m currently using?
ah that’s good to know, I should be able to do 3 turns!
Would love some guidance on an issue I’m trying to resolve.
When a film roll completely unspools onto another, both reels start spinning fast because torque mode is still turned on for 1 second until the “no film detection” triggers and set odrive motors torque and vel to 0.
The odrive reel motors continue to spin because of inertia.
What I would like to know is how could I “brake” the reels to a stop? Right now I just use my hands and pinch the reels to a stop. If I let it spin it will stop spinning after a minute or so.
Instead of going to zero torque, you could switch to velocity mode with a setpoint of 0 instead
That works but it’s a violent stop.
This is the code I to stop the machine when the “no film detection” is triggered.
_reel0.write("controller.config.input_mode", 1);
_reel1.write("controller.config.input_mode", 1);
_reel0.write("controller.config.control_mode", CONTROL_MODE_TORQUE_CONTROL);
_reel1.write("controller.config.control_mode", CONTROL_MODE_TORQUE_CONTROL);
_reel0.write("controller.input_torque", 0);
_reel1.write("controller.input_torque", 0);
if I change to this:
odrv0.axis0.controller.config.input_mode = INPUT_MODE_VEL_RAMP
odrv0.axis0.controller.config.vel_ramp_rate = 0.5
odrv0.axis0.controller.config.control_mode = CONTROL_MODE_VELOCITY_CONTROL
odrv0.axis0.controller.input_vel = 0
odrv0.axis1.controller.config.input_mode = INPUT_MODE_VEL_RAMP
odrv0.axis1.controller.config.vel_ramp_rate = 0.5
odrv0.axis1.controller.config.control_mode = CONTROL_MODE_VELOCITY_CONTROL
odrv0.axis1.controller.input_vel = 0
It does stop but it’s an abrupt stop because the reels are spinning freely due to inertia and it has no idea of what velocity it is at , so when velocity is set to zero, it cannot ramp down, it just stops on a dime.
Not sure what I could do for this
Try lowering the gains for the velocity controller. set vel_integrator_gain to 0, and lower the proportional gain by quite a lot. (you aren’t using the position or velocity modes for anything else so doing this won’t affect your torque control)
I’m having a very strange issue -
When I rewind or forward at high velocity, with both motors in torque mode, sometimes the odrive stop working and I get this error:
In [19]: dump_errors(odrv0)
system: no error
axis0
axis: no error
motor: Error(s):
MOTOR_ERROR_UNKNOWN_TORQUE
MOTOR_ERROR_UNKNOWN_VOLTAGE_COMMAND
sensorless_estimator: no error
encoder: Error(s):
ENCODER_ERROR_ABS_SPI_COM_FAIL
controller: Error(s):
CONTROLLER_ERROR_INVALID_ESTIMATE
axis1
axis: no error
motor: no error
sensorless_estimator: no error
encoder: no error
controller: no error
This started to happen today, was fine before - what could this be?
That’s the same issue as here unfortunately
Try to keep the SPI wires away from the motor wires. Did you upgrade the firmware or not in the end?
so weird, it started happening more and more yesterday was able to run the machine all week without issues -
Thinking about it… I added two loadcells (on each reel) for measuring tension 2 days ago, which are close to the motors. Could this be interference? I think they are also SPI devices. I use the loadcells data to adjust torque values in realtime. Here are the load cell amps I use: https://www.sparkfun.com/products/13879
Would having shielded cables for both the SPI encoders and the LoadCells help me? Right now the SPI encoder cables are breaded and the loadcells cables are in a non isolate but thick sleeved 5 wire cable.
If I can’t make this work with the SPI encoders, would going back to index search encoders solve this issue? Would really love to keep SPI encoders because I’m spoiled being able to start the machine without index search and going back would be a real depressing situation.
Ok will try to move the cables a bit. I added the ferrite rings on the motor cables and did 3 turns. Should I add ferrite rings to encoder cables as well?
When I run odrivetool dfu it says I’m about to upgrade to 5.04 same version I already have so I didn’t do it - would you be able to send me a compiled firmware?
You had mentioned something about that in a post above and was not sure I understood what to do - if there’s a new 5.0.4(with the fix in) I’ll do that - Please let me know, otherwise I’m really stuck and would need help getting a compiled version.
Installed the firmware with the fix, did calibration, Still getting error although different one.
Thanks to @Wetmelon for the firmware
system: no error
axis0
axis: no error
motor: no error
sensorless_estimator: no error
encoder: no error
controller: no error
axis1
axis: Error(s):
UNKNOWN ERROR: 0x00000040
UNKNOWN ERROR: 0x00000100
UNKNOWN ERROR: 0x00000200
motor: Error(s):
MOTOR_ERROR_UNKNOWN_TORQUE
MOTOR_ERROR_UNKNOWN_VOLTAGE_COMMAND
sensorless_estimator: no error
encoder: Error(s):
ENCODER_ERROR_ABS_SPI_COM_FAIL
controller: Error(s):
CONTROLLER_ERROR_INVALID_ESTIMATE
Anything else you guys think I could try? Would really hate to go back to index search
@towen @Wetmelon Would the Odrive Pro help me with SPI encoder (or anything else to not have index search), make the anti cogging calibration easier and be more reliable overall?
If so I’ll just buy 2 now. I’m only using torque mode and nothing else.
So I tried everything I could.
After all this it still crashes with errors. So now I have to go back to CUI and that is not gonna work long term for my machine.
If you guys @Wetmelon @towen have any other suggestions I would love to try them, not sure what else can be done at this point.
EDIT: I’m back with the CUI and there’s no issues - everything good except that index search really is bad for my application.
@towen @Wetmelon so the odrive crashed again with the CUI encoders. I noticed when this odrive is connected to USB (with isolator) it was "disapearring / reconnecting by itself)
So I swapped the Odrive with a brand new one and so far everything is working, same wiring everything. I don’t have the mental strength to try the SPI encoders with this new odrive but maybe another time - I need to continue working on more pressing issues.
Can I send the board for a replacement? It was purchased September 6th 2021
that is really annoying.
What is your supply voltage btw?
I sometimes find that the SPI encoders work until I raise the supply voltage past about 40V, and then I seem to be more likely to get ERR_ABS_SPI_COM_FAIL which persists until I power-cycle the encoder itself (i.e. there is a problem with noise being coupled from the motor to the encoder which causes the encoder itself to go into an error state, and the magnitude of some kinds of EM noise goes up with the square of the supply voltage)
It would be weird if you have a dud ODrive causing this though. I suppose they are running different firmware? I suspect that is the only difference but I could be wrong.
I don’t think the ODrive team would have any objections to you sending it in for a replacement though, because they should be able to repair it pretty easily if anything is obviously wrong, and even if they can’t repair it but they can find out why not, then they have valuable info for their design. Plus I think any basic warranty policy would definitely cover something purchased less than a year ago without question, unless it had been obviously abused in some way, which yours hasn’t. 
Send an email to info@odriverobotics.com and include a link to this thread
I have a 24V 20A Mean Well PSU powering the machine.
It could be luck that it’s working right now. It was crashing randomly, do you think the power supply could be dying? I can try swapping it for a new one. Not too sure how to test if it’s dying though.
Ok cool - I’ll do that, in any case they can verify and see if it has issues and if there are none, then it will help diagnose the issues.
Actually I’ll try swapping the PSU later this week and give SPI another go, I can’t do this now though - I have major PTSD of seeing these SPI fails errors all weekend long
Lol. It’s not that bad.
Small update - Been using the machine and it’s working great but I just noticed an issue today.
Hoping to get some tips on how to sort this out. @towen and @Wetmelon if you guys have any ideas please let me know.
Here’s a pic of the machine today:
I noticed that when the machine is moving film, M0 is bumping and the bumps only happen when M1 is moving. Not noticeable at higher speed because the bumps are closer together and you can’t feel them.
For testing, if I pause the machine and rotate M1 by hand while resting my other hand on M0’s reel, I can feel the bumps. If I twist M1 faster the bumps are faster etc… M0 doesn’t affect M1 though… only M1 affects M0.
Any idea why M1 is affecting M0? And what do you think I could try? Replace encoders? Replace Motor, Recalibrate with different settings? Replace cables? Anything would help thanks very much for reading.
Here’s a video of the issue:
I asked on Discord but I figured continuing the thread here could be good too.
Here’s a small recap of what my machine does -
It’s a film scanner which operates like a tape deck. It uses an Odrive 3.6 with two D5065 motors for the reels. Both motors are set to Torque mode and their only job is to pull in opposite direction, tensioning the film in torque mode. A stepper motor act as a capstan, moving the film.
Here are more details on the configuration:
Thanks very much for reading.
Answered on Discord, but for posterity, v3.6 does have some known axis-to-axis coupling, it seems to be related to current in one motor causing sensing error in the other motor, which causes these wiggles. Unfortunately the only real fix is to use two separate ODrives, either via upgrading to Pro/S1, or two v3.6 boards.
