Contrologix 5000: Transparent Reload?

Again, my apologies. Been asked to become the "PLC Guy" here ...

This is a pollution control system that (now) runs a redundant PLC set-up.

Can this app be reloaded transparently so that the program executes seamlessly? Doesn't redundancy provide such capability?

My concern is upon download, the program will momentarily go to zero, causing the valves to change state, and then the Operator will have to re-select the previous mode to re-establish the previous fume exhaust path.

And until that is done, which in theory should only take as long as it takes for the program to reload and the selection re-made, the fumes could be exhausting to atmosphere (although they are coming from another device which has actually processed them).

So (I *think*) the exhaust path is just going to be diverted temporarily, but I'd rather this not happen if it can be avoided.

SoftwareJanitor said:

Again, my apologies. Been asked to become the "PLC Guy" here ...

This is a pollution control system that (now) runs a redundant PLC set-up.

Can this app be reloaded transparently so that the program executes seamlessly? Doesn't redundancy provide such capability?

My concern is upon download, the program will momentarily go to zero, causing the valves to change state, and then the Operator will have to re-select the previous mode to re-establish the previous fume exhaust path.

And until that is done, which in theory should only take as long as it takes for the program to reload and the selection re-made, the fumes could be exhausting to atmosphere (although they are coming from another device which has actually processed them).

So (I *think*) the exhaust path is just going to be diverted temporarily, but I'd rather this not happen if it can be avoided.

Click to expand...

What PLC? But in general, most PLC's go into program mode (non-run) mode in order to do a download. During this time, different PLCs handle the state of outputs different ways. RSLogix5000 for example you can configure the off-line state of outputs, to turn off, stay the same or even turn on. However, I'm not sure that during the download if the PLC is technically still in program mode, or some other mode that cannot support this output operation. It will be interesting to hear from others as I've never given that one any thought...the programs I write are for whole factories, so anytime a download is required, it's a given that all the processes need to stop.

robertmee:

Oh, sorry - it's a ControlLogix L73.

You would think you'd be able to load one Controller and then seamlessly switch back and forth, but maybe not that easy, right?

Don't some of these systems allow you to load *two* programs into the same memory space of a *single* Controller and then switch them back and forth? You would think you'd be able to do that.

You'd have memory space "A" with your existing app, up and running, and then you'd load your updated app into memory space "B", then tell the Controller on the next scan to execute from memory space "B".

Not in a Redundancy setup, I don't believe....You always download to the primary controller and the secondary controller synchronizes to it. There's no opportunity to have different programs in each.

From the AB Redundancy manual:

"Download the project only to the primary controller. When the secondary
controller is synchronized, the system automatically crossloads the project to
the secondary controller."

SoftwareJanitor said:

robertmee:
Don't some of these systems allow you to load *two* programs into the same memory space of a *single* Controller and then switch them back and forth? You would think you'd be able to do that.

You'd have memory space "A" with your existing app, up and running, and then you'd load your updated app into memory space "B", then tell the Controller on the next scan to execute from memory space "B".

Click to expand...

Different brands handle online vs offline changes differently. In the Siemens world, it works kinda like that, but it's a one way transition from A -> B. There's no toggling back and forth between two PLC programs.

In Siemens all changes are made offline. If you download code, it can almost usually do it in run (if there is enough spare memory). Certain things like changes to safety programming or changing the HW require it to stop. It downloads new copies of the code without deleting the old versions, and once everything is loaded it switches over at a "control point" which is basically the start of the next PLC scan. THe old code is deleted at the switch. This may or may not delete/initialize some of the data in the PLC, depending what changes were made.

Rockwell is a bit different, as I understand it. You can make offline changes, which wipes out the current program and tag data, and uses whatever was in your offline project. THe PLC has to stop processing before you can do this. The other option is to make online changes. This preserves your tag data, but changes can only be while actively connected to the PLC.

Both methods have their advantages. I'm not sure how redundancy factors into all of this, I don't have much experience there. What you describe COULD be how it is implemented, but that doesn't mean it is how it WAS implemented.

In AB's world, yes, A sync to B and vice versa so you don't download twice.

What's described by OP can probably be done by little bit of creative programming. See this thread (post #8+) and proceed with caution:

http://www.plctalk.net/qanda/showthread.php?t=75670

Hmmm....

So my options are:

1.) I *might* be able to configure outputs to stay at their last state during the download? That might be useful.

2.) Cut/Paste online edits (I've never done that before, but there's a first time for everything, right?)

3.) Export to .l5x, then Import the changes into the Online running app. This method brings in my tag changes, which saves me time and probably is less error-prone?

--------------------------
But you would think with the redundant Controllers - each with its own IP address, that you could do the following:

a.) Disable redundancy so the 2nd Controller stops getting copied to the first

b.) Load to the IP address of the 2nd Controller

c.) Manually fail the 1st Controller, causing switchover to the 2nd Controller

Then, if you desired, you could fail the 2nd Controller back to the 1st.

There would *still* be a blip in the changeover, but no more so than the automatic redundancy would allow.

