Hi Greg, as you seem to have experience with EtherNet/IP ... could you eventually have a look at what I'm doing in the feature/etherenet-ip branch?
Here the "ManualPlc4XEtherNetIpTest" class is an example where I connect to a eip device with the connection String: eip://10.10.64.30:44818 and try to read the address: #4#105#3 Where: #4#105#3 means (Class number 4), (Instance number 105) and (Attribute number 3) The Web-UI of the device tells me the instance numbers and the convention tells me #4 is the assembly object. I got the attribute #3 from an EIP Explorer tool I used to generally connect to the device in the first place (I used this to capture the traffic with Wireshark and compare that to what I've been doing). Does this Address Format make sense? Is there a publicly accepted convention to writing down EIP Addresses? Is the "attribute # 3" also a convention? Chris Am 21.08.18, 02:50 schrieb "Greg Trasuk" <[email protected]>: Hi Cris: It’s been a while, but a long time ago I wrote an Ethernet/IP driver for Allen-Bradley’s ControlLogix PLC. So I might be able to help a little. I’m trying to find the code, so I can donate it or at least let you look at it if you’d like (I wrote the code while operating my company which is now 10 years defunct). Some answers below... > On Aug 20, 2018, at 10:05 AM, Christofer Dutz <[email protected]> wrote: > > Hi all, > > I’m currently working hard on the EtherNet/IP protocol and am pretty unfamiliar with it. > Especially when it comes to the structure. As I want to build the EtherNet/IP support as simple as possible it would be great if someone here could eventually answer some of my questions. > > Questions like this one: > > > * There seem to be different ways in which information can be read. Which option would be the best for our usecases? First, be aware that Ethernet/IP is really an encapsulation of the CIP (Control and Information) Protocol from DeviceNet that runs over Ethernet. So you want to get familiar with the CIP documentation that is available at ODVA (back when I looked into it, I had to join as a personal member; you might want to see if they will let Apache join as a foundation). There are "explicit messaging" and “I/O” connections. Explicit messaging (also called “Unconnected Messages”) is a request/response exchange. You ask a device a question (“What is the value of x”) and it returns an answer. I/O connections are more like subscriptions. You setup a connection between two devices, and then the device sends data at some interval. On ethernet, the Explicit Messaging runs over TCP/IP, whereas the I/O data is sent as UDP once the connection is set up. In my case, I never bothered to figure out I/O messaging; the unconnected messaging was fast enough for what I was trying to do on the ControlLogix. > * Which are the options that exist on every EtherNet/IP compliant device? The spec defines “object types” (46 in my copy of the spec) that may be present, but the only ones that are required for all modules are - Connection object or connection manager - Network specific link object - Identity Object Class - Message Router Object Class > * Can someone explain why for our test WAGO device I have to read the values of the digital input, by reading #4(assembly class)#105(instance)#3(attribute) An assembly is a collection of data. The device profile can define a “static assembly” that is specific to that device. Assemblies numbered 0-0x63 are open static, defined by the device profile. Higher numbers are vendor-defined and dynamic assemblies. So that device must define some meaning for that assembly instance. Not sure what the ‘3’ means offhand. > > Would be great, if you could help me a little. > > Chris Cheers, Greg Trasuk
