RS5000 rack optimized

[JeffKiper]

What is Rack optimized? I have seen it in CLX CNET remote chassis, and Flex chassis. I don't understand what or why it is used. Can you shed some light on it?

[daba]

I certainly can....

When a ControlLogix controller uses I/O modules in a remote chassis, without Rack Optimisation, it will use a "connection" for each and every module.

The system only allows 250 connections, and some of these will be used by comms and other modules. In a large system it would be easy to run out of connections.

Rack Optimisation reduces the connections needed for digital modules only, by getting the remote I/O communications module (ControlNet or EtherNet Bridge module), to act as a Remote I/O adaptor, gathering digital inputs from the chassis, and delivering digital outputs.

This is done via two tags, automatically created when you configure the remote comms module for Rack Optimisation.

The whole of the digital I/O for a chassis is then exchanged with the controller using just 1 "connection".

In contrast, if you had a 17-slot remote I/O chassis with a mix of digtal I/O in all the slots (barring the comms module of course). Without Rack Optimisation, you would consume 16 connections to exchange the I/O data.

The tag-names for the I/O in the remote chassis change, and don't look like proper I/O tags, but the system caters for this by automatically creating alias tags to the rack-optimised tags, allowing the programmer to continue to use standard Location : Slot : Data I/O tag addressing.

An example is called for.....

Bit 0 of an Input Module in slot 3 of a remote chassis, connected via a CNB module in that chassis with a name of Remote, would be addressed like ....

Remote:3:I.Data.0

With Rack Optimisation, the data is brought into the controller from the CNB in another tag, called the rack-optimised tag...

Remote:I.Slot[3].0

The system creates an alias from the I/O tag to the rack optimised tag for you, so you can address the input point like all others.

Hope This Helps...

[Mickey]

Having said all that and given there is a choice to use it or not. Why wouldn't one use "Rack Optimization"? What is the down side if any?

[The Plc Kid]

From what i have learned rack optimization can not be used if your remote rack contains any analog or specialty modules such as a thermocouple card.

[Operaghost]

Rack Optimization can be used on a remote chassis even if it contains analog or specialty modules. Rack optimization only affects digital modules so your analog modules don't care.

Don't use rack optimization if you are using modules with extra features such as electronic fusing or diagnostics. That information can not be transferred using rack optimization.

Also, once you configure the remote comm module to use rack optimization you can still choose which individual modules should or should not use rack optimization.

So using that 17-slot chassis example you could have the the following (RO = rack optimize, DC = direct connection):


(1) ethernet or controlnet configured for RO
(6) standard digital input modules using RO
(3) standard digital output modules RO
(3) analog input modules using DC (no other option)
(1) analog output module using DC (no other option)
(2) Fused digital output modules using DC
(1) Diagnostic digital input module using DC

So, if you do not use RO then the comm module does not need to be configured for it and will not require a connection. So you would use 16 connections on this one chassis.

How many connections would this use as detailed?

OG

[The Plc Kid]

5 Connections?

[The Plc Kid]

OG

I got that from AB tech support. Guy told me that i could configure RO but if i had even one analog or specialty module in that remote chasis then they would all consume 1 connection.

What did Daba mean by system only supports 250 connections? is that per processor or per ENBT or similar module?

What about multiple procesors in a single chasis is the backplane limited to 250 connections?

What about 2 enbt cards each setup for a different network?

[Operaghost]

Ok, so that was 8 connections total.


Comm module using RO requires one connection. All standard digital I/O modules use this connection.
(4) for analog. Each analog requires one connection
(3) for fused and diagnostic digital modules as each would use one connection since they are configured for direct connection.

So what I was trying to get across is that analog will always use a DC. Digitals can be mixed with some using DC and some using RO even in the same chassis. The presence of analog modules does not affect the rack optimization or connections for the digital modules. Perhaps there was a misunderstanding on that call to tech support.

Now as to your other questions, the 250 connection limit is per CPU, not per chassis. If you have two CPUs then each is capable of 250. However, be aware that comm modules have limits also. You mentioned the 1756-ENBT which has a maximum of 64 connections. So for example, you could not have say 75 remote ethernet chassis connected to that one local ethernet module. Upgrade to the 1756-EN2T and that number increases to 128 connections.

OG

[Operaghost]

Take a look at a similar example on Page 66 in Rockwell's Logix5000 Controllers Design Considerations manual:

http://literature.rockwellautomation.com/idc/groups/literature/documents/rm/1756-rm094_-en-p.pdf

OG

[The Plc Kid]

Thanks for clearing that up OG.

250 connections per cpu does seem like a low number. I could see that getting full real fast on some of our systems.

If i had a system where i need 320 connections how could i use c-logix?

I know i could use 2 cpu but getting that data from one cpu to another uses connections also.

I know that each produced/consumed tag use 1 connection but using UDT you can move many tags with 1 connection but i have never been able to find what that max is.

[Operaghost]

Well, rack optimization is the best way to conserve connections for your I/O.

You've got the right idea with the UDT. If you can pack your data into a UDT or an array, that can really help conserve those produce/consume connections.

One produced array/UDT tag could have as much as 500 bytes. So for example, you could pack 125 DINT tags into an array and then produce that array. That counts as one produced tag and just one connection.

Now when it comes to producing, bear in mind that it requires one connection to produce a tag AND one connection for each consumer. So if you are using two cpus then figure two connections per produced tag. The consumer cpu would use one connection only for each consume tag. It's the producer that gets the extra hit.

Tak a look at page 57 of that document I pointed you to earlier. Lots of good detail there.

OG

[Operaghost]

Oh, and to address Mickey's "why wouldn't you use it". I might have addressed this already, but just in case.

Don't use rack optimization (RO) if your remote chassis contains just analog modules.

Don't use RO if you are using fused or diagnostic I/O modules as this extra data will not be available.

Don't configure the comms module for RO if you are going to configure the I/O modules for a direct connection (DC). The comms module would unnecessarily use a connection and bandwidth is wasted as the RO comms would still occur even if no modules use it. The modules would transmit their data using DC and the comms module would sent data as well using RO.

I had a customer that had several remote chassis with just analog modules and they had those chassis setup to use RO. I tried to convince them that this was affecting there ControlNet performance but, it worked and they weren't gonna touch it. Oh well.

OG

[mellis]

Just to further clarify what OG said...

The only situation where you don't use rack optimization is where you don't have any basic digital I/O modules.

Also keep in mind that applies for future I/O modules as well.

In reality, almost every real installation I have done is set for rack optomization. Even if you don't need it, it's only one additional connection that could be wasted. If one additional connection per rack is going to break your system, you are too close to the edge already.

[Operaghost]

You are right mellis but one more thing to consider....

When a chassis is configured for RO then it will automatically transmit data for each slot in the chassis back to your controller. Even if a slot is empty, or contains a DC style module, data will still be transmitted for that slot.

That data (even meaningless data) means you are adding extra traffic to your network.

So I agree, I almost always set a chassis to use RO, and it is the default setting. But if you know you won't use it, then not only can you save one connection (not a real big deal) but you can reduce network traffic by not configuring that chassis for RO.

OG