daviddein

Sorry for the much delayed response, but here is a copy of the ESI. This issue is still happening in the latest version of the IDE. Note: I had to change the file extension because it wouldn't let me upload xml. Copley_BEL_4.12_rev3.txt

Curt, On a separate, but related issue. I am trying to figure out if I am working inside an edge case or if I need to look elsewhere with regards to a CK3E ethercat master device. Setup: CK3E -> Copley BEL -> Rotary stage with 8419.5555555... cts/deg In CSP Mode, everything seems to work generally 'fine' above the int32 limit of the target position PDO getting through several rollovers, but gets faults around 20 billion counts (~2.4M degrees). I am assuming that in a buffer, the gcode target position in text form gets converted to a 64-bit float, multiplied by the target unit conversion, then cast into int32 to put in the PDO for the discrete encoder count target; with regard to rollover the Copley seems to auto-magically handle that without any issues. Is that correct or is the math sequence a little different?

So, is this something I am setting up incorrectly (wrong checkbox or other), or is it a bug? I am doing some development work, and whenever I change the bus configuration I have to go in and manually fix all of these 'errors' in the auto-generated ecatconfig files so my project can compile correctly.

PowerPMAC Version 4.4.1.7

I am no wizard in C or delta tau language in general, but I included the ECATMap.h file in my bgcplc that had some nifty pshm pointers that I wanted to use. I had issues when trying to use the unique #defines concerning IOBuffer's, and I kept getting compile errors stating: expected ';' before 'pshm' looking at my ECATMap.h file: #define Slave_1003_EL1252_1003_1D09_16_SysTime (x) pshm->ECAT[0].IOBuffer[32 + x] removing the space before a '(x)' fixed my compile error #define Slave_1003_EL1252_1003_1D09_16_SysTime(x) pshm->ECAT[0].IOBuffer[32 + x] Is this an auto-generation bug? This is similarly occuring in the ECATMap.pmh file as well.

From my observations, normal PLC's run at the servo tick, so doing a sequential read on the IOBuffer bytes took a little over 30 cycles, with a jitter of a Servo tick for some reason; obviously not what I want! I was able to pull over the IOBuffer data very quickly using bgcplc's with the following code: //grab the data quickly max_diff_servo = pshm->ServoCount; int i = 0; while(i<8){ bytes_in[i] = Slave_1003_EL1252_1003_1D09_16_SysTime(i); i++; } max_diff_servo = pshm->ServoCount - max_diff_servo; Slave_1003*** is a #define in my ECATMap.h file from when I set up my ethercat ENI file. peculiarly, any #define which points to an IOBuffer address is formatted incorrectly when it gets auto-generated. For instance, this is the ECATMap.h entry that gets auto generated, which gives me compile errors. #define Slave_1003_EL1252_1003_1D09_16_SysTime (x) pshm->ECAT[0].IOBuffer[32 + x] Remove the space before the (x) make the problem go away.

The primary issue was that I was updating my trigger time on my Beckhoff 2252 I/O slice with a delta tau local variable, which is a double data type. After 18.23 minutes of time from start of the controller, a double doesn't have the precision to represent the last 64us of time. This gave me the false indication that timing was not working properly, when in fact it was working the entire time I was just uploading a start time that was incorrect. To fix, I used two local variables representing the upper and lower of my 64-bit nanosecond time when I want the I/O slice to trigger, and copied that number over to the ethercat bus.

Thank you for the help. The ultimate problem was the math I was using. I was utilizing IOBuffer to pump data over to the slave device. Not aware that the local variable trigger_time was in fact a double, truncating of the data seems to be occuring as I attempt to slice it back into pieces to fit in the IOBuffer array. Code segment below. //transfer toggle time to output byte index=0; while(index<8){ buffidx = byte_shift_time_trigger + index; ECAT[0].IOBuffer[buffidx] = trigger_time>>(index*8); //this line must be wrong index++; } I saw the problem when inspecting "watch ethercat mapped variables", the 64 bit word over time had its LSB's go to FF. Now to fix it...

