[etherlab-users] Cyclic Synchronous Position mode

[Graeme Foot]

Note: from your previous email you are also delaying the send to the start of the next cycle, which adds another cycle of delay.

Graeme.

From: etherlab-users [mailto:etherlab-users-bounces at etherlab.org] On Behalf Of Graeme Foot
Sent: Wednesday, 16 May 2018 10:57 AM
To: Michael Ruder <rudermi at gmx.de>; etherlab-users at etherlab.org
Subject: Re: [etherlab-users] Cyclic Synchronous Position mode


It's something like



------

t = 0.0 : master receive datagram 0, receive actual position -2

t = 0.1 : master send datagram 1 (target position 1)

t = 0.2 : drive receive datagram 1 (actual position -1 returned)

t = 0.5 : drive sync 0, target position 1 becomes active, actual position 0 is recorded

------

t = 0.0 : master receive datagram 1, receive actual position -1

t = 1.1 : master send datagram 2

t = 1.2 : drive receive datagram 2 (actual position 0 returned)

t = 1.5 : drive sync 0, target position 2 becomes active, actual position 1 is recorded

------

t = 2.0 : master receive datagram 2, receive actual position 0

t = 2.1 : master send datagram 3

t = 2.2 : drive receive datagram 3 (actual position 1 returned)

t = 2.5 : drive sync 0, target position 3 becomes active, actual position 2 is recorded

------

t = 3.0 : master receive datagram 3, receive actual position 1

t = 3.1 : master send datagram 4

t = 3.2 : drive receive datagram 4 (actual position 2 returned)

t = 3.5 : drive sync 0, target position 4 becomes active, actual position 3 is recorded





So you are comparing Target Position 4 with Actual Position 1 which, due to the sync0 time, is around 2 ½ cycles old.



What you need to do is find the Following Error PDO index, add that to your drive PDO data, and use it.



I use Yaskawa Drives so don't know what the ELMO one is (and you need to log in to get the ESI file so I can't look it up).  On the Yaskawa drive it is index 0x60F4:00.





Note: the above assumes that your master is waking at cycle time zero; the slave distributed clocks are nicely synced; you have an appropriate Sync Shift Time (say 500us); and the ecrt_master_send() is called so that the drive receives its datagram before the sync event.





Regards,

Graeme.





-----Original Message-----
From: etherlab-users [mailto:etherlab-users-bounces at etherlab.org] On Behalf Of Michael Ruder
Sent: Wednesday, 16 May 2018 4:52 AM
To: etherlab-users at etherlab.org<mailto:etherlab-users at etherlab.org>
Subject: [etherlab-users] Cyclic Synchronous Position mode



Hello,



I am currently experimenting with the Cyclic Synchronous Position mode of ELMO drives. I am using EtherLab 1.5.2 from the 1.5.2 branch with ec_generic on a PREEMPT RT system (kernel 4.14.28).



If I compare the current position the drive reports in the frame I receive after I send a frame with a new target position, I see a certain offset between this current position and the new target position that I do not understand. If I divide the offset by the current velocity, I receive a constant time delay of about 3.45 ms (which means 3.45 cycles, as we have

1 ms cycle time).



>From my understanding, the new target position should become active some time after the frame has been received (depending on several 0x1c32 values), while the inputs are sampled at some other moment (depending on serveral 0x1c33 values). This could explain the 0.45 cycles as being the delay between input sampling and activating the output value.



However, this still does not explain the 3 cycle delay. One cycle I could understand because I compare the just sent target position with the right afterwards received current position, which is from the previous cycle.

But where do the other 2 come from? I could not find any documentation about a FIFO like buffer in the drives.



Also, for precise synchronisation, I would need to know the 0.45 ms delay not just approximately by measureing it. Unfortunately, all 0x1c32/0x1c33 (index 6 and 9) are 0 for my slaves. Is there some "general" information on those delays?



I am using SYNC0 (with period 1 ms like my cycle). The SYNC0 offset does not affect the above offset, which seems however understandable as all 0x1c3x-delays are relative to the SYNC0 moment. The SYNC0 offset however does of course affect the real time moment the axis reaches the position.



Thanks for any help,

--

.      -Michael

_______________________________________________

etherlab-users mailing list

etherlab-users at etherlab.org<mailto:etherlab-users at etherlab.org>

http://lists.etherlab.org/mailman/listinfo/etherlab-users
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.etherlab.org/pipermail/etherlab-users/attachments/20180515/ddff4a43/attachment-0004.htm>