Absolute time in PPMAC

Hello,

 

Our application requires access to real-world time (UTC) from hours through microseconds each pass through the servo routine.

 

We are considering:

GPS receiver --> (PTPv2) --> Beckhoff EL6688/EK1100 --> (EtherCAT Distributed Clock) --> PPMAC as EtherCAT master.

 

Some questions:

 

+ Has the EL6688/EK1100 combo been demonstrated to provide absolute time to PPMAC? I believe this has been discussed in other threads but haven't seen a resolution.

 

+ What variable holds the absolute time? If Sys.TimeOfDay, what is the mechanism to keep Linux time synchronized with the EtherCAT reference clock? Or EtherCAT registers 0x0910 - 0x0916 (how would these be accessed from PPMAC)? Or something else?

 

Alternatively, once UTC is set in the servo task, am I correct that it can be incremented accurately with a precision pulse stream fed to a time-base input on our ACC-24E2A servo board to maintain time? We would still need to set the starting UTC accurately.

 

Are other timekeeping mechanisms available for Power PMAC so our application can can have access to accurate absolute time? I am new to PPMAC and it appears relative timekeeping is well-supported, but we need absolute.

 

Thank you.

We will have to gather our Linux jocks and EtherCAT jocks when they return to the office to answer this one.

 

Many users have used the EtherCAT distributed clock feature to keep the PPMAC servo update in sync with the signal returned from the EtherCAT source (we modulate the setting of the circuitry that creates our internal clock to keep it from drifting off). But you are correct -- that is relative time. Note that this technique can modify the physical time between consecutive servo interrupts.

 

Many of our observatory users have fed a precision pulse stream into an input on an axis card like the ACC-24E2A as a "time-base input", as you note. This technique does not change the physical time between consecutive servo clocks, but allows us to count the number of pulses between consecutive clock cycles, and make the velocity of the programmed moves proportional to the number of pulses received. This has worked very well to keep moves from drifting off over time -- but again, this is relative time.

 

We will have to be very careful to distinguish, but still coordinate, the external reference time from "Linux time" (which updates based on processor clock cycles), and PMAC move time, which updates based on hardware-generated servo clock updates.

Many of our observatory users have fed a precision pulse stream into an input on an axis card like the ACC-24E2A as a "time-base input", as you note. This technique does not change the physical time between consecutive servo clocks, but allows us to count the number of pulses between consecutive clock cycles, and make the velocity of the programmed moves proportional to the number of pulses received. This has worked very well to keep moves from drifting off over time -- but again, this is relative time.

 

We use an external timing board (Spectracom Tsync) to trigger the DeltaTau via the time-base trigger mechanism. We then use the same card to generate a pulse stream synchronized to absolute time as described above via the external time-base mechanism. This allows us to both trigger at a matched absolute time and remain synchronized to it.

 

We've also tried to synchronize our DT to an EL6688 via ethercat but were not able to get things going. I think it's possible and we were working with Henry and Atul at Delta Tau to this end. I ran out of time on the project though and haven't been able to return to it - perhaps things are further along now.

Curt, abeard,

 

Thanks for your replies. Our application is indeed for an observatory. The Spectracom board is interesting, since it might be able to generate a programmed pulse rate compatible with a sidereal clock (subject to verification; the granularity of frequency-setting may be too coarse).

 

If we use a pulse stream into the 24E2A for time-base input, does the frequency need to be substantially higher than the servo interrupt rate to get precise results, since we are counting an integer number of pulses? or are the counts interpolated?

 

I am still very interested to hear from the "jocks" about reading in absolute time. This would be a useful capability.

Historically, the "pulse-stream" time-base input is how most observatory users have kept the PMAC synchronized to an external reference time. There is timer-based interpolation on the pulse counting, so PMAC can calculate, for instance, that 23 and 47/256 pulses have been received in the most recent servo cycle.

 

With or without the interpolation, there is no long-term drift regardless of the input frequency relative to the servo frequency, because over the long term, it is just a counting process. We do generally recommend that the input frequency be substantially higher than the servo frequency, but that is for smoothness of motion executed under the time base, as higher frequency reduces quantization noise in computing the pulses received per servo cycle.

 