Just seems kinda weird that you've got TWO Controllers, but you cannot do what I've described. It would essentially be a manual version of the automatic redundancy. Why should I have to cut/paste or Import/Export code and data piecemeal, which is sloppy and error-prone, if I have TWO controllers.

SoftwareJanitor said:

But you would think with the redundant Controllers - each with its own IP address, that you could do the following:

a.) Disable redundancy so the 2nd Controller stops getting copied to the first

b.) Load to the IP address of the 2nd Controller

c.) Manually fail the 1st Controller, causing switchover to the 2nd Controller

Click to expand...

IMO that's not possible. In the first step, the secondary controller stops updating logic & data from the primary one. In the 3rd step you'll need to activate the redundancy before to execute a switchover: during activation, the system will copy again the application from the primary to the secondary.

Just to clarify, online editions are performed with the primary controller and the redundancy copies any modification to the secondary controller. In older versions, it was mandatory to disqualify the secondary controller before editing the primary one.

SoftwareJanitor said:

Just seems kinda weird that you've got TWO Controllers, but you cannot do what I've described. It would essentially be a manual version of the automatic redundancy.

Click to expand...

That's not correct. The main idea of redundacy is having the same application on both controllers, and any change (logic or data) made in the primary have to be copied to the secondary. If the system detects a different application or data in the secondary, it will disqualify that controller and start synch (primary -> secondary).

SoftwareJanitor said:

Why should I have to cut/paste or Import/Export code and data piecemeal, which is sloppy and error-prone, if I have TWO controllers.

Click to expand...

Usually, you put a full application in a redundancy before activating it (and before start production), then you make minor changes. I'm not sure why you need to do a massive download.

SoftwareJanitor said:

My concern is upon download, the program will momentarily go to zero, causing the valves to change state, and then the Operator will have to re-select the previous mode to re-establish the previous fume exhaust path.

Click to expand...

As robertmee pointed, it's possible to set the output modules (via properties) to remain on the needed state. Also, you can force the outputs on the running application and the new application: this way, when you run the new application, the system will find the same forces.

nhatsen:

Yeah, I understand how redundancy works (now), just sayin' - you ought to be able to control that "redundancy" process manually for debug purposes. I mean ... you've *paid for* TWO Controllers and all it can do is run its redundancy in what amounts to "automatic" mode?

That's disappointing.

Don't you agree it would be easier, less error-prone, and more efficient if you could just load the other Controller and switch to it? Crazy that the system does not provide accommodations to allow for that.

SoftwareJanitor said:

nhatsen:

Yeah, I understand how redundancy works (now), just sayin' - you ought to be able to control that "redundancy" process manually for debug purposes. I mean ... you've *paid for* TWO Controllers and all it can do is run its redundancy in what amounts to "automatic" mode?

That's disappointing.

Don't you agree it would be easier, less error-prone, and more efficient if you could just load the other Controller and switch to it? Crazy that the system does not provide accommodations to allow for that.

Click to expand...

Exactly, that's why you buy it. Because it is redundant and you don't think of this in most of the cases. You buy it because it works.

You can control lot of things and it is there in the redundancy manual, but I still don't get exactly what you want to controll.

I've never actually done this, but believe this is how it works, someone with the kit could test it out...

If you download a "new" project to the Primary controller, it places it into a "non-run" mode, which will mean that the secondary controller takes over, continuing to run the existing application.

At the end of the download, the software prompts/asks you to put the new Primary controller into "Run" mode, warning you that control will revert to the new application (similar to "Test Edits" in a non-redundancy system).

If you say yes, this invalidates the secondary controller, and initiates a primary to secondary synchronisation, during which time redundant operation is not possible until the secondary is updated by the primary.

Well that's how I hope it works... tbh. Needs testing to confirm before doing it live.

SoftwareJanitor said:

Don't you agree it would be easier, less error-prone, and more efficient if you could just load the other Controller and switch to it?

Click to expand...

I think it could be dangerous depending of the scenario. Let me explain my point.

If you have just one controller and want to download an application, you need to switch the controller to program mode. That means the process under control is not running and you can start next time from a safe state. What you propose is like online edition but in a bigger scale: it can give you the chance to put a full aplication online, even a totally different one, in a running process.

SoftwareJanitor said:

Crazy that the system does not provide accommodations to allow for that.

Click to expand...

I would like a mute button on my wife, but life is not perfect

In any case let's review how this new behavior/function could be implemented:

1. Switch off the redundancy. Secondary controller is disqualified.
2. Download the new application into the disqualified controller (according to the manual, new applications have to be downloaded into the primary).
3. Request for a pre-synch. The redundancy module verifies if each tag (including I/O) in the disqualified controller exists in the primary controller and get its current value; new tags get the default value.
4. Request a switchover. Disqualified controller becomes primary and the former primary is disqualified (panic time: any not-well-tested logic can do something very bad in this moment).
5. Request for synch. Disqualified controller gets a copy of the application from the primary.
6. Disqualified controller becomes secondary.
7. Redundancy is on.

Steps 3 & 5 can generate a heavy crossload on the redundancy.