CLX Redundancy Options

I will be likely designing a CLX redundant system sometime soon and I have two questions:

1. The process is a water treatment plant that does not require redundancy for usual reasons...high speed switchover or even 100% guaranteed availability. What we really want is to be able to edit UDT's in the secondary CPU without synchronisation occuring, and then when we are ready switchover CPU's and then synchronise the old primary to the new program when we are satisfied the the new program is working ok. At that point we would probably leave the two CPU's running as a normal synchronised primary/secondary pair.

In essence, can we disable the synchronise and crossload and manually force switchovers between two CPU's with different projects loaded? And then later enable synchronising when we are ready?

(I am assuming both projects would have the same RSNetworx config loaded...but this is where I begin to have suspicions that there is a gotcha in what I am asking for.)

2. Is Redundancy formally supported at Rev15? (And what of Ver16 which will be the version that will be current during the timewindow we will be doing this project in?). The reason I ask is that the Redundancy Manual specifically refers to Ver 13 only, yet RSLogix 5000 permits Redundancy to be enabled for V15 projects.

This is an interesting idea. I have been maintaining and modifying a redundant system for about 3 years now. I started on version 8.5x and am now at 13.5x. Version 13 is very stable.

I recently noticed that version 15 will alow you to enable redundancy in the controller properties too. I looked on the firmware page of the Rockwell site and only 13 is listed in the redundancy bundle. I would say that 13 is the only one supported at this time. I have not read or heard about version 15 or 16 having a redundancy firmware release? I would not worry at all if I had to implement another redundant system using version 13.

The ControlNet configuration will be the exact same on both systems. In fact you actually set the node numbers to be the same in each racks CNB's and ENBT's. The SRM module forces the secondary CNET and ENET modules to Node+1. When a switchover occurs they swap. There is only one RSNetworx file for each of your ControlNets.

You can set the SRM to Never sychronize on it's own. It will only synchronize when you tell it too with the redundancy tool in Linx.

I have never tried to edit on the secondary chassis for obvious reasons. Our system does demand 100% reliability.

From my experiences updating firmware I think your plan will work. I suspect you can edit, I have gone online with a secondary chassis before. I have downloaded to it before too. I am unsure what will happen when you push the become primary function though? I know it will cause a major fault, but this will clear. The transfer from one controller to the other will NOT be bumpless. It will fault, then clear then it will go into run.

A disqualified secondary controller might dump it's program too? You might have to download then edit?

Really you need a bench system to verify this stuff.

I am not sure how much is really gained this way. You will not get a bumpless transfer at all. So really you could do a download about as fast. Maybe I am missing something though. Hardware costs are going to be substantial.

Most of the gotchas in redundancy systems have to do with initial hardware requirements. Make sure you understand them before you get too far. All I/O must be on ControlNet. Ethernet is only for messaging and HMI's. Each ControlNet must have at least 4 nodes too. (I think)

Hope these answers help.

RSL

Unusaual, but intresting idea.

Let me star from the end:
Redundancy v15 is not available yet, limited release (L6x controllers) will be out in a couple months, L55 after that.
You can create project now, but no FW available.

I an not sure about ver 16, may be next year?

The main feature in ver 15 is "on the fly upgrade" from v13 to v15 or v15 to v15.
I have to try, but I am pretty sure that V15 will let you Disqualify secondary, Lock Primary, modify secondary, switch to secondary and enable SYNC.

Can this be done in v13?

I am not sure if forced switchover will work on unsyncronized system. I don't have ver 13 redundancy running anymore, so can't test.

I would recommend you to contact local RA office and ask the to pass this to the redundancy marketing for review and test.

OK encouraging stuff thanks. Probably we don't even need bumpless transfer if I write my code right. Most of my actuators can be made event based rather that state based I suspect.

My style of coding is very UDT intensive and this project will be a very slow incremental process over a period of about 18 months years...the plant can stand short shutdowns of few hours, but we will never get a window long enough to do more than one equipment item at a time. Nor will the operators appreciate me dropping the plant out just to do a few edits...for all these reasons I'm looking for a "sort of redundant" system that allows me to get all my offline edits into the secondary, and then force a switchover with minimum disruption. And over such a long project period a succession of UDT edits are inevitable.

Mostly I'm just controllling pumps and valves...the pumps can tolerate short bumps, and the valves are Rotorks that have separate OPEN/CLOSE commands, so if the new program simply checks the current state on startup and continues with it I shouldn't cause any bumps.

Having said all this though, the existing plant is run on an old DCS with full CPU redundancy and the operators will specify at least that same level of functionality into the future...therefore once the edits are complete...we will put the system into normal full redundant pair mode.

When you tell an un-synchronized chassis to "become primary" it will cause a major fault in the processor you are commanding to become primary.

The only way to transfer bumpless is with a synchronized chassis.

The new change firmware feature still requires you to synchronize the secondary after you flash the firmware. Then you disqualify the other and flash it too. The new feature just allows 2 chassis with similar but not identical firmware to synchronize.

I do not think it will be possible to command a disqualified chassis to become primary without the fault. This is a safety feature. Let alone command a chassis with a different user program to take over?

Contr_Conn if I am off on any of this please let me know.

RSL

SYNC - means both COntrollers running the same program, so it is out of question because we will have 2 separate programs so SRMs will be disqualified.

I am sure that ver 13 will not let you to force switchover to disqualified secondary. Period.

In ver 15 (preliminary info I have):

The new change firmware feature still requires you to synchronize the secondary after you flash the firmware.

Click to expand...

I think if you "Lock for Upgrade" it will let you to have 2 separate programs and even FW versions in 2 separate processors, and switch from PRI to SEC.
It has feature called "Initiate Locked Switchover" - it will work with disqualified system.

In any case this situation may have other issues (CNB, ENB etc) and must be approved and tested by redundancy group or you are taking chance.
It may work for a few times and quit later, so don't take my word as YES

This is not setup you want a take a chance, call RA.

Great, thanks for the steer. At the very least I now have some of the right questions clarified to ask RA.

The feature you are asking for is one that has been on the design room floor for some time at Rockwell. My understanding that this will be done in a future version. It would be great to use the secondary to make and test program changes and then when you have what you like, synchronize the processors.

Redundancy has only been supported in odd versions. The goal was with version 13 that redundancy would be included with each version. This has not happened. Also there is a 2-3 month lag for redundancy when RA releases the odd versions.

Hope that helps.

We are still waiting for user defined function blocks - due to be out early 2007. Just when this project is winding down.

Sheldn said:

The feature you are asking for is one that has been on the design room floor for some time at Rockwell. My understanding that this will be done in a future version. It would be great to use the secondary to make and test program changes and then when you have what you like, synchronize the processors.

Click to expand...

Like I said, with ver 15 redundancy you can force switchover on disqualified system.
Will it be officially suported for applications like this? Not sure.

Redundancy has only been supported in odd versions. The goal was with version 13 that redundancy would be included with each version. This has not happened. Also there is a 2-3 month lag for redundancy when RA releases the odd versions.

Hope that helps.

Click to expand...

What about ver 8 - it is even
ver 12 had no redundancy as planned, 14 is guardlogix only. I think 16 redundancy will be out as well.

We are still waiting for user defined function blocks - due to be out early 2007. Just when this project is winding down.

Click to expand...

Ver 16 will have user defined instructions in ladder.
I am not sure about function blocks