Hi Greg, nice to hear from you ... of course code is always welcome.
For the ethernet/ip driver however we are currently using an implementation from outside the ASF: https://github.com/digitalpetri/ethernet-ip I'm working together with Kevin (aka Digitalpetri) to iron out some of the quirks. But maybe your code could help build a pure Apache driver He has implemented drivers for Modbus, EtherNet/IP and UPC-UA (All the ones we didn't have drivers for) and the great thing is that he does this almost the same way we are doing it. This allows us to integrate his encoders/decoders directly in our driver implementations. The code is Apache licensed so we could fork Kevin's work, but I don't want to do that as I would treat it as unkind. By the way, he's also the main contributor to the Eclipse Milo Project (https://projects.eclipse.org/projects/iot.milo), which is an Open-Source OPC-UA suite. Regarding the communication forms. As far as I understood it there are actually 3 types: - Unconnected Explicit messaging - Connected Explicit messaging - Connected Implicit messaging Explicit messaging is always TCP and Request/Response communication and the implicit is UDP and automatically sent by the PLC. As far as I understood the difference between connected and unconnected: - Unconnected Explicit: I come to the counter with a list of reports I would like to have. As soon as I give the list to the employee, he runs into the archive and collects things on the list and returns that - Connected Explicit: I pre-registered my interest in a list of reports. I get an order-id back, so as soon as I come to the counter and give the guy the order-id, there's a box waiting with all the reports on the list and it even has a nice cover sheet on it. - Connected Implicit: I pre-registered my interest in a list of reports. I get an order-id back, but instead of fetching the reports from the counter another guy brings the box to my desk and I only need the oder-id to cancel the order. Well at least this is how I understood it. Connected has the benefit of being more efficient for regularly occurring requests. Unconnected is better suited for ad-hoc queries. Currently I'm working on Explicit messaging first. I don't even know if Kevin implemented implicit messaging ... but that would probably be best for the subscription form of communication. 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
