CAN Latency and practical application

[wayneosdias]

I ordered a 6HC rather impulsively as my current controller was beginning to fail. Having used a Duet 2 wifi with great success in the past I just assumed the 6HC supported step/drive signals to drive external drivers. Once I discovered this was not the case I impulsively ordered x2 1XD Expansion Boards. Then I read of the CAN latency issue and impulsively ordered a Mini 5+ as that board natively supports x2 off-board drivers. I now have a 6HC + x2 1XD expansions and a Mini 5+.

Taking a step back and looking at the best possible solution. My machine is a PnP that rapids large XY distances with a fairly heavy head. It requires >36V XY drivers with encoding hence the need for the offboard drivers.

The more I think about CAN latency it in practical terms; If the XY is driven by the 6HC + XDs and the CAN latency only manifests as a slightly off Homing of XY this should not be an issue. So long as the XY are not Homed at a rate so fast to overrun the limit switch, once Homed, latency is no longer an issue given that;
-Work Offset is almost never at home, or at least never on my machine and doesnt require any correction of overstep.
-Work Offset or Job reference is ultimately determined by visual calibration.
-Since component pick up and orientation is automated with vision, vision settling time can be adjusted to compensate for any XY deviation due to CAN latency.
Is that accurate?

Lastly the only thing Im not terribly sure of is that OpenPnp has 'Smoothing' options requiring a lot of velocity/trajectory updating in the XY plane. Is it conceivable that the increased gcode planner updating for smoothing could overrun the CAN? Does the 6HC buffering handle this?

I really like the speed of the 6HC Ethernet and like it to be the solution. If anyone could shed some light on any of this it would be greatly appreciated.

Thanks Wayne

[rjenkinsgb]

As far as I am aware, the CAN latency only affected such as "instantaneous" signals between two boards, like an axis limit or probe on one board relating to an axis motor on a different board.

In normal operation, all commands are queued ahead of time and then executed synchronously by all boards.

That's what caused a problem with a switch/probe detection, as the motor board would still be executing the move for a few milliseconds before the probe signal reached it.

I believe even that is now a non-issue, and the axis will take the correct position from the switch trigger point.

Even without that, a simple solution is a two stage home, backing off a fraction then a very slow move on to the switch again, so the distance moved during any delay is irrelevant.

[dc42]

@wayneosdias it's as @rjenkinsgb said in his reply.

[wayneosdias]

Thanks for the explanation. So if I understand correctly, if a CAN driven axis has its limit switch local to the CAN board and not the Main board, there is no latency issue at all?

[rjenkinsgb]

@wayneosdias said in CAN Latency and practical application:

So if I understand correctly, if a CAN driven axis has its limit switch local to the CAN board and not the Main board, there is no latency issue at all?

Correct, as I understand it.

And, as of the recent betas, the endstop position is also correct even with remote switches; any overshoot will be cancelled automatically.

[deckingman]

@wayneosdias If it's of any help, I have a CoreXYUVAB (3 XY gantries) with 6 extruders running a 6HC main board and three 3HC expansion boards. The XY and Z motors are connected to a 3HC expansion board and the UVA&B motors are connected to the 6HC main board. The 6 extruders are connected to the other two 3HC expansion boards. The end stops for all those axes are scattered around between the various boards and not necessarily connected to the same board as the motors. Latency for homing Z was initially a bit of an issue but that was resolved over a year ago and everything is "fine and dandy" now.

[dc42]

@wayneosdias said in CAN Latency and practical application:

Thanks for the explanation. So if I understand correctly, if a CAN driven axis has its limit switch local to the CAN board and not the Main board, there is no latency issue at all?

No, because the limit switch triggering is still processed by the main board.

[wayneosdias]

@dc42 said in CAN Latency and practical application:

@wayneosdias said in CAN Latency and practical application:

Thanks for the explanation. So if I understand correctly, if a CAN driven axis has its limit switch local to the CAN board and not the Main board, there is no latency issue at all?

No, because the limit switch triggering is still processed by the main board.

Understood, Thank you.