Short update
- I got new belts for 100€ instead of 300€
- I’ve ordered springs
- I am strengthening the error sanity checks
- I add an electric safety (if more than X amps are delivered by power supply, power supply is immediately witched off)
And most importantly
- I got rid of the PC, python and USB interface. I opted for an arduino mega, RS232 interface and the OdriveArduino I modified for my needs.
There was quite some work to rewrite the trajectory planing algorithm that fits the constraints of the arduino board. I’m streaming position commands at 100Hz. I now have the system working for a few hours and it seems rather stable… I guess we will continue to turn on “Odrive radio” (having the machine working non stop for hours) for a few days to build the trust again.
Yeah and I also did
- Order alternatives to odrive, including from roboteq and ingeniamc.com . In both cases their professional support seems just right by the way.
1 Like
Good to hear you’re making progress! If you end up finding that the UART is a bit noisy, you can always get a CAN shield for the Mega and run CAN. You may also want to consider upgrading to a Yun or a Teensy or STM32uino… all of which will run Arduino code, but have much faster 32-bit ARM processors.
I also had this problem, but I also found the solution, do you by any chance use multi-threading in your python ?
Well, I do, and I was calling the “odrv0” object from two different threads (on set the speed and the other was collecting information), and we all know that reading/writing to a shared object from multiple threads can cause a collision, so I made sure to call lock.acquire() and release.
Blockquote
Global variable
lock = threading.Lock()
Inside the threads (example)
lock.acquire()
if odrv0.axis1.current_state != AXIS_STATE_CLOSED_LOOP_CONTROL:
odrv0.axis1.requested_state = AXIS_STATE_CLOSED_LOOP_CONTROL
lock.release()
Blockquote
and the issues went away.
1 Like
Thanks for pointing that out. I was not using multi threading. Besides, I am also pretty sure there was no odrivetool nor any process I am aware of that would access the odrive.
Anyway, my python code is dead code now.
For the record, we have been testing the uart/arduino interface for several hours over several days now. The instability seems gone. But we will better now when the real usecase starts, hopefully in a few days.
Unfortunately the real test is postponed until late August at best 
I’ll update with results once we have seen the beast running for a few days
1 Like
Well I guess the topic name might be seriously misleading now 
We are having the odrive-powered machine back in pre-production stage since last Monday. After several dozen pallets in the lab to fine tune the behavior.
Today we cut about 500 boxes with it. No particular issue.
The whole thing seems rather stable. Such tests will continue this week and likely next week too. But at the moment it’s being manually loaded with boxes.
Then likely in November/December we will change the current prod layout to connect the main conveyor directly to the machine. And then we will finally know if we can test odrive for a serious industrial setup in a torture-like usecase.
If everything goes well – and maybe even if it doesn’t – I may write an entire article entitled “box cutter / an odrive story”
@madcowswe would you be interested ?
What branch are you using, btw? Master firmware?
the default fw that you can download from the main site.
the binary i can see in our directory (along with sha1sum) is
fe0c15963bfbdeda33135d78ac4644a147a83792 *ODriveFirmware_v3.5-48V_0.4.10.elf
we are using odrive 3.5 in 48v version i beleive
[edit] I made the decision to never touch the odrive firmware and always use master/production fw. [/edit]
1 Like
we got about 2200 boxes cut with the machine in the last few days. and still counting.
it’s a manual “test and validation” setup for the moment. Meaning that the machine is parallel to the main conveyor belt and they manually take boxes from the main belt, get them through the box cutter, and manuall get the newly cut box back on the belt.
We still have a few issues with non-standard boxes that get jammed in the machine (no relationship with odrive). We need to get that under control prior to connecting to the main belt to the machine.
but overall it’s looking good.
1 Like
Loss of USB communication might be because of the power supply of Odrive not providing enough current. That was the reason I was getting this error while trying to calibrate the motors.