2 ControlLogix sharing I/O Cards

[40mpg]

Hello,


Can someone clarify and correct my understanding of two controllers sharing an I/O card.


I read through the Logix 5000 I/O document and as I understand it:


1. For an input card, as soon as the first controller establish an ownership, the second controller can only receive data from the input card if the first owner breaks its connection to the input card. However, if the second controller sets the input card to "Listen Only Data" mode, then both controllers can receive input data from the same input card. TLDR: two controllers can receive data from one input card.





2. For an output card, only one controller can be an owner, and any other controller configured to claim ownership of the output card will be rejected. If the second controller configures the shared output card as " Listen Only Data" it can receive status of the output channels.


TLDR: two controllers CANNOT command one output card what to do?

 

[JBooth]

set up produced/consumed tags or messaging between your controllers. controller 2 sends request to controller 1 when the output needs triggered, controller 1 does the actual triggering

 

[40mpg]

set up produced/consumed tags or messaging between your controllers. controller 2 sends request to controller 1 when the output needs triggered, controller 1 does the actual triggering

Yes , I have plan for a produced/ consumed method. I just needed to specifically spell out that PLC 2 will not have direct control over the device in question and it has to be PLC 1 that is doing the controlling in a technical document i have to write, and I needed to confirm that the reason for the above statement is because of what I understand about output cards sharing.




P.S (cost to run a connection from PLC 2 to the device in question will be out of scope)

 

[Operaghost]

OK so, you are sort of right.

Lets clear up Owner versus Listen-only first. The owner of a module (a CPU) stores the configuration for that module. That means whenever the module powers up, the owner will send the configuration data to the module. Owners can send and receive data to and from the module. For a listen-only connection you can only receive data, you cannot send anything to the module

Input modules
Two controllers can indeed own the same module AND both receive data from that module. Both controllers hold the configuration data. So when that module powers on, it will receive that configuration data from whichever owner CPU responds first. The input module requires a connection to an active owner. So if one CPU powers down, the other CPU will keep that module active and continue receiving data. Produce and consume cannot do this. Even still, I generally find it more common to have only one owner and have the other controllers as listen-only.

The gotcha with this setting is that the configuration settings must match exactly on the two owner controllers. If one owner decides to change the RPI setting, it will cause the other controller to see that input module as faulted. If I recall, the error message says something about configuration mismatch. So making changes to the configuration settings on the fly really cannot be done without faulting the module for the other controller. You would have to then go to the second controller and make the same config change to reestablish the connection.

For listen-only connections to an input module, as long as the owner is active, the controller using listen-only will receive input data from the module, but it cannot see any of the configuration settings or data. If the owner powers down, the listen-only connection is broken and that controller will see the module as faulted.

Output Modules
Much easier here. One owner only. Listen-only for any other controllers. Listen-only controllers can see the status of the outputs, but the output tags themselves are not available to that controller. The output tags actually appear as inputs to this controller. When you read data from a module, it is treated as an input even if you are reading the status of outputs. So the listen-only controller cannot send data to the output module and thus cannot turn on or off the outputs. Same rules about the owner has to be active...yadda yadda.

I know Produce and Consume is another option for the Outputs. I personally prefer the listen-only connection.

OG

 

[40mpg]

Listen-only controllers can see the status of the outputs, but the output tags themselves are not available to that controller. The output tags actually appear as inputs to this controller. When you read data from a module, it is treated as an input even if you are reading the status of outputs. So the listen-only controller cannot send data to the output module and thus cannot turn on or off the outputs. Same rules about the owner has to be active

OG

Awesome, thank you for the detailed explanation!