Thread Rating:
  • 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
(resolved) semaphore control on ECAT IOBuffer
#1
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
Reply
#2
Most customers do not have issues with timing in PLCs. Timing for motion is handled by firmware and IO is usually less important. What are you trying to accomplish?
Does your EtherCAT network have a distributed clock or is it free run?

If you just want to verify all data is from the same EtherCAT cycle you should be able to check the value of Sys.ServoCount before and after copying the values into holding registers.
If you want your code to run every EtherCAT cycle guaranteed you would be looking at writing a different type of program. (PLC 0 or Servo Routine)
You could make a custom servo routine to copy all values to where a PLC could use them, but then that servo routine could interrupt the PLC and you would have to do the same check.
Reply
#3
(12-23-2020, 05:10 PM)Eric Hotchkiss Wrote: Most customers do not have issues with timing in PLCs. Timing for motion is handled by firmware and IO is usually less important. What are you trying to accomplish?
Does your EtherCAT network have a distributed clock or is it free run?

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.

(12-23-2020, 05:10 PM)Eric Hotchkiss Wrote: If you just want to verify all data is from the same EtherCAT cycle you should be able to check the value of Sys.ServoCount before and after copying the values into holding registers.

Good idea! I will check it out to see if it fixes my current problem.

(12-23-2020, 05:10 PM)Eric Hotchkiss Wrote: If you want your code to run every EtherCAT cycle guaranteed you would be looking at writing a different type of program. (PLC 0 or Servo Routine)
You could make a custom servo routine to copy all values to where a PLC could use them, but then that servo routine could interrupt the PLC and you would have to do the same check.

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.
Reply
#4
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:

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.
Code:
#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.
Reply


Forum Jump:


Users browsing this thread: 1 Guest(s)