RS5000 Input Module Owners

Good day,
I will have 2 L61 controllers in the same local rack.Is it possible that both controllers can own the same input module also located in the same local rack. All I could find so far is that they can own the same input module if it is in a remote rack. Thanks in advance for any help.

I was not aware 2 controllers can "own" the same module? That seems like really bad idea.

More than one controller 'owning' an input module is no problem. It just means that the state of the inputs are sent to both controllers. What isn't allowed is 'ownership' by more than one controller of an output module.

But I have no idea about BENNY's question.

IIRC there is no restriction on where the input module sits. It can be local or remote.

What isn't allowed is 'ownership' by more than one controller of an output module.

Click to expand...

That seems reasonable. I'll bet it generates quite a bit more network traffic in that config.

Sibling rivalry

What you're actually looking for is a 'listen only' connection. This can be done over the backplane or over a ControlNet or EtherNet/IP network.

One controller actually 'owns' the connection to the Input module. In RSLogix 5000, this is an ordinary Input connection.

When the controller starts up it will send a connection request, including keying information and the RPI value, to the module. When the module accepts the connection, the owner sends the Configuration data block, and cyclic I/O transfer commences.

The other controller should have a 'listen only' connection. It gets the same Input data at the same RPI, but it doesn't have any keying relationship and it doesn't send any Configuration information to the module.

The only drawback of a Listen Only connection is that if the main connection fails, the Listen Only connection does, too.

It is technically possible, but uncommon, to create two owner connections to an Input module. As long as the configuration data is identical for both, whichever establishes first will run, and if that connection is broken the other controller will create a new connection to it. This is NOT the way redundancy works and it should not be your standard method.

Output modules cannot have multiple Owners. You can perform a Listen connection to an Output module's data, but you can't have multiple owners.

I remember fondly being in a RA class where the assignment was to take "ownership" of the output module in another station with the goal of flashing thier lights to indicate we had done so.

Being a bit ADHD we took it a step further and took control of ALL the workstations in the classroom and made the blinking lights snake through everyones station in turn. Then we sat in the back of the room and marveled at what we had done.
The snake slowly died as others figured out what was going on with thier lights. Sadly we didn't get extra credit for that.

Other than that bit of mischief, I imagine there is a more practical reason for the ability to own an output module in a different rack, but other than extending an existing rack to add more I/O to a single CPU I can't envision one. Can you give me an example where this makes sense?

It seems very dangerous to have one module in a rack controlled by a PLC some distance away and the rest controlled by the local controller.

The listen only connection has interesting possibilities. I have never set one of those up, I'll have to look into that.

TheWaterboy said:

I remember fondly being in a RA class where the assignment was to take "ownership" of the output module in another station with the goal of flashing thier lights to indicate we had done so.

Being a bit ADHD we took it a step further and took control of ALL the workstations in the classroom and made the blinking lights snake through everyones station in turn. Then we sat in the back of the room and marveled at what we had done.
The snake slowly died as others figured out what was going on with thier lights. Sadly we didn't get extra credit for that.

Other than that bit of mischief, I imagine there is a more practical reason for the ability to own an output module in a different rack, but other than extending an existing rack to add more I/O to a single CPU I can't envision one. Can you give me an example where this makes sense?

It seems very dangerous to have one module in a rack controlled by a PLC some distance away and the rest controlled by the local controller.

The listen only connection has interesting possibilities. I have never set one of those up, I'll have to look into that.

Click to expand...

It is not an issue of "controlled by", it's about convenience. A specific I/O requirement may be geographically better served by an I/O module located in a chassis in a panel closer to where the field device is. You have to realise that Logix5000 isn't a PLC system, with one processor, and remote I/O chassis. Instead, it's a networked control system that allows multiple controllers, in multiple chassis, with I/O modules anywhere, that can be configured to collaborate into a functional system.

I highlighted the words "controlled by" deliberately.... You do not "control" I/O modules, they are simply modules that allow the control system access to "real-world" inputs and outputs.

Specifically, an Input module will "produce" it's input data tag onto the network, which can be "consumed" by a connected controller. A "connected" controller is one that has successfully downloaded the module's configuration tag (which is configured "per project" for each controller). The input data tag can also be consumed by a controller that is "unconnected"... i.e. "listen-only" mode.

Multiple controllers can be connected to an Input module, provided that the configuration tag that is downloaded to the module is identical to the configuration it already has from the first controller that successfully downloaded its configuration.

An Input module will reject, and therefore not make a connection, to a controller that tries to configure the input module to work differently.

For output modules, whichever controller gets its configuration tag downloaded first, becomes the "owner" of the module, and no additional "connections" are allowed.