ControlLogix: How Large an Application?

Does anybody know what the limitations are of a typical ControlLogix PLC?

1.) Is there a physical I/O limitation, or only a practical limitation? Or, put another way ... what's the largest number of I/O you've ever seen being read by a ControlLogix PLC?

2.) Is the physical memory limitation a hard number? I've never heard of anyone here *expanding* memory on a PLC, or even talking about it. Are there memory cards (or even hard drives) that can be dropped into a PLC rack?

If anybody can think of any other limitations that they know of, feel free to include them in your reply. Thanks!

The attached image is just for L8x. There's more info and controllers (L6x, L7x) in this manual.

nhatsen said:

The attached image is just for L8x. There's more info and controllers (L6x, L7x) in this manual.

Click to expand...

Those numbers are correct for earlier processors too.

The system was designed for 128,000 digital I/O, and each analog I/O reduces digital I/O by 32.

So 64,000 DIO allows 2000 AIO, and using 4000 AIO allows for zero DIO.

These numbers of I/O are huge, but when you consider you can break up a system by putting multiple controllers on the network, the limitations of I/O in one "system" goes away.

By far the biggest limitation is the number of connections supported by (A) your processor, and (B) your communication modules.

Rack Optimisation reduces the number of connections (to remote chassis), but only works for digital I/O.

I'd have to check the newer modules, but there never was a single processor or comms module that could support 4000 AIO, since the largest AIO had 6 channels, that number of AIO would have needed over 600 connections.

Thanks! So, practically-speaking, there's no I/O limitation (the PLC could keep up even with thousands of inputs), but then you could never get that many I/O into the processor anyway?

So let's say I had 500 I/O: 200 DO, 100 AO, 100 AI, and 100 DI's. This would all go onto multiple I/O remote racks with however many modules (based on the number of channels each module had). Is there a limit to the number of I/O racks you can have your Controller talking to?

Daba - when you say "connections", do you mean a communication connection to the remote rack, or physical wiring connection? If the former, what's the nature of the connection? Is it by rack, module, or what?

SoftwareJanitor said:

Daba - when you say "connections", do you mean a communication connection to the remote rack, or physical wiring connection? If the former, what's the nature of the connection? Is it by rack, module, or what?

Click to expand...

Think of a "connection" as a single communication channel that allows data to be passed between modules..

All modules use one or more "connections" to maintain communications between themselves and the "owner" of the connection.

For example, and the simplest case, an I/O module is required for the application......

1. System is powered-up, Controller does its self-tests....
2. Controller attempts to establish a "connection" with each I/O module specified in the application "IO Configuration" tree.
3. Module is queried for its type, and revision, the controller checks that it meets the "Electronic Keying" criteria in the IO Configuration.
4. (Assuming E.K. successful) - Controller downloads the module's Configuration tag to the module.
5. If the module accepts the configuration tag (it checks it is valid), then the "connection" is established, and the module and controller can communicate with each other using Produced/Consummed data transfer.

Once connection is established, the I/O module is referred to as being "owned" by that controller.

When all required modules have their connections established, the I/O LED goes steady green, and everything is healthy.

If the "connection" gets lost, for any reason, the module throws away its configuration data, and the connection is terminated. A controller must re-download a configuration to re-establish the connection.

Output modules (and that means any I/O module with outputs) can only have one owner, for obvious reasons. Any attempt by another controller on the network to establish a connection to an "owned" output module will be rejected by the module.

Input modules, on the other hand, can be "shared" between controllers, i.e. have multiple owners. For this to occur, the downloaded configuration tags must be identical, or the module would not know how to behave. If multiple ownership is in operation for a module, then it will continue to produce data for controllers to consume if at least one owner is still present.

To conserve the number of connections used by I/O modules, it is possible (and by default) to use "Rack Optimisation" for digital IO modules in remote chassis. Basically this give the remote chassis' communications adapter the responsibility of collating the I/O tags to/from the IO modules into two single tags that are exchanged with the controller. Foe example, if a 17-slot chassis full of digital I/O modules was not configured for "rack optimisation", it would use 16 "connections" with owner-controllers. If rack optimisation is used, then it only uses 1 "connection". Analog modules cannot use the "rack optimisation" scheme, and will always 1 (extra) connection for each analog module.

SoftwareJanitor said:

So let's say I had 500 I/O: 200 DO, 100 AO, 100 AI, and 100 DI's. This would all go onto multiple I/O remote racks with however many modules (based on the number of channels each module had). Is there a limit to the number of I/O racks you can have your Controller talking to?

Click to expand...

The limit will be reached when all the controller connections are used.

From my previous post - the communication modules (that allow access to the remote chassis), will also require some connections themselves, tags that are produced/consumed between controllers also require a connection (per tag), and messages require a connection to allow passage, although with messages you have the option to use a connection only for each data transfer - i.e. the connection is established first, message sent, then connection broken.

In large applications with lots of remote I/O, lots of produced/consumed tags etc., it is quite easy to run out of available connections !! Then it is time to start building UDT tags for produced/consumed data transfers, combining multiple messages into one where possible, and ensuring that all digital modules are using Rack Optimisation.