jhenning
-
Posts
15 -
Joined
-
Last visited
-
Days Won
1
Content Type
Profiles
Forums
Events
Downloads
Posts posted by jhenning
-
-
We have a CK3E (FW 2.7.0.0) with 31 EtherCAT slaves attached in a tree topology. In case a station is lost due to cable problems or power loss we would like to identify where in the tree the problem occurs. Our code is all in BGCPLCs, so a solution using C language constructs is desirable.
I have code that works:
for (j=0; j<31; j++) {
pshm->P[10] = j;
Command ("L0 = P10");
Command ("P11 = ECAT[0].Slave[L0].Online");
if (! pshm->P[11]) { fault handling }}
Unfortunately it is very compute intensive, ~600us to complete the loop. Given all the information gathering in Acontis, is there a PMAC variable or command that would immediately recognize and localize a station loss?
We could probably approach this in a more hardware-oriented way: since all stations have a digital input terminal, one line could be made always active, so if it reads 0 a station outage would be indicated, but this would be a fallback solution.
Thanks!
John
-
Upgrade to FW 2.7.0.0 fixed this problem. Thanks!
-
1
-
-
L0=nan. If I request 20 bytes, then LO=22 (slave number).
Index 361A:0 is 4 bytes in size, per AKD documentation. This command worked before in the the old project, returning a 32-bit integer representing bus voltage.
Is fw 2.7.0.0 available for CK3E? If so, how do I get it? (Haven't gotten any new fw in a long time.)
-
Hi,
We have a mature project developed on UMAC 465 fw 2.1.1.3 and IDE 2.1.0.107. The ecattypedsdo command worked as advertised on that project.
We are now porting the project to CK3E fw 2.6.1.1 and IDE 4.6.0.14. Anytime I issue ecattypedsdo in this environment I get an error message:
L0=ecattypedsdo(0,22,1,$361a,0,0,4)
requested data size: 4 and received data size: 20 do not matchThis happens regardless of the slave and object size requested. When I change the requested size to 20 bytes the command succeeds, but the results appear to be the command parameters with no useful data. The following should return DC bus voltage for a Kollmorgen AKD:
L0=ecattypedsdo(0,22,1,$361a,0,5000,20)
sys.cdata[5000]
Sys.Cdata[5000]=0
sys.cdata[5001]
Sys.Cdata[5001]=0
sys.cdata[5002]
Sys.Cdata[5002]=0
sys.cdata[5003]
Sys.Cdata[5003]=0
sys.cdata[5004]
Sys.Cdata[5004]=22
sys.cdata[5005]
Sys.Cdata[5005]=0
sys.cdata[5006]
Sys.Cdata[5006]=1
sys.cdata[5007]
Sys.Cdata[5007]=0
sys.cdata[5008]
Sys.Cdata[5008]=26
sys.cdata[5009]
Sys.Cdata[5009]=54
sys.cdata[5010]
Sys.Cdata[5010]=0
sys.cdata[5011]
Sys.Cdata[5011]=0
sys.cdata[5012]
Sys.Cdata[5012]=20
sys.cdata[5013]
Sys.Cdata[5013]=0
sys.cdata[5014]
Sys.Cdata[5014]=0
sys.cdata[5015]
Sys.Cdata[5015]=0
sys.cdata[5016]
Sys.Cdata[5016]=0
sys.cdata[5017]
Sys.Cdata[5017]=0
sys.cdata[5018]
Sys.Cdata[5018]=0
sys.cdata[5019]
Sys.Cdata[5019]=100 // not validAny suggestions?
Thanks,
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.
-
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
-
About the problem of absolute timekeeping on Power PMAC, I wonder if anyone has experience with PTPv2 (IEEE1588-2008). SourceForge among others has a daemon available for Linux. If this locks in Linux time, then Sys.TimeOfDay should keep time with the PTP grandmaster clock, right?
Hi jhenning and all,
did you manage to make the PTPd work on the PPMAC?
I understand that the HW PHP works with kernel version >= 3.19.3; does the newest PPMAC runs this linux kernel?
thanks
Piefum,
Sorry, I have not had a chance to try this out; still an open item. Let me know if you find out anything.
-
Hi,
About the problem of absolute timekeeping on Power PMAC, I wonder if anyone has experience with PTPv2 (IEEE1588-2008). SourceForge among others has a daemon available for Linux. If this locks in Linux time, then Sys.TimeOfDay should keep time with the PTP grandmaster clock, right?
Thanks!
-
Going in a somewhat different direction: does anyone have experience installing PTPd on PPMAC (source code at SourceForge)?
Thanks.
-
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?
-
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?
-
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.
-
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.
-
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.
Localizing ECAT link outages
in Power PMAC
Posted
Yes, using pshm->ECAT[0].NotAllDevsOperational to detect slave loss does make this PLC much more efficient (25% decrease in BG CPU usage) under normal conditions.
if (pshm->ECAT[0].NotAllDevsOperational) {
for (j=0; j<31; j++) {
pshm->P[10] = j;
Command ("L0 = P10");
Command ("P11 = ECAT[0].Slave[L0].Online");
if (! pshm->P[11]) { fault handling }
}
}
Thank you.