Control Logix Redundant System

SHINE

Guest
S
I am with a new project and we are working on AB controllogix.
We are planning to use redundancy everywhere as the process is critical.

We will use redundant CPU, redundant Power supply to all chassis.

We have redundant CPU chassis with redundant power supply.

down that we have 4 I/O chassis each chassis with one CNBR card.

Now what will happen if the CNBR card itself fails in that particular I/O chassis.

can we have two redundant CNBR card in each I/O Chassis. can we switch automatically to other CNBR card
if the first CNBR card fails in the I/O chassis.

has anyone tried this.

Is this software switching will there be any timing issue.

also now suppose i have only one CNBR in each chassis and suppose that CNBR card has failed. what will happen to
the I/O cards. can we program the I/O cards to stay in their previous state.

will this failure of one CNBR card in an I/O chassis trip our process. will our CPU go to fault mode when an CNBR card in a I/O chassis fail.

Will the user be known that a cnbr card has failed in so and so I/O chassis.

Sorry this is my first time with Control logix.

thanks for your help
 
Try a search on the www.ab.com website. I did a quick search typing in control logic redundancy then did a google site search and found some good info.
 
I think current version of redundand CLX (v11) does not support redundand CNB
I heard that V13 will support multiple CNBs and Ethernet I/O for redundand system.
Technically you need to double each I/O module also. I/O modules fail more often than CNB I think.
Call techsupport, they give pre-sale info without techconnect contract.
 
who REALLY does this

Speaking of redundant systems brings this to mind....

I've quoted systems for years where the end user, for
what ever reason, has specified redundancy in the
logic controller (PLC. SPS). In every single case,
this feature was eliminated before actual implementation
due to complexity and cost.

What industries really DO implement this stuff?????
 
Control_Conn is a valued member of the forum, but I think he's shooting from the hip above; those statements are incorrect.

What you need, SHINE, is the Redundancy System Manual, publication number 1756-UM523D. Get it from your A-B dealer or download it here:

http://www.ab.com/manuals/cl/#hardware

This should answer most of your questions about the capabilities of the ControlLogix and ControlNet-based redundancy systems.

Most redundant ControlLogix systems use one 1756-CNBR in each remote I/O chassis. The 1756-CNBR's are no more likely to fail than the other modules in the chassis, so you have the same level of reliability at the I/O chassis level.

If a 1756-CNBR in a remote I/O chassis does fail, it will not affect the rest of the ControlNet network, and will not cause a fault in the controller. The I/O modules in that chassis can be configured to hold their last state, or to go to a defined fault state.

The controller will know about a failed I/O connection immediately.

ControlLogix redundancy is relatively easy compared to many other products both past and present, but it's a pretty hard thing to make a redundancy application your introduction to the control platform. Make sure you know your local A-B office well !
 
Just to add to Ken's excellent comments above....ControlLogix redundancy is very easy, much easier than most other redundant systems, BUT it does require some very specific knowledge to make it work well.

The biggest thing to be aware of is that with redundancy your application logic scan times are going to be greatly increased. This means that you will need to write programs that are as processor time efficient as possible, otherwise you have the risk of the finished program having excessive scan times.

This is quite easy to manage if you are familiar with ControlLogix, but a redundant system is usually not something most people would tackle the first time they use a product.

The main thing is exactly what Ken suggests...talk to someone local within Rockwell (who is well informed about this issue) and make sure you have all the right information, before you begin work. If you do this is WILL all work just fine. It really is an excellent system you will enjoy working with.
 
THANKS A LOT - NEED YOUR HELP AGAIN

Thanks all for your valuable post.

Now below are for Ken Roach and PhilipW,

My customer is been insisting on having two CNBR card in each I/O chassis.

I exactly replied to him after seeing your post.

But he doesnot seem to be convinced yet on it. because our competitor has offered him a system from other brand which supports two RIO Card.

Can I have two CNBR card in same I/O chasssis and continue to get the same I/O details via one card or both of them all the time.

not like switchover but i will get the same I/O details all the time in both card and even if one card fails it will not matter me because i will continue to get data from other card. Only i should get a message that the other CNBR is failed so that somebody can replace it with a new card.

I read the Redundancy manual.

Thanks again for your valuable help.
 
I will defer to Ken on this one if he has a better idea, but IF your customer really wants two CNBR modules in each chassis then yes it is possible.

All you need to do is configure both modules as per normal, and give them different node numbers on the ControlNet. The I/O modules in the remote chassis will then appear twice in the controller I/O tag list, once for each CNBR. All you have to do is then use a GSV instruction to get the MODULE/FAULTCODE for both CNBR's and use this to decide which is the valid I/O tag and then buffer it a working tag you want the actual logic to work on.

The main drawback of this method is that on a larger system you are using up twice as many processor connections (250 max), and it is possible you will run out of them. It might also be a good idea to use the status of both the primary and secondary CNBR modules you have already read, and then use this in the program with an SSV to dynmically enable the connection to the primary CNBR module that needs to be in use, and inhibit the secondary CNBR.

This is quite easy to do once you have the right information. Once you got to writing the actual program I (or someone else) could help with the details.

I think that this trick would make more efficient use of processor resource, especially in a larger system, but for a small one it would not be necessary. If you like you could email me your proposed config and I might be able to help a little further. [email protected]

It is still true that the system does NOT really need two CNBR modules in each chassis, but if the client insists.... I would not try to change his mind. But remember your competitor probably NEEDS to use two remote I/O modules in each chassis because his modules do NOT have redundant network ports built-in like the 1756-CNBR's. This may give you a price advantage you may not want to throw away.
 
Last edited:

Similar Topics

Hi sir. We are using Control logix redundant PLC system which supports only PTP time synchronization protocol but from DCS side we are receiving...
Replies
1
Views
2,393
Dear all, I have just arrived to a new site and found very strange Control net network. Just to explain the situation. there is redundant CLX...
Replies
5
Views
5,205
I have a Redundant Allen Bradley system 1756-L55 controller which have 1756-BA1 lithum battery it is our normal practice that we have to change...
Replies
1
Views
2,745
Dear Experts Is it possible two have following functionality using conrologix processors & I/Os at remote We have two separate redundant...
Replies
2
Views
3,900
I have a PLC setup that is currently running two (A Redundant) Control logix Processors - a Primary and Seconday. One important note to...
Replies
3
Views
5,121
Back
Top Bottom