Multiple ControlLogix Controllers in the same Chassis

Ken Roach said:

I've also seen this done when multiple OEMs needed to contribute to the same control system and share the same network.

Each one got their own CPU, shared inputs, owned outputs, and did Produced/Consumed Tags to communicate with one another.

In the old days we did it with L1 controllers and would split up motion control from continuous process control, as well.

Old days. Get off my lawn !

Click to expand...

ebolbol said:

When you open the project, the I/O tree looks like any other project, but there is a difference. Not all is what it seems. certain tasks and programs and routines are done by various controllers and not necessarily by the main controller. Huh...

Click to expand...

Operaghost said:

It looks like any other controller. There is no "one project that rules them all". The project is not distributed, there is no inherent master controller. Your application programs might consider one controller to be the main/master, but there is nothing inherent that makes any CPU the main/master controller.

Each CPU has its own project, logic, tags, I/O modules. As Ken mentions though, input modules may be shared among multiple CPUs. Not output modules though. The only thing that might stand out is that if they are using Produce and Consume then the I/O configuration will also show the other controllers. But that would also happen if they were all in separate chassis.

Imagine the four CPUs in four separate chassis. This works exactly the same as if they were all remote.

OG

Click to expand...

Operaghost said:

Imagine the four CPUs in four separate chassis. This works exactly the same as if they were all remote.

OG

Click to expand...

Operaghost said:

The only thing that might stand out is that if they are using Produce and Consume then the I/O configuration will also show the other controllers.

Click to expand...

daba said:

That, in a nutshell, describes the situation perfectly !!

I always make a point to my students that the "chassis" just contains a "backplane", which is a network component, allowing whatever modules that are plugged onto it to communicate with each other.

I also point out that every single module can be considered to a "processor", performing different processing functions. Input modules process real-world inputs into Input data tags, output module process Output data tags to real-world outputs, communication modules act as "bridges" from the chassis to other devices, so they are processing data that needs to be communicated, etc.

They all communicate with each other using the Producer/Consumer model of data exchange.

After more discussions about limitations in sharing I/O modules, I tell the students that the networked 3, 4 or 5 training rigs in the room (each with 2 controller modules), can be looked at as one "PLC" - I prefer the name DCS - Distributed Control System.

I have to stick to the course material, but if time allows I like to throw in additional exercises, e.g....

1. Use your potentiometer (analog in) to display on the panel meter (analog out) of the training rig to their right. This concentrates on configuring local and remote I/O, and usually initially gives errors because the chassis to the right still has the last exercise in the controller, which has control of the unsharable analog output module. It's a good exercise because the students see first-hand what the problems are, and how they become resolved automatically.

2. A "chat-room" - it's fun and it involves creating a bunch of produced and consumed string tags. There's no I/O or coding involved, just produce/consume tag data-exchange. Also they have to put everyone else's controllers into their I/O Configuration, nothing in the standard course material goes anywhere near that scenario.

In summary... Any module - Any where : it's just a collection of modules on a network.

Click to expand...

ASF said:

Presumably, you have opened the program of the first controller in the chassis (Master_Inflow_Sortation). As far as it's program is concerned, it's a Controller and the other three are just I/O modules. So you will get a "Controller Properties" for itself, and "Module Properties" for the other three.

Remember, each of the four L73's has it's own PLC program!

What you are looking at there is NOT the program executed by ALL FOUR processors - you're looking at just the program executed by the processor in slot 0.

The other three L73's have their own program, and their own .ACD file. They will probably all look completely different to one another. If you open the program for the second one, you'll find that the second controller views the first as an I/O module, just like the first does the second.

Does that make any more sense?

Click to expand...

Operaghost said:

Look at the I/O config and next to the "[0]" there is a little left facing arrow icon. That is how we know that you are looking at the application for controller in slot 0.

If you go online to slot #1 you will see the same little icon next to [1]. Again, they all operate independently with their own applications.

As ASF mentions, each controller has the other controllers in their I/O configuration for the purpose of messaging or Produce and Consume. But to the controller in Slot #0, then modules in slot #1 and so on, are treated just like I/O modules. That's why you can't drill any deeper to see the code. The code is in the other controller.

You have four completely independent CPUs that just happen to be located in the same physical chassis. Treat them as four independent systems.

OG

Click to expand...