-
Content count
6 -
Joined
-
Last visited
Community Reputation
0 NeutralAbout Mark Short
-
Rank
Newbie
Profile Information
- Country United Kingdom
-
Mark Short liked a post in a topic: Redundant Owner field in Network Connection Parameters
-
Mark Short started following Redundant Owner field in Network Connection Parameters
-
Redundant Owner field in Network Connection Parameters
Mark Short posted a topic in Allen Bradley / Rockwell Automation
In the Forward Open message of EtherNet/IP, there are two Network Connection Parameters, one for Originator->Target, the other for Target->Originator. Volume 1 of the CIP specification (3-5.4.1.1) describes the fields of the Network Connection Parameter. It explains the role Redundant Owner field for the Originator->Target direction, but makes no mention of its role for Target->Originator. Am I right to assume that the Redundant Owner field has no role in the Target->Originator direction, and is ignored? -
Mark Short liked a post in a topic: Reading and Writing I/O tags in PLC
-
Mark Short liked a post in a topic: EtherNet/IP - Multiple Service Packet
-
EtherNet/IP - Multiple Service Packet
Mark Short posted a topic in Allen Bradley / Rockwell Automation
I am developing software in C++ to communicate with Allen Bradley devices using EtherNet/IP.To improve performance, I am using the Multiple Service Packet service to encapsulate (i.e. bundle together) many Read Tag services. I restrict the number of services I encapsulate so that neither the request nor the reply exceeds the connection size.It works OK most of the time, but occasionally I get a Multiple Service Packet replay with General Status = Embedded Service Error, and the last two of the encapsulated Read Tag replies have General Status = Partial Transfer. I interpret this as the ControlLogix device saying that the message it's been asked to generate is too large for its connection size. In this error case, the reply would occupy 4002 bytes, and the connection size is 4002 bytes, so I would expect it to be OK. The ControlLogix seems able to create messages up to 3992 bytes in size.I measure the reply size by counting (inclusively) from the CIP sequence count to the end of the packet. This is based upon my interpretation of Volume 1 of the CIP Spec, section 3-5.4.1.1, where connection size is defined.Any suggestions why the ControlLogix device is unhappy generating a message of 4002 bytes? -
Mark Short liked a post in a topic: Controllogix CIP with SCADA using Large Forward Open Connected Messaging
-
Allen Bradley Ethernet/IP Mapping Size Limit?
Mark Short replied to Chris Elston's topic in Allen Bradley / Rockwell Automation
FWIW my experience with the Large Forward Open service and Allen Bradley devices is that the Logix range will only support a connection size of about 4000 bytes, whereas the Micro800 devices support the full 65511 byte connection size. -
Forward Open Response message format
Mark Short replied to Mark Short's topic in Allen Bradley / Rockwell Automation
I went back to the Wireshark traces, and looked at the actual bytes sent/received, and they do correspond with the CIP specification. The Request Path that I couldn't understand only appears in Wireshark's translation of the raw bytes. So I think Wireshark is not translating CIP correctly. -
Mark Short liked a post in a topic: Forward Open Response message format
-
Mark Short changed their profile photo
-
Forward Open Response message format
Mark Short posted a topic in Allen Bradley / Rockwell Automation
I am working on software to communicate with Allen Bradley PLCs via EtherNet/IP. I'm very much in the foothills at the moment, trying to figure out how connect to the PLC using the Forward Open message, by looking at Wireshark traces between Rockwell's Connected Components Workbench and Micro 850 device . The Forward Open request makes sense, but the Forward Open response has a Request Path in it that I can't make sense of. It appears after the Additional Status Size field. The definition of the Message Router Response in the CIP spec doesn't include a path (but the Message Router Request does). After the Request Path comes the Forward Open Response bytes, which is what I expect to see. It does occur to me that my copy of the spec might be out of date. I have Volume 1 Common Industrial Protocol (CIP), Edition 3.3, dated November 2007. (I've looked on the OVDA site, and haven't found out what the latest version is.) Or is it that I just haven't understood the gnarly structure of CIP messages correctly? Thanks in advance.