The "trigger" feature abeard talks about can be very important, as it sets a very accurate starting time (T0), latching the counter value in PMAC at the instant it is received, so all subsequent times can be referenced to this.

 

I will call the above technique the "hardware method". It is probably the simplest. As to the "software method":

 

The Sys.TimeOfDay element references a standard Linux function. It can be written to using a C API call (but not from the Script environment). It can be tied to an external time using standard Network Time Protocol (NTP) functionality, just as your PC's time is likely tied to your network server using this method. We have a number of users doing this. This communication happens through the standard Ethernet "host port" on the PMAC.

 

To do what you want, we will have to keep both the Linux time and the servo time in the PMAC synchronized to your external source. The servo heartbeat can automatically be tied to the EL6688 through the "distributed clock" EtherCAT feature we have implemented. Many users utilize this feature to keep PMAC's servo software properly synchronized with the hardware on the EtherCAT network.

 

What has not been done yet is to implement any software to utilize the numerical absolute time information that would come in from the module to keep Sys.TimeOfDay (or something similar) from drifting off, and to make this information accessible from the servo software in a way you can properly utilize it -- I presume for functions like data gathering to properly time stamp the logged data. This looks like a substantial task requiring knowledge of EtherCAT, the module, Linux, and Power PMAC.

Historically, the "pulse-stream" time-base input is how most observatory users have kept the PMAC synchronized to an external reference time. There is timer-based interpolation on the pulse counting, so PMAC can calculate, for instance, that 23 and 47/256 pulses have been received in the most recent servo cycle.

 

With or without the interpolation, there is no long-term drift regardless of the input frequency relative to the servo frequency, because over the long term, it is just a counting process. We do generally recommend that the input frequency be substantially higher than the servo frequency, but that is for smoothness of motion executed under the time base, as higher frequency reduces quantization noise in computing the pulses received per servo cycle.

 

The "trigger" feature abeard talks about can be very important, as it sets a very accurate starting time (T0), latching the counter value in PMAC at the instant it is received, so all subsequent times can be referenced to this.

 

I will call the above technique the "hardware method". It is probably the simplest. As to the "software method":

 

The Sys.TimeOfDay element references a standard Linux function. It can be written to using a C API call (but not from the Script environment). It can be tied to an external time using standard Network Time Protocol (NTP) functionality, just as your PC's time is likely tied to your network server using this method. We have a number of users doing this. This communication happens through the standard Ethernet "host port" on the PMAC.

 

To do what you want, we will have to keep both the Linux time and the servo time in the PMAC synchronized to your external source. The servo heartbeat can automatically be tied to the EL6688 through the "distributed clock" EtherCAT feature we have implemented. Many users utilize this feature to keep PMAC's servo software properly synchronized with the hardware on the EtherCAT network.

 

What has not been done yet is to implement any software to utilize the numerical absolute time information that would come in from the module to keep Sys.TimeOfDay (or something similar) from drifting off, and to make this information accessible from the servo software in a way you can properly utilize it -- I presume for functions like data gathering to properly time stamp the logged data. This looks like a substantial task requiring knowledge of EtherCAT, the module, Linux, and Power PMAC.

OK, the hardware method looks like a reasonable approach.

 

Still, it would be great to read absolute UTC at will. Beckhoff documentation talks about EtherCAT registers $0910-$0917 containing nanoseconds since Jan 1, 2000. Is an image of these registers available in PPMAC, or can they somehow be read from the EK1100 coupler?

Firstly, I have not used the Beckhoff EL6688 EtherCAT Slave.

 

However, if it provides UTC data on Indexes $0910-$0917, our master will read that data. It is a matter of mapping the Indexes of interest to the PPMAC using the System Setup utility in our IDE. It is a fairly straight forward procedure that is supported with a GUI. Once mapped the data will be written to a PPMAC structure of the form:

 

Ecat[j].IO[i].Data // for each of the mapped Indexes

 

At this point, the mapped data is available in PPMAC to do with as you please.

 

OK, the hardware method looks like a reasonable approach.

 

...read absolute UTC... EtherCAT registers $0910-$0917 containing nanoseconds since Jan 1, 2000. ...can they...be read from the EK1100/EL6688?