Hey, so... I am looking to keep various EtherCAT slaves in sync and the default settings in PowerPMAC IDE for an Acontis CK3E appear to work for about 10-20 minutes. Within this goldy locks zone of operation, I can time I/O slice input and outputs, watch system times from slave devices, and get a maximum offset or jitter of 0.8us; this is on par with the DC sync characteristics I get when utilizing the same hardware setup in TwinCAT. After 10-20 minutes of operation of the CK3E master, the timing of my I/O slices immediately becomes indeterminate and I start seeing jitters as high as 65us. This appears to correspond with the task manager reported "EtherCAT Tasks" CPU percentage time (4khz rate * 27% utilization = 67.5us). To me, this alludes to a timing conflict between the EtherCAT servo tick and the DC Sync pulse; but I can't be certain since I don't know how to monitor either of these processes. A vast majority of the ECAT[].Slave[].DCxxxx variables have no context for Acontis, only for Etherlab stack so I don't even know what dial to turn or button to push to see whats going on under the hood of the Acontis master. CK3E Firmware Version 2.5.4.0 PowerPMAC IDE 4.4.1.7 Slave Hardware: Beckhoff EK1100 Bus coupler Beckhoff EL1252 Input Module Beckhoff EL2252 Output Module Copley BEL-090-06 Troubleshooting steps that have not provided any gains: 1. clear config, start from scratch. 2. changing servo rate (4khz to 2khz) 3. changing ethercat rate (4khz to 2khz) 4. setting slave distributed clocks to different cycle rates with an appropriate offset 5. power cycling the slaves (not the master) 6. ecat reset 7. adjusting DC timing variables (plus,minus,kp,ki,refband) 8. change dc to master shift or bus shift. Any help is greatly appreciated, David

I am trying to ensure a IOBuffer read (or write) occurs in a single servo cycle, and doesn't cross into another cycle. Only an issue because data >32 bits is mapped to IOBuffer. In this instance I/O is just as important as motion. Good idea! I will check it out to see if it fixes my current problem. Thank you for the other avenues. Checking the sys.servocount is probably the path forward for my needs. If I determine that I truly need a guaranteed write on a servo cycle I will try these recommendations.

Hi yall, I've been pouring over the software reference manual, but could not find what I was looking for with regard to data control for EtherCAT data exchange. I am not intimately familiar with how PLC's operate, so I am assuming that there is always the possibility that a sequential read/write, from and to, the ECAT IOBuffer's may happen over a cycle or two; so some kind of semaphore control or block mechanism to ensure execution in one cycle would be useful in ensuring data isn't exchanged by the EtherCAT cyclic routine in the middle of my PLC. I would like to utilize a PLC and the program command structure that comes with it, but if I have to use a C function I suppose I may have to ensure data integrity. Any suggestions? David

Andrea, I copied the contents of ECATConfig.cfg into ECATMap.pmh and it worked like a charm! Thank you! I just need to add it to my process now, so that I don't forget. Regards, David EDIT: As an added note, the modification to the *.pmh works just fine, however I encountered an error on the first ECAT[].IO[] definition when attempting to upload. De-activating ethercat network, and then uploading solves this problem. It appears that writing some ECAT[] params while the bus is active is not permissible.

Hey, So I am working with a CK3E running the Ethercat Acontis Stack, and I am trying to get my EK1100 with a EL1252 I/O slice data to be mapped correctly to the proper IOBuffer and IO.Data register so I can use it in my user program. As a specific example, PowerPMAC IDE maps my ethercat slave, and I have PDO's with data representing the status of the input (single bit) and the latched time events when the input goes high or low (64 bit ns time). I will focus in on the negative latch time PDO for input 2. From the ECATConfig.cfg file -------------------------------------------------- ECAT[0].IO[4103].BitLength=64 ECAT[0].IO[4103].Data=24 ECAT[0].IO[4103].Index=7433 ECAT[0].IO[4103].SubIndex=200 ECAT[0].IO[4103].Input=1 ECAT[0].IO[4103].Offset=43 ECAT[0].IO[4103].BitPosition=0 ECAT[0].IO[4103].Slave=1 From the ECATMap.pmh file -------------------------------------------------- #define Slave_1002_EL1252_1005_1D09_200_LatchNeg2 (x) ECAT[0].IOBuffer[24 + x] Initially, everything works when I right click on my Ethercat master -> Load Mapping to Power PMAC. ECAT[0].IO[4100].Data and then go view the cyclic PDO in "Watch Ethercat Mapped Variables". I download and save all program files, save, and then reset the controller. However, after a reset, my mapped variables no longer updates to a correct value, its just zero as if no data is being pumped into IOBuffer. Inspecting the manual, IOBuffer uses ECAT[x].IO[x].Data as a storage variable for the offset when looking for the start address of any data bigger than 32 bits. Reading ECAT[0].IO[4103].Data, the value is 0 which is wrong according to ECATConfig.cfg, it should be 24. Setting ECAT[0].IO[4103].Data=24, and ECAT[0].IOBuffer[24 + x] now returns the correct data (reverse ordered, but that is a separate issue than the current one). What I can't understand is why .data is not sticking to 24 and is being set to zero after a power cycle; and I am wondering if it possible to re-upload ECATConfig.cfg after a power cycle or reset? Any help is greatly appreciated, Regards, David