Pylogix and class 1 connections

 A few times a year I'm asked about class 1 connection ability with pylogix.  Typically, I respond simply that pylogix doesn't make class 1 connections and I don't plan on supporting them.  Purely as a technical challenge, I have experimented in this space but I never really saw class 1 connection support as something useful to most people.  A few have made their case, only one was compelling.  I'll do my best to lay out my thoughts.

What is a class 1 connection

Simply put, I/O connections.  Anything that gets added to the Logix tree uses a class 1 connection.  Devices communicate at a predictable rate, at the RPI specified.  When a device is added to the tree, there are a number of properties, including IP address, number of input words, output words, etc.  The controller will reach out to the target device, sending these connection parameters.  The target device responds agreeing to the terms, the two devices switch over to UDP and exchange their data at the specified interval.

How does pylogix make a connection

Pylogix uses class 3 explicit connections, similar to the MSG instruction if you are familiar.  Most communication drivers use class 3.  It makes the most sense for pylogix because there is no configuration that has to be done on the PLC end.  Simply point it to a tag read it or write a value to it.  The PLC doesn't care what device is asking for it.  As long as you as the user doesn't close the connection, you can keep making requests (reads/writes) on the same connection.

Pros and cons

There are a couple of disadvantages I see with class 1 connections that I don't think most people are thinking about when they ask for support:

1) The PLC has to be configured ahead of time.   If pylogix were to utilize class 1 connections, it would be via the Generic Module.  These cannot be added at runtime, so the configuration would be offline and have to be downloaded to the PLC.  This works at test time, but not very often during production.

2)  It's not very flexible. The generic module limits you to an array of input words, an array of output words and an array of configuration words.  Again, this cannot be modified at runtime.  You'd have to change the controller configuration, change pylogix configuration, then download.

3) Speed.  I think the most common instinct people have is that class 1 will be faster.  It sounds faster.  The problem comes from trying to get determinism with the overhead of an operating system.  The faster the RPI, the less reliable the PC end becomes.  The PLC is expecting the response at the RPI.

4) Consumes a node towards your node count.

The most compelling case I heard was a user was making bridge between two controllers.  It might have been that one was Modbus and the other Ethernet I/P.  Data was being sent to the bridge via Modbus at a specific interval.  The bridge needed to get the data to the ControlLogix at the same interval.  This situation made sense to me.

I do have a few things in the works in the is space.  First, and the most complete, an "adapter" module, which connects to the generic module in the I/O tree.  Data will be exchanged at the configured RPI.  The 2nd option, I have an EDS file, which when registered, gives you a pylogix module you can add to your I/O tree.  Similar to the generic module, the adapter will connect to the pylogix module in your tree and exchange data at the configured RPI.  The last idea, which I haven't worked on yet, would be adding a Subscribe method to pylogix.PLC to return data at a specified poll rate.  I imagine this would utilize pylogix current connection method, but run a thread to continuously read the data.