[etherlab-users] Etherlab 2.0 generic slave (ec_slave3) port configuration issue

[Robert Wilson]

This is a quick follow-up to my previous issue, in case it is helpful for anyone using the latest RT_PREEMPT target for Simulink. 

In the latest EtherLab revision (0d8acc30e5aa) it looks like in ecrt_support.c an offset computation gets summed twice for the conversion destination. Specifically, in ecs_start():

convert->dst =  pdo_map->domain->io_data
	      + pdo_map->offset;
	      + bytes * pdo_map->idx;

where pdo_map->offset is already updated in register_pdos() with: 

pdo_map->offset += bitlen*pdo_map->idx / 8;

If I remove the "bytes*pdo_map->idx" all of the output pdos have the correct byte alignment on the wire and all of the input pdos have the correct byte alignment in Simulink, and everything works as it did with the RTAI Simulink target. Not sure if this breaks other pdo configurations, though. 

-Rob



----- Original Message -----
From: "Robert Wilson" <rpwilson at stanford.edu>
To: etherlab-users at etherlab.org
Sent: Friday, December 21, 2012 12:00:19 PM
Subject: Etherlab 2.0 generic slave (ec_slave3) port configuration issue

Hello,

We currently have an ethercat system working in RTAI using EtherCAT master 1.5.1 and EtherLab 1.3 and have been developing this system using both the c-api and Matlab + generic slave blocks (ec_slave2) for several months without significant issues. Recently, we have become interested in moving over to RT_PREEMPT and have ported our Matlab simulation over to the development branch of Etherlab (2.0?). At this point we are able to generate code from Matlab and execute it on our realtime system, and the slaves successfully transition to the OP state and start communicating correctly with the master--i.e. the pdo is intact as reported by 'ethercat data' and also in Wireshark. However, at the output of the the Generic Slave block (ec_slave3) we are not getting the correct pdo. Instead, we get what looks like only every other byte of data concatenated together so that the byte that is usually at an offset of x1E shows up at xF, at least for the first half of the block output. In the second half of the block's output there isn't as obvious a pattern. 

Our pdo entries look something like this (using the ec_slave3 configuration convention):

[hex2dec('6000'), 1, 240
 hex2dec('6000'), 2, 240
 hex2dec('6000'), 3, 240];

and in the working RTAI system we get a vector of 90 uint8's at the output of ec_slave2.

Since the slaves seem to be configured fine and are functioning correctly with the master, we suspect there is an issue with our portconfig. Nominally, we are setting it up like this:

slaveB.PortConfig.output.pdo_data_type = 1008;
slaveB.PortConfig.output.pdo = [0*ones(30,1) zeros(30,1) 0*ones(30,1) [0:29]'
                                0*ones(30,1) zeros(30,1) 1*ones(30,1) [0:29]'
                                0*ones(30,1) zeros(30,1) 2*ones(30,1) [0:29]'
                               ];

which does not just dump our 90 bytes in order as in RTAI. We've tried changing the pdo_data_type to boolean and packing the uint8's in Matlab with the same result. We've also tried the system in both 32 and 64 bit ubuntu, on 3.2 and 2.6 kernels, and with both the development and stable master and get the same issue. 

Has anyone seen this issue before? Thought I would ping the list before diving into the ec_slave3 code. Our current thought is that there might be a troublesome data cast somewhere, but I'm hoping we just made a silly mistake in the port configuration. Thoughts?


I also have a more general question concerning the use of the generic slave blocks--is it possible to execute multiple reads or writes during a single servo cycle? I'm interested in doing a read at the beginning of the servo cycle, performing control calculations, and then doing a write before going to sleep, but I can only seem to get one big packet per servo cycle regardless of Simulink block order or domain configuration. This is building a large delay into our control loop. An alternative plan is to run the generic slave block as fast as possible and decimate our control loop, but a read-modify-write approach would be preferable.


Thanks!
-Rob Wilson