Jump to content
OMRON Forums

jhenning

Members
  • Posts

    15
  • Joined

  • Last visited

  • Days Won

    1

jhenning last won the day on December 14 2022

jhenning had the most liked content!

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

jhenning's Achievements

Apprentice

Apprentice (3/14)

  • First Post
  • Collaborator Rare
  • Conversation Starter
  • Week One Done
  • One Month Later

Recent Badges

1

Reputation

  1. 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.
  2. 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
  3. Upgrade to FW 2.7.0.0 fixed this problem. Thanks!
  4. 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.)
  5. 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 match This 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 valid Any suggestions? Thanks, John
  6. 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.
  7. 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
  8. 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.
  9. 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!
  10. Going in a somewhat different direction: does anyone have experience installing PTPd on PPMAC (source code at SourceForge)? Thanks.
  11. Thank you! This looks promising. I will pursue it and report back with the results.
  12. 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?
  13. 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.
  14. 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.
×
×
  • Create New...