>       Well actually not. A full period of jitter then using average
>       time over 100 samples is 1% or about if not exact 1/n=(100/n)%
>       of jitter. 
> 
> The ethernet controller of the processor has a clock with a very
> fine-grained control of the time. Currently this clock takes 3 seconds
> to lock to the PC clock. Once locked it is very stable ...  But there
> is also the PWM frequency, which determines the sampling time of the
> position and motor currents. I want all the drives to sample the position
> at exactly the same time. For this I want to sample just before the next
> data from the PC arrives. This way both the encoder data and the ethernet
> packet arrive simultaneously and the current control loop has everything
> up-to-date for the next computation.  After the current control loop
> has finished it sends the status back to the PC.

I make it a little bit different. PC and micro controller is running at 
slightly different clock so there is only a need to compensate for clock drift. 
I use micro controller internal clock  and use arrival times to compensate for 
the clock drift.

The problem is I have no way to make PC send Ethernet packets with an accurate 
clock but with this method it is running smoothly anyway although with some 
extra delay.


> What using the timer brings, is that it allows me to compensate for the
> delay from the sigwait to the actual sending of the packet. By
> reading the timer with timer_gettime.

My method compensate for all jitter in between clock used to trigger servo loop 
in PC to micro controller internal clock although with some extra delay.


>       I have done this for stepper and have also written about how
>       to do it with decimal point to reduce jitter then running servo
>       loop at similar rate as stepper pulses.
> 
>       What protocol do you use for Ethernet?

I use a slightly modified Hostmot2 driver, stepper generators have been 
modified to send/receive positions encoder style in both directions. I am 
pretty sure messages are sent via UDP.

I am however thinking about CANopen messages over Ethernet, probably via UDP/IP 
since the dictionary and SDO communication would be very useful for parameters 
and it may be used to set parameters manually without following a standard for 
the entries, only the SDO messages.

The thing with the CANopen dictionary is it have an electronic datasheet so 
that a configuration tool could be used to access named parameters in the 
device. The name is in the dictionary while the micro controller only use 
numbers. Do anybody know about any similar protocol which may be used on 
Ethernet?


> Currently it is an ad-hoc protocol over UDP. One port is used for
> the timing and the PC broadcasts sync packets. I want to change this
> protocol to PTP, but also use the hardware time-stamping of the ethernet
> controller on the PC. Both will take some effort ad will have to come
> after I've finished the mechanics. Currently there is no compensation
> for propagation delay which causes one drive to sample slightly earlier
> than the other, and swapping the ports on the switch causes the order
> to change. The delay is well below 1us, so not an issue for mechanical
> systems like milling machines and lathes.
> 
> Since the PTP protcol has to be mixed with the real-time control I need
> to do something with scheduling. The TDMA driver included in RTNET is not
> "suitable" because the UDP packets are tagged differently and the ethernet
> controller in the microcontroller is not able to do all the checks. I
> also use a switch, instead of a HUB which also makes the TDMA sub-optimal.
> The drives have a 100Mb link and the PC had 1Gb.

As far as I understand PTP protocol is for very accurate clock synchronization?


> The other port is the data for the control loop which is just a struct
> sent with every UDP packet, and changed at will.  If, for some reason,
> I want to add a protocol I'll use another port.

Here I am thinking about CANopen. PDOs used for real time protocol is 
practically the same as sending a struct although byte order is defined, there 
are no padding and there exists standard communication profiles there the data 
is defined although it is usually possible to change by configuration. SDO and 
EDS electronic datasheet is however standardized so it is possible to access 
standardized or custom parameters in micro controller with a standard protocol.


Regards Nicklas Karlsson

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
_______________________________________________
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers

Reply via email to