[etherlab-users] Cycle time

[Stephen Glow]

Hi Massimo;

I've reflected a bit more on the delay that you are seeing and believe I
understand the reason.  Let's step through the timing of your program
when using a 10ms update rate:

Time 0.000ms - you compose an EtherCAT frame which writes the value 1234
to the amp's process data space and also reads back the current contents
of it's output buffer.

Time 0.002ms - The message is received by the amplifier and memory is
copied to/from the shared RAM by the EtherCAT mac on the slave device.
The value currently stored in the amps outgoing buffer is 1233 (previous
data copied to shared memory).

Time 0.010ms - The response packet from the EtherCAT network is received
back at the master.

Time 0.200ms - The amplifier processes the most recent write and copies
the received value (1234) into the outgoing shared memory space.

Time 10.000ms - Your loop runs again and you compose a frame containing
the value 1235 to be sent to the amplifier.  You also check the most
recent value you've received from the amplifier and find it's equal to
1233, two cycles old.  This is the contents of the packet that was
received at time 0.010ms.

Time 10.002ms - slave's MAC receives latest frame and copies swaps data
around.  The output value sent back to the master this time is 1234
(value written by slave at time 0.200ms).

Time 10.010ms - The response packet is received back at the master

Time 10.200ms - The slave processes the latest data and writes the value
1235 to shared memory in it's MAC.

Time 20.000ms - You run your loop again and write the value 1236 out to
the drive.  The value you read back is 1234.  This is the value that you
sent to the amplifier at time 0.

As you can see, the total delay in the data from your perspective is
20ms.  The actual delay caused by the slave is only 200 microseconds.
In fact, this extra cycle of delay will be seen in any slave with an
update latency that's greater then zero, which means it will occur in
any complex EtherCAT device.

The important point to take away from this is that EtherCAT is a polled
bus.  There is an added cycle of delay caused by this polling which
should be kept in mind.  It's wise to use a short update period if you
want to receive your data in a timely manor.

Rgds,
Steve

Glow, Steve wrote:
> Hi Massimo;
>
> Something you need to keep in mind when communicating with any complex EtherCAT device is that when you read/write to process data, you are actually accessing a shared memory block used to communicate between the main processor in the target and the EtherCAT MAC layer.
>
> The processor on the EtherCAT slave will transfer values into and out of this shared memory area some some fixed update rate.  If you write values faster then the slave can consume them, then some of the data you write will be lost.  If you attempt to read data faster then the save can update it, then you will read redundant values.
>
> The update rate at which we process data on our servo amplifier is different for different objects.  Some objects are updated at our current loop rate of 16kHz.  Others are updated at the main position loop rate of 4kHz.  Some objects are handled in a background task which runs at 1kHz.  The update rate for any particular object is based on how it's used and how much calculation is required on our processor to update it.  This object prioritization allows us to make most of the drives object dictionary available for PDO mapping without jeopardizing drive performance.
>
> I tried out the example program that you posted and did notice one strange effect that I can't explain.  In the example you posted, you seem to be updating the process data every 10ms.  In your printout at the end, you show a two cycle delay in receiving a response.  This is one cycle longer then I would expect.
>
> I logged the actual EtherCAT messages being sent using wireshark and confirmed that the update values are actually being sent from the drive on the cycle following your write.  This is one cycle faster then your debug output suggests and is what I would expect from the drive.  I don't know why you are seeing the data late.
>
> The correct drive behavior can be seen fairly easily if you log the messages using wireshark.  Just find the block of messages that corresponds to your process data updates and look at when the new data is being sent back from the drive.  For a slow update period like 10ms, this should always be on the following message.
>
> Rgds,
> Steve
>
> Florian Pose wrote: 
>
> 	Hallo Massimo,
> 	
> 	On Mon, Feb 02, 2009 at 04:23:58PM +0100, Massimo Mancin wrote:
> 	  
>
> 		Some one can explain me why we have such a latency and we cannot
> 		achieve a sampling period less than 1  millisecond.
> 		    
>
> 	
> 	this is not a master limitation.
> 	
> 	  
>
> 		  Period = 100 Microseconds
> 		 Counter |Time[microSec]|TargetVelocityWrite|TargetVelocityRead|CommandedVelocity
> 		   1000  |      0       |   1000            |      0           |      0
> 		   1001  |    100       |   1001            |      0           |      0
> 		   1002  |    219       |   1002            |      0           |      0
> 		   1003  |    300       |   1003            |   1000           |      0
> 		   1004  |    400       |   1004            |   1000           |      0
> 		   1005  |    500       |   1005            |   1000           |      0
> 		   1006  |    600       |   1006            |   1000           |      0
> 		   1007  |    703       |   1007            |   1000           |      0
> 		   1008  |    800       |   1008            |   1000           |      0
> 		   1009  |    900       |   1009            |   1000           |      0
> 		   1010  |    999       |   1010            |   1000           |      0
> 		   1011  |   1099       |   1011            |   1008           |   1006
> 		    
>
> 	
> 	this looks as the Accelnet has an internal computing cycle of about 300
> 	us. I'm sure that Jim or Steven can give you a statement about this, as
> 	they know their device better than I do. ;-)
> 	
> 	BTW, you should no do this,
> 	
> 	  
>
> 		status      = (*(uint16_t*) (domain1_pd + off_accelnet_rx + 1));
> 		    
>
> 	
> 	because EtherCAT data are always little-endian. If you use the
> 	EC_READ_* macros, you are on the safe side:
> 	
> 	status = EC_READ_U16(domain1_pd + off_accelnet_rx + 1);
> 	
> 	  
>
>
> ****************************************************************
> The information transmitted in this message is confidential and may be privileged. Any review, retransmission, dissemination, or other use of this information by persons or entities other than the intended recipient is prohibited. If you are not the intended recipient, please notify Analogic Corporation immediately - by replying to this message or by sending an email to DeliveryErrors at analogic.com - and destroy all copies of this information, including any attachments, without reading or disclosing them.
>
> Thank you.
>