I’d like to integrate ODrive with a Duet 3 6HC controller via CAN bus, the 50kHz step pulse rate on the ODrive is too slow to have both high speed and high encoder resolution (2^14).
Is there any documentation on integrating the CAN FD from Duet with the ‘CAN Simple’ on the ODrive? If anyone has tried this please share your progress
I asked this question on the duet forums about the feasibility of integration and one of the admins responded ‘it should be possible’ so there is some hope there, but I was unable to get any additional information.
I’ve seen on discord that the v4 will have CAN FD, but as I have the v3.6, I would prefer not to have to purchase another (or wait until it comes out) if at all possible.
CAN-FD is a different hardware implementation of the CAN hardware. Odrive doesnt have the hardware to use CAN-FD frames so you’d need to implement a CAN-FD driver board drivers on the odrive that can talk with the duet board and then implement the duet can protocol on the odrive to understand what the duet is talking.
Or use a separate microcontroller to do the can-simple - CAN-FD translation.
No, you would have to use something like a teensy4 that has both can2.0 and can-fd transceivers built in, add a driver chip and then program it yourself.
Or add a can-fd interface IC like mcp2518 to odrive, program an SPI driver for it and then program a duet compatible can protocol interface for odrive.
On a hardware level can-fd can talk to can2.0(which is what odrive has) if the message field in the can frame is only 8 bytes long and the wire speed is 1mbit at most. This is up to the duet board but as they don’t publish protocol specs i can’t say for certain.
Careful, the CAN FD transceivers are largely the same as the CAN 2.0b transceivers. There are some certified for FD but I think most of the 2.0b ones work anyway
It’s the CAN controllers that are different. ODrive uses a CAN controller that’s built into the ARM processor. You can buy external controllers that could communicate over SPI, but then you’d have to write a whole new software stack for this in the ODrive firmware.
@Merlin246 What problem are you trying to solve? Do you wan to send commands to ODrive or receive encoder feedback? And at what rate? 1kHz on ODrive’s CAN is not a problem.
@Wetmelon I am trying to use the maximum encoder (AS5047P via SPI) resolution of 2^14 CPR (1/2^14 turns/step) while maintaining the ability to travel at high speeds. The step/dir interface limit of 50kHz allows for maximum speeds of ~3 turns/s at this encoder resolution which is far too slow.
Yeah you can just use the basic CAN commands, or UART, or whatever. It should work fine with the Duet, you’ll just have to tell it your device is a CAN 2.0b device so it can’t go too fast. I assume that’s implemented on the Duet?
Honestly, I have no idea. I haven’t spent any time in the firmware files for Duet. I wanted to see if it was feasible to do so, then start getting into it. Is there a way on the ODrive to set specific data sequences to specific commands or is it hard-coded?
You can’t dynamically add CAN commands. They are defined in Firmware/communication/can/CANsimple.cpp - you could always add your own commands in there.
I believe duets can goes close to the 12mbit max limit. The reason they went with can-FD and wrote their own protocol was that CANOpen and can2.0 was simply not fast enough for the motion command rates that they wanted to achieve.
I had a look at the duet source Here and looking at the formats, duet makes extensive use of the extended message format of can-fd. The movement command itself(line 82) is 4 32bit ints which comes out to 16 bytes if im not mistaken. Can2.0 has a limit of 8 bytes. So it seems you either need a can-fd controller on the odrive or modification to duet source to create a message that conforms to the can2.0 limits.
Further the duet protocol contains time syncs and uses prescheduling and timing based motion commands so you would have to implement the relevant timers and protocol from scratch. The duet controller also seems to expect some return from the drive before it can be used.
Thanks for looking into this and the analysis. It looks like this is beyond my capabilities of modification as I don’t have the faintest of where to start implementing a can fd controller on the odrive.
The only thing that might be possible for me is editing the message sending, but with the time syncs, prescheduling and timing based motion that adds another layer of complexity.
I think, based on the lack of documentation and info, that they don’t really want others doing drivers or accessories compatible to them. The implementation is really unique(reminds me a lot of klipper) and handles motion totally differently to something like cia402. Which is the standard in automation. Which makes adaptation a somewhat laborious task.
I’m not married to Duet by any means, but I’m most familiar with their environment as its really the only thing I’ve used to configure ~15 printers, likely with more to be done in the future. Also their web interface is beautiful.
Is there a motion controller alternative that works well with ODrive via something other than step/dir?
No since step/dir is the only standard interface it supports. Also most motion controllers that support something other than step/dir are in the professional sector. Which means expensive.
I misinterpreted the question… I was talking in general what the Duet is talking to, not necessarily via CAN. For CAN, it would just be talking to the ODrive, it also uses CAN to communicate to any expansion boards, but I don’t use any.
We wanted originally go the CAN route for connecting the Odrives to the Duet board. But because of the incompatibility issue, we had to implement our system with step/dir signals. Not perfect, but just good enough for now.
I can confirm, that it is possible to implement CAN on Duet, but it is not priority in Duet’s firmware development due to low demand. It could be commisioned as custom development though. Unfortunately we can’t afford it at current stage.
So, but is CAN-FD going to be part of Odrive v4? Are there any other specs published yet