Thank you! This looks promising. I will pursue it and report back with the results.

 

Firstly, I have not used the Beckhoff EL6688 EtherCAT Slave.

 

However, if it provides UTC data on Indexes $0910-$0917, our master will read that data. It is a matter of mapping the Indexes of interest to the PPMAC using the System Setup utility in our IDE. It is a fairly straight forward procedure that is supported with a GUI. Once mapped the data will be written to a PPMAC structure of the form:

 

Ecat[j].IO[i].Data // for each of the mapped Indexes

 

At this point, the mapped data is available in PPMAC to do with as you please.

 

OK, the hardware method looks like a reasonable approach.

 

...read absolute UTC... EtherCAT registers $0910-$0917 containing nanoseconds since Jan 1, 2000. ...can they...be read from the EK1100/EL6688?

Hi Curt,

 

I am in the process of figuring out a way to sync our PMAC to UTC time as well. Idealy I would like to send commands to the PMAC with a timestamp ahead of time and have the PMAC execute those commands on those timestamps.

 

Right now were synchronizing the PMAC based on times that commands are sent and knowing that they're supposed to be sent at 50 ms intervals (the time stamps aren't sent with the commands).

 

What is the simplest way to sync the PMAC to UTC time that has been proven by any of your customers?

 

thanks,

windell

 

Historically, the "pulse-stream" time-base input is how most observatory users have kept the PMAC synchronized to an external reference time. There is timer-based interpolation on the pulse counting, so PMAC can calculate, for instance, that 23 and 47/256 pulses have been received in the most recent servo cycle.

 

With or without the interpolation, there is no long-term drift regardless of the input frequency relative to the servo frequency, because over the long term, it is just a counting process. We do generally recommend that the input frequency be substantially higher than the servo frequency, but that is for smoothness of motion executed under the time base, as higher frequency reduces quantization noise in computing the pulses received per servo cycle.

 

The "trigger" feature abeard talks about can be very important, as it sets a very accurate starting time (T0), latching the counter value in PMAC at the instant it is received, so all subsequent times can be referenced to this.

 

I will call the above technique the "hardware method". It is probably the simplest. As to the "software method":

 

The Sys.TimeOfDay element references a standard Linux function. It can be written to using a C API call (but not from the Script environment). It can be tied to an external time using standard Network Time Protocol (NTP) functionality, just as your PC's time is likely tied to your network server using this method. We have a number of users doing this. This communication happens through the standard Ethernet "host port" on the PMAC.

 

To do what you want, we will have to keep both the Linux time and the servo time in the PMAC synchronized to your external source. The servo heartbeat can automatically be tied to the EL6688 through the "distributed clock" EtherCAT feature we have implemented. Many users utilize this feature to keep PMAC's servo software properly synchronized with the hardware on the EtherCAT network.

 

What has not been done yet is to implement any software to utilize the numerical absolute time information that would come in from the module to keep Sys.TimeOfDay (or something similar) from drifting off, and to make this information accessible from the servo software in a way you can properly utilize it -- I presume for functions like data gathering to properly time stamp the logged data. This looks like a substantial task requiring knowledge of EtherCAT, the module, Linux, and Power PMAC.

Going in a somewhat different direction: does anyone have experience installing PTPd on PPMAC (source code at SourceForge)?

 

Thanks.

Hi,

 

Some progress to report. We are locking the EL6688 module to a GPS PTPv2 master clock. EtherCAT PDOs include internal and external time stamps at $10F4:17 and $10F4:18 (there is some small difference between them that needs to be understood); this is 64-bit time since Jan 1, 2000 in nanoseconds and will not roll over for 500+years. This is not system time as such, but it is available to tasks as an absolute time resource.

 

-John

An update on the previous post: the external time stamp is only updated when a PTP sync message is received (currently 1 sec interval, appears to 0.5 sec minimum with PTPv2). Update is signaled by $10f4:0f toggling between 0 and 1 [note: subindexes above are decimal, not hex]. So some other timer will have to be used to interpolate between time stamp refreshes. The internal time stamp appears to be the distributed clock, but it updates at the same rate. The EL6688 manual (v2.1, p82) says that additional offsets need to be added to get absolute UTC.