Duet 3 CAN bus protocol

[oskarodrive]

Hi,

I make a servomotor controller called ODrive. Some people are using Duet together with ODrive via step/dir signals. However, this interface is very limiting, a lot of velocity and acceleration feed-forward information is thrown away from the motion controller.

I am very excited to see that Duet 3 will support a CAN connection for synchronized control from the master controller to slave boards. I am very interested to know what is sent over CAN?

I hope it is either some sort of Position Velocity Time (PVT) data, or some polynomial/spline primitives, and a time sync mechanism. This would make it possible to track the trajectories locally on the ODrive and hence have full access to the feed-forward terms. This would allow for very high performance and dynamic tracking accuracy.

Very excited to hear what is currently the plan for the CAN interface, and if there is any possibility to get early access.

Thanks!

Cheers,
Oskar

[dc42]

The message format we are currently using for CAN movement messages is here https://github.com/dc42/Duet3Expansion/blob/master/src/CAN/CanMessageFormats.h. But this will change when we implement the separate time sync protocol and S-curve acceleration.

[oskarodrive]

Thanks!

Is there any documentation as to what these parameters mean? The accel, steady and decel clocks I can guess are the timing parameters of a trapezoidal profile. I take it the actual displacement target is int32_t steps;.

What are initialSpeedFraction and finalSpeedFraction?

I think we are OK to skip the delta specific stuff for now.

[dc42]

Yes the acceleration and deceleration clocks define the time spent accelerating and decelerating. The clock frequency is currently 120MHz. I will probably change the units to microseconds to allow different clock speeds.

The initial and final speed fractions give the starting and ending speeds, as a fraction of the top speed parameter.

[oskarodrive]

Great thanks for the clarification.

What would you suggest is a good next step when it comes to implementing compatability? Are there any docs or code that pertains to the other parts of the CAN configuration?

What you said about clocks vs microseconds (or maybe nanoseconds?) would be great. Please keep us (or others that may want to implement compatibility) in mind for the future too!

Thanks!

[dc42]

Most of the rest of the CAN commands are still to be implemented. I concentrated on the movement commands because they are time-critical, unlike most other commands.

[oskarodrive]

Great, it's actually pretty much only the movement commands that would pertain to us, since we would just be implementing an axis without much else. At least to start with.

Do you think it's best to wait for the protocol to mature a bit before we start with implementation on our side? Or do you think we can get started now?

[A Former User]

Have you been in touch with the linuxcnc guys to see if you could market the expansion boards as hardware for them?

If they could interface their hardware abstraction layer to the CAN bus protocol that could be a interesting combination for a more feature complete Duet CNC solution.

[m1klos]

This post is deleted!

[elixirtrip]

Is there any news about odrive and duet 3 connection?

[A Former User]

@elixirtrip said in Duet 3 CAN bus protocol:

Is there any news about odrive and duet 3 connection?

not by means of can bus afaik, but this expansion support 1 external step/dir driver
https://www.duet3d.com/Duet3Expansion1XD