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" <[email protected]>
To: [email protected]
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
_______________________________________________
etherlab-users mailing list
[email protected]
http://lists.etherlab.org/mailman/listinfo/etherlab-users
