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@etherlab.org http://lists.etherlab.org/mailman/listinfo/etherlab-users
