search

OpenEtherCATsociety / SOEM

Simple Open Source EtherCAT Master
Other
1.23k stars 653 forks source link

Use of ec_dcsync0 CyclShift #790

Open mtc199 opened 3 months ago

mtc199 commented 3 months ago

Is CyclShift intended to be set differently for each slave?

Background: SOEM based master on microcontroller variable number of servo drive slaves, various brands, CSP mode variable number of I/O slaves using Beckhoff SSC distributed clock used on all slaves distributed clock tracking PI loop on master keeps SYNC0 jitter at about 220ns simple EtherCAT chain under 16 devices, 1 port / not redundant if servo drive documents specify a shift, it is typically 0 or don't care master has been setting one CyclShift (0) for all slaves, which I'm now thinking is incorrect

There are various timing diagrams which show what is supposed to happen, such as the one on the poster under DC unit: https://www.ethercat.org/download/documents/EtherCAT_Device_Protocol_Poster.pdf ...or the one at the top of this page: https://infosys.beckhoff.com/english.php?content=../content/1033/tc3_io_intro/1446579467.html&id=

These diagrams show EtherCAT end of frame (EoF) before DCSYNC0 event. In the SSC slaves I sometimes encounter problems with, SYNC0 may occur within the EtherCAT frame reception time. This can cause failures depending on where the slave is in the EtherCAT chain. I'm now thinking I was supposed to use CyclShift on a per slave basis to position SYNC0 after the EtherCAT Frame. Is this the correct method to investigate?

I'm guessing the master has the information to calculate a safe shift value. Maybe some combination of slavelist[i].pdelay, 0x1C32:06, 0x1C33:06, 1C33:09, or something in the 0x0900s can calculate the shift?

Thank you for any suggestions.

ArthurKetels commented 3 months ago

The first thing that strikes me is the use of multiple servo slaves in CSP mode. This will result in mediocre control performance, and a world of hurt in corner cases. It is just not a clever thing to use position mode in multiple axis. But I digress.

In precision control the process values and time are equally important. It is no use to know exactly "how much" when you do not know "when". The distributed clock and hardware sync of EtherCAT take care of the "when". All partners in the control system have a common understanding of time.

But the physical transport of bits over a wire costs time. So when multiple slaves are connected in a loop, the first gets the data from the master sooner than the last. Also the number of slaves will impact the size of the data packets to be transmitted. And as the slave can only process the data after the last bit has been received, this will add to the delay (between master data ready, and slave data processed).

The use of SYNC in a slave makes the data transport from master to slave discrete. When SYNC fires the assumption is that the data from the master has already arrived in full. When it works this simplifies the inner control loops in the slave because the received data compared to the previous cycle is assumed to have constant delta time.

It is easy to see that at larger slave systems this guarantee is difficult to hold with all SYNC units firing at the same time. Hence the SYNC delay function, where the SYNC is still synchronous with the cycle time but offset. Slaves positioned later in the chain or having larger copy&paste times have their SYNC offset as to allow optimal time between data reception and SYNC events.

This can indeed be pre calculated by the master application by using the measured propagation delay and the known paste&copy time of the slave. But do not be surprised when there is no solution possible at high cycle rates and many slaves. Also think about what happens when a packet gets corrupted. There is no physical system that is perfect.

To make things more complicated there is also a data path back from the slaves to the master, and here the timing offsets are reversed. Some times this does not matter, but often it does.

For starters it is a simple algorithm that takes the propagation delay as only factor in the SYNC shift. This mostly works well. The second step is to add the copy&paste time of the slave. The issue is that many slaves do not have this value populated, or it is not reliable. And sometimes you do want to have two slaves exactly synchronized.

Still, I see the whole synchronized control loop as something from the 80-s. It is much better to timestamp all sensor data (the real capture time), and set-points (at effective execute time), and then use the EtherCAT bus asynchronous. In physics nothing happens at exactly the same time, so don't pretend it is. The slave can with the help of the time stamps and a Kalman filter predict what the most likely values are in the near future. Even when the parameters of the control loop have all different time-stamps, jitter and cycle time. It also can cope much better with dynamic changes in timing.

mtc199 commented 3 months ago

Thank you for taking the time to make a lengthy reply. I will read it again, but at this time I don't fully understand all the suggestions provided. While attempting to use EtherCAT, I have found plenty of documentation. Unfortunately, what I find is either high level (almost marketing) or low level (down in the registers). The middle area of intended setup for particular use cases or relevant examples eludes me. I am certainly not to the point where I think my choices are clever. I hate to clog up this issue system with general questions, but I have pursued other routes without any actionable answers. From your answer, at least I know that adjusting SYNC shift for each slave is a reasonable thing to try.

If position modes are not the way to go, that would rule out PP, IP, and CSP. This leaves PV, CSV, or CST. Is a torque or velocity mode considered a modern way to do multi axis coordinated motion? My current assignment is to run EtherCAT drives from a system that has roots in the '90s. I would like to consider or study what is state of the art. However, the choices in the current project are mostly driven by compatibility concerns.

ArthurKetels commented 3 months ago

the choices in the current project are mostly driven by compatibility concerns You just have to work with what you got. I get your point.

However we can still talk about fundamental principles. In physics force controls velocity, and velocity controls position. Therefore when your high level controller sends position setpoints to the motor controllers, it will no longer be able to control the velocity or even less the force. And yes when controlling position you very damn well have to get the timing exact. A small deviation in timing (let alone skipping a cycle) will lead to large velocity errors, and even larger force errors. This due to the differentiation effect.

On the other hand if you send torque commands to the servo controllers, then an error in setpoint will have little effect on velocity and position due to the integration effect. And disturbances like friction, slip-stick and resonance all happen in the force domain.

I grand you that implementing a system based on force control is much more effort than a simple position setpoint generator. Then again the rewards are also much higher.