https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=7337
--- Comment #2 from dachs@xxxxxxxxxxxxxxxxxxxxxxxxx 2012-06-07 03:28:16 PDT ---
(In reply to comment #1)
> Hi,
>
> was this changed in a later release of the EtherCAT specification?
> I cannot have access to the specification on www.ethercat.org (restricted to
> members only) and the only open source library I found so far (Simple Open
> EtherCAT Master - http://soem.berlios.de/) is using the same bit order as
> Wireshark.
Hi,
I have access to the ETG specifications and there is an inconsistency:
According to the document "EtherCAT Communication" page 33 (section EtherCAT
Presentations) the order is:
CMD (8bit) | IDX (8) | ADDRESS (32) | LENGTH (11) | RESERVED (2) | CYCLIC (1) |
RESERVED (1) | MORE (1) | IRQ (16)
This order is also mentioned in a handhout of a Beckhoff Seminar for Developers
On the other hand, in the "EtherCAT Specification Part 4" section 5.4.1.2 the
order is defined
CMD (8bit) | IDX (8) | ADDRESS (32) | LENGTH (11) | RESERVED (3) | CYCLIC (1) |
MORE (1) | IRQ (16)
Tomorrow I will make a trace from our experimental setup with some ethercat
slaves to examine how the real ethercat slaves indicate a cyclic frame in the
network.
--
Configure bugmail: https://bugs.wireshark.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching all bug changes.
