NTP time synchronization for parallel movements of multiple motors about ethersweep

[Duckle29]

I just saw this pop up on youtube and it's interesting.

I think you'd want to use a setup that supports IEEE 1588 PTP which is a way to synchronize clocks on a network to sub-microsecond level.

It requires a phy that supports it, and I'm unsure if the wiznet phy+mac supports it.

One approach could be a new version of this that uses an STM32F107xx which has a built in Ethernet MAC with 1588 support, however the support seems weirdly undocumented from a quick google. It does however also have CAN, so the software stack if using that MCU could easily support swapping the ethernet phy for a CAN phy.

I'm unsure if the phy also needs support for this, but something like the Ti DP83640 Does implement it. (Ti AN-1729)

[Duckle29]

I did some more digging on the F107, and it does seem like it'd be a fair bit of work to implement, but seems fun. I found This TCP/IP stack that supports it.

It doesn't suppor the DP83640, but if you're lucky it's close enough to the supported dp83848. If not then there's the implementation of that to go off of to add support for the 83640 :P

[Neumi]

This is some valuable information. I also thought a bit about using an STM with built-in ethernet, but in the end didn't find a good solution to the hardware layout. The W5500 sits on the top board and only SPI has to go through the pin headers. Sending the ethernet lines through them wouldn't work I suppose (+ EMI/EMC problems). The other option would be to have the uC on the top board as well and route everything else down. But then the space on the top board is pretty much gone.
But would be worth a try! I always wanted to play around with the built in Ethernet and CAN stuff anyway! :D
Replacing the W5500 would of course be no problem. I choose it because it is widely used, has good drivers, is cheap and everywhere in stock. (I also didn't want to take a deep dive into networking + physical layer stuff :D) I might make use of the hardware interrupt pin (pin 36 on W5500) to get better packet timing. This is currently just connected, but not used in software as for now. This might help with some latency issues (at least the latency that originates from the uC code doing something else ;)).

[Duckle29]

Yeah, honestly doing the digging on the F107 it seemed cool.... and a LOT of work 😅

[Neumi]

I just checked the F107.... It would be very hard to get them on one board without double-sided assembly. And even with double-sided assembly the THT RJ45 and the F107 would not fit side by side on the board. But I would like to keep the THT RJ45 for stability reasons... The F107 with a smaller form factor like some BGA would be great :D

[PhilCowley]

To get synchronised movement, could you not try a two stage solution. First send the requested position/speed etc. to each motor, then, once all the motors are ready, send a broadcast "go" signal? This would remove any requirement for an NTP server on the network and any requirements to update RTCs in the controllers.

[Duckle29]

I haven't really looked in to this more since, but I did brush by some comparisons of hardware PtP like that (very expensive) Ti phy does, compared to software only PtP.

Might be much more interesting to see what kind of sync you can achieve with just a software solution?
I found this: https://github.com/mpthompson/stm32_ptpd

[asteppke]

Just as a reference for the discussion: With a direct Ethernet connection without special hardware and using NTP one can expect synchronization accuracies below 1ms. For many motion control tasks this is already sufficient. Servo PID loops for example often run with 1 kHz.

With PTP in a pure software mode one can achieve accuracies below 10us, and with dedicated hardware below 100ns.

The effort of a software NTP client implementation is quite small, even from scratch. A dedicated hardware approach looks like overkill here. If there is an easy to port PTP software client that might be beneficial but NTP would cover a lot of potential use cases.