[etherlab-users] Is this a bug? Large networks using multiple datagrams!

[Aaron Edsinger]

Hi Shahbaz. We have also encountered issues with >1 datagram systems but 
never looked into it deeply. Ours may be a different issue, but it looks 
similar. Our work around was to simply split the data across multiple 
domains (and at a higher loop rate).

Please let me know if you learn more about the issue.

--Aaron

On 3/2/12 6:34 AM, Shahbaz Yousefi wrote:
> Hi,
>
> We have been observing some strange behavior with the ethercat network 
> that I wanted to bring to your attention. We are not sure if it has 
> something to do with the master or the slaves.
>
> First, let me explain what we do. We are building a robotic skin (so 
> now, you may remember me). Right now, we don't have a real large skin, 
> so we have decided to test our network with fake sensors.
>
> Here is the setup:
>
> Imagine 2 slaves, each of them producing data for 600 pdo-entries (in 
> 50 pdos) each producing 16 bits of data. They are both in the same domain.
>
> After configuring the network, this is the master's log:
>
> ... EtherCAT: Requesting master 0...
> ... EtherCAT: Successfully requested master 0.
> ... EtherCAT 0: Domain0: Logical address 0x00000000, 2400 byte, 
> expected working counter 2.
> ... EtherCAT 0:   Datagram domain0-0: Logical offset 0x00000000, 1200 
> byte, type LRD.
> ... EtherCAT 0:   Datagram domain0-1200: Logical offset 0x000004b0, 
> 1200 byte, type LRD.
> ... EtherCAT 0: Master thread exited.
> ... EtherCAT 0: Starting EtherCAT-OP thread.
>
> As you can see, the master needs to send two datagrams to retrieve 
> data from the whole skin. Having more than 1 datagram is indeed what 
> we are aiming at testing.
>
> The strange behavior that we observed was that the first 600 values 
> (that corresponds to the first datagram) were correct, but the second 
> one was total gibberish.
>
> Now we added another slave to the end of the network, this one 
> connected to a small piece of skin with 72 pdo-entries (in 6 pdos). 
> That is, the data of the slaves are divided in 1200-1200-144 bytes. 
> Here is the master's log of this network:
>
> ... EtherCAT: Requesting master 0...
> ... EtherCAT: Successfully requested master 0.
> ... EtherCAT 0: Domain0: Logical address 0x00000000, 2544 byte, 
> expected working counter 3.
> ... EtherCAT 0:   Datagram domain0-0: Logical offset 0x00000000, 1200 
> byte, type LRD.
> ... EtherCAT 0:   Datagram domain0-1200: Logical offset 0x000004b0, 
> 1344 byte, type LRD.
> ... EtherCAT 0: Master thread exited.
> ... EtherCAT 0: Starting EtherCAT-OP thread.
>
> The result was this:
>
> - The first 600 values (corresponding to the first datagram) were correct
> - The second 600 values (corresponding to the first 600 values of the 
> second datagram) were gibberish
> - The last 72 values (corresponding to 72 values at the end of the 
> second datagram) were showing values of the second slave (Which should 
> have been in the second 600 values)
> - The data from the last slave was nowhere to be found
>
> *My question is, has the master ever been tested with networks that 
> require more than one datagram to collect data?* If not, can you 
> please test it (like us, you can have the slave pretend there are a 
> lot of sensors) and see if you get the same behavior?
>
> *If this is not a master's bug, do you have any idea how such a thing 
> might happen?!*
>
> The way it looks, it seems like the second slave thinks it should 
> write data from byte 1200 to 2400 on the second datagram. Indeed, it 
> should write from bytes 1200 to 2400 of the whole data being 
> exchanged, which is byte 0 to 1200 of the second datagram, since the 
> first datagram has 1200 bytes of data already. Could it be that the 
> master is sending wrong configuration to the slaves?
>
> The master we are using is one that was downloaded from the 
> development branch on Feb 6 2012.
>
>
> _______________________________________________
> etherlab-users mailing list
> etherlab-users at etherlab.org
> http://lists.etherlab.org/mailman/listinfo/etherlab-users

-- 
Aaron Edsinger, Ph.D.
Meka Robotics
San Francisco, CA
415.206.0131 (Ph)
415.994.0727 (Cell)
www.mekabot.com
www.csail.mit.edu/~edsinger

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.etherlab.org/pipermail/etherlab-users/attachments/20120302/bb3995a9/attachment-0005.htm>