What is the mechanism of compensation-jitter or handling jitter in linuxcnc??

PCW wrote:

LinuxCNCs read inputs, process input data ,write outputs mode, Ethercat would need
2 cycles per servo thread.
 

I don't believe Ethercat is like this  With careful ordering of the addf statements, you read from ethercat, process time critical I/O and then write the current state back to ethercat in the one servo cycle. Doesn't the encoder component do something similar?

eg

addf lcec.read-all servo-thread
addf cia402.0.read-all servo-thread

addf motion-command-handler servo-thread
addf motion-controller servo-thread
addf s-pid.do-pid-calcs servo-thread
addf 0-pid.do-pid-calcs servo-thread

addf cia402.0.write-all servo-thread
addf lcec.write-all servo-thread
 

I think you are right there, rodw. And PCW is right as well.
From what I have seen there is only one read-write package (I mean, there is a package sent out with data to the client, and some 10 usec later there is a package sent back to the master with data from the client) sent and that's triggered by lcec.write-all.
If one tries to follow that
1st lcnc servo-thread cycle: do math and send data to EC client with lcec.write-all
2nd lcnc servo-thread cycle: read data from client lcec.read-all. It reads data that came as response from lcec.write-all. However, due to that small window between write and read, like some 10s usec, one may or may not be able to prepare data based on the data that was received. I tend to think that if one uses a function that is integrated in the EtherCAT controller chip, one can get a response based on the current write. If there is an MCU that does the job and communicates with the EtherCAT controller chip, than those 10 usecs are too short to receive the data to the MCU, do the real thing and write back a response to the EC client controller and prepare that for sending in a package. Meaning that the data one reads is from two cycles before (or one cycle before, you know what i mean),
3rd lcnc servo-thread cycle: Read the response from the 1st lcnc servo-thread cycle.

The consequence is that writes to the EC client are immediate, reads from the EC clients are delayed by one cycle.

Regarding jitter from the EC client view. It's seems to be up to the client to do the synchronization it wants to do, there is nothing dictated as far as I can see. The client can choose to synchronize on incoming package SM2 sync, outgoing package SM3 sync or based on clock DC sync. The Distributed clock time is available with nano-second resolution and the client can use that, but doesn't have to.
The measurements I have done show a low jitter of +-1 usec on a 1 second window (1000 1ms cycles). So, SM2 synchronization gives +- 1 usec or better in the mini test setup I have.



 

I think you have to take care here about what is linuxcnc and what is ethercat. The vast majority of ethercat installations are through large industrial complexes. CNC is a very small subset but ethercat has it covered as it can can service 100 servos in 100 usec. 

The ethercat frame (aka the bullet train) passes by a slave (eg the station) and data is unloaded and put on the train without the train stopping. So at the ethercat level, there is no concept of seperate read and write operations as it all happens at the one time.
But the issue is that linuxcnc can't handle that.. My take was more that the train is unloaded with lcec.read-all, linuxcnc does what it needs to do and then loads the train with lcec.write-all.

The servo thread executes  read-all, does all the hal stuff and then it sleeps until it is called again (every 1 kHz). How long the execution phase takes will depend on how much you are doing in hal and how fast your processor is. We observed via kernel traces on an i5 that the execution took about 200 usec. So my take is that about 200 usec after the train arrives, the station master loads it up with a bit more luggage. This luggage may not end up on the same train but another train (ethercat frame) will come along shortly after to take the luggage from the stationmaster. It is this behaviour that makes ethercat so lean when compared with other fieldbus technologies.

hello,

Yes, all of you are right i think.. but we can compare etherNET with etherCAT(it has special FPGA hardware) just in the layer of type of communication.. thats all.. they are different and therefore both are right for other stuff.. I do not know how exactly is lcec.c was written but Hakan has great truth about the cycles... ethercat does stuff in the other way... when that non stopping train is passing through the slaves, firstly output data from the actual slave are written in the free space of the train and then are input data readen... 

There should be a cycle delay but ... Sasha I. should know more about details 

what I knew from my experiences with ethercat at the industrial level, for regular purposes it should runs on 62,5us without any crutial jitter BUT only and only at beckhoff stuff masters... there is tool for this watching purpose in the twincat3 GUI.... When lcnc scan time is 1ms == 1000us, there is planty room... ethercat as protocop could do stuff faster as we need I think...

But every slave with cia402 has bit of status of cyclic communication in the its own statusword... If there will be something wrong, it will goes low immediatelly 

regards

FWIW, I'm planning on adding a test one of these days where I try to run a specific test workload with ever-decreasing cycle times to see how well we handle things and to catch regressions.

github.com/linuxcnc-ethercat/linuxcnc-ethercat/issues/342

Obviously this is of limited use; the exact hardware, drivers, power management, and workload all matter. But I suspect that we can get something useful without a huge amount of work.