Implementing an Object-Specific Service about cpppo HOT 4 CLOSED

I've been working with EtherNet/IP CIP for years, and I still shake my head in disbelief. So, don't feel bad about how long its taking to understand!

Unfortunately, for "Explicit" CIP, many layers of encapsulation are required to route the request to the Ethernet module, to the right CPU or interface, and then to the right device; only at the lowest level is the Service Code carried.

In Cpppo, these Service Codes (and their accompanying data) are produced and parsed in (for example) the Logix class, in cpppo/server/enip/logix.py. We'd need to create a new 'dialect' class, to pass to cpppo.server.enip.client's 'client' or 'connector' object, to understand the new service codes.

In other words, we'd need probably need to derive a new class from cpppo.server.enip.logix's Logix class. This Logix class understands how to produce and parse the regular ControlLogix "Read Tag" (0x4c), Service Codes. If your Keyence DL-EP1 doesn't do Read/Write Tag, then instead we could derive a class from the more basic Message_Router class or Object class instead -- these only understand how to produce/parse Get/Set Attribute (0x01, 0x0E, 0x10) Service Codes.

Anyway, once we create that class, and know how to produce/parse the payload of this new 0x4D service code -- we would instantiate an instance of cpppo.server.enip.client's 'connector' or 'client':

from cpppo.server.enip import logix, client

class ep1( logix.Logix ):
    ... # produce/parse 0x4D Service Code

with client.connector( host='ep1', dialect=ep1 ) as connection:
   ... # do I/O

I might be able to shake a few hours of consulting time loose to help get this going, if its of value to you...

from cpppo.

It'll also require amending cpppo.server.enip.client to understand and pass thru the new keyword we designate, which is interpreted in your new ep1 class to issue the 0x4D service code. Its sort of messy right now, as this all grew organically over time...

The 'client' class constructs an elaborate hierarchy of 'dict'-like objects (cpppo.dotdict), containing all of the CIP encapsulation and payload data. At the lowest level are the things like read_tag_fragmented, get_attributes_all, etc. We'll need to teach it a new one, such as get_decimal_places or something, which your new ep1 Message_Router object will be able to interpret.

from cpppo.

Should this type of data transfer (reading data from a sensor) use "Implicit" Messaging then? I see that "Implicit" Messaging is useful for transferring data repetitively as opposed to the Request-Then-Receive framework that I've been trying to implement with "Explicit" Messaging.

I'm just trying to figure out if I'm going in the right direction before I dive down the path of implementing a new service code.

Thanks,
Bryan

from cpppo.

Well, that's a possibility -- but you couldn't use Cpppo, then, because we don't implement "Connected" / "Implicit" requests (yet). These are UDP/IP, and use a much simpler encapsulation -- but initiating the "Connected" session is much more complex, and requires the Forward Open request via an Explicit / Unconnected session, which then establishes the Implicit / Connected session...

All this only works within the same LAN, of course, because the receiving party (the EP1 device) has to be able to directly send UDP/IP packets to the initiating party (your Python program). So, they all have to be in the same Layer 2 IP network, usually.

from cpppo.