one device two plc's controlling it?

I have an application where a pump is currently contolled by an older TI-565 plc, the customer wants to use this same pump as part of an expansion and control it with his "new" PLC-5/80E system, while still being able to run it from the old system.

The only solution that comes to mind is having the old system retain control (already wired and tested), and connecting the two plcs together, then pass run request/status bits back and forth between the two.
Anyone have another option?

I considered relays fired by plc's but if one wants the pump off and one wants it on, who wins?

thanks,

Ken

Let 2-position selector switch decide which system is in control

I had a similar experience, but with a new construction project.

You have to consider what might happen if the 'old' system is
offline for some reason, and the 'new' system wants to start the
motor. You also need to consider emergency stop condition.

In my case, I had each PLC pick up a relay, the N.O. contact of
which was paralleled with the other PLC's similar relay. This
circuit was the start circuit. The motor start aux. contact
was run to a pair of interposing relays, and these contacts were
brought back as inputs individually.

Ken's point is well taken, you almost need a 'stop' relay that
allows the other system to always stop the system. OTOH, you
might decide that 'only the system that starts the motor
can stop it'.

For my logic, I generated a condition called SNM (Somebody, Not Me) started the motor. (Aux true, coil output false). In this case,
SNM is in charge of the motor, and I could not start it.

Good luck...be safe

Ken,

First, if that lousy old TI-565 is gonna end up in the trash somewhere... CALL ME! before it gets discarded.

Second, a little story...

When I started at my current position the main process was controlled by two PLC's. One was "lousy, old and undependable!". The other was "brand new" with all the bells, whistles and a whole bunch of the pretty blinkin' lights!

When I started there, the "lousy, old and undependable" PLC was "charged" with more down-time than any other factor in the process. The "brand new" PLC had its' problems but, hey, there were far fewer problems on the "brand new" PLC than there were on that "lousy, old and undependable PLC".

There was a major, and I mean MAJOR, campaign underway to replace that "lousy, old and undependable" PLC with a copy of the "brand new" PLC.

My first task was to investigate the "lousy, old and undependable" PLC and see if there was something I could do to "prop-up its' performance until the new system could be installed".

Now... one of the really important things that a Process Developer needs to understand is that "users" have this Neanderthal trait of "killing the messenger". In terms of a process controlled by a PLC, this means that the "users" tend to blame (and kill, as soon as possible) "that damned computer!"

Those of us that are a little more open-minded realize that the computer will do what you tell it to do. And the complement to that is... GI-GO... Garbage In - Garbage Out.

What this implies is... if a so-called Process Developer can not get the "system" to respond as required by the users, then, "that damned computer" must be the cause of everyones' grief!

The user refrain becomes... GET A BETTER COMPUTER!

Those of us "in the know" know that the refrain should be... "HANG THAT DAMNED PROCESS DEVELOPER!"

So... as I said, "My first task was to investigate the "lousy, old and undependable" PLC and see if there was something I could do to "prop-up its' performance until the new system could be installed"."

I did investigate. When I suggested to a fellow Process Developer (one that was familiar with the process) that I would probably have to rewrite the entire process... on-line... live! He said, "Damn! You're gonna be busy for the next 10 years!"

Within a few months (spent learning all the details of the system) I installed a re-write of the most critical part of the process. This part of the process was responsible for more down-time than any of the others.

That was seven years ago. Since then, that part of the process has been "charged" with zero-down-time... that's a big "goose-egg", as in, "none", "nada", "zip"... get my drift?

I have since moved on to the remaining parts of the process. There are only a few modules left to deal with. When my friend said, "...You're gonna be busy for the next 10 years!" I thought he was crazy... little did I know.

So, at this point, there is now a concerted effort to replace the "brand new" PLC with one like that "lousy, old and undependable" PLC.

There are two reasons for this.

The first is that the manufacturer of the "brand new" PLC has quit making PLC's (Honeywell).

The second is that the "lousy, old and undependable" PLC is as SOLID AS A ROCK!!!

Now-a-days, if there is any down-time "charged" to a computer, it is only charged to the "brand-new" Honeywell. This is simply because that "lousy, old and undependable" PLC has been reprogrammed from a process-point-of-view as opposed to being a huge "switch-handler". The Honeywell has yet to be addressed.

Now... here is my conundrum... that "lousy, old and undependable" PLC, or rather, that SOLID AS A ROCK!!! PLC, is a TI-555. And, of course, much to my chagrin, TI has also quit making PLC's.

"Ohhh, What a World! What a World!" (Wicked Witch of the East?)

So now, despite efforts from forces beyond my control, I'm trying to replace the Honeywell with another, SOLID AS A ROCK, TI.

The point of that "little" story is that...
"Programming a PLC does not necessarily make a process!"

END_STORY:

Now, Ken, with respect to your question...

I can only assume that you want to be able to try the newer control system as long as it works but then be able to shift back to the older system if the newer system fails. This might mean switching between systems while the process is running.

If that is the case, then you should have all input and feed-back information available to both computers - all the time.

You should then, almost as Panic Mode suggested, use a switch to control the outputs.

Both computers know what's going on at all times but only one is actually controlling the outputs.

You should definitely be cautious about the conditions that might make you want to switch from the newer system back to the older system.

For example, if a move stalls under the newer system, switching back to the older system might cause a radical move.

In this case, you might want to monitor the status of that switch and provide for some kind of smoothing effect, or a move cancellation of some kind, when you switch from one to the other.

(49) (LU2E)

Taking into account Motor Overloads, E-Stops, and any other safety check already programmed in 'old faithful', I would simply have the new PLC send a request that the pump be turned on (networked or a relay contact energizing one unused 565 input, with a little modification to the 565's ladder - a branch checking the new input in parallel to the existing enable control.

If the 565 is powered down, or a fault occurs, that control panel shouldn't power up the pump. Think of the poor technician (ME) working on the panel & from some remote location a motor starter is energized & sends 480 volts through the panel.

Otherwise that pump should have it's own control panel, then it could monitor a request from each PLC & activate if either is on and no faults exist.

My suggestion is a auto-manual-off switch.

Off - no power goes to the motor starter, period.

On - Power goes to the starter, for testing or manual over-ride.

Auto - each PLC feeds a relay, which in turn has a contact feed the starter.

Sugestion 2 - Taken from a duplex pump panel - each source has a auto-off switch, so either source can be locked out, and another auot-manual-off as describe in suggestion one. An aux contact or slave relay on the starter cound give feedback to the plc's.

regards...casey

Thanks for all the replies. After explaining all the options/problems. The customer has decided to install a new pump for this new process. (Saves a lot of grief).

Terry, the old 565 will not be discarded. This plant was a "TI" plant until Siemens bought TI. They have 4 very large TI systems in place,used for process control, I have to admit I prefer TI over AB when it comes to process control.
The old TI systems, had built in PID loops, structured text, analog alarms, you name it.

The main concern with the old system I mentioned earlier is that it uses the 500 series I/O cards, which are becoming difficult to obtain.
The other 3 systems use the newer 505 series I/O, which can still be bought, but Siemens has announced the termination of that line as well.

Sometime in the next few years, we(me) will have to replace these older systems. Siemens is pushing an upgrade to S-7. But that will not happen, no local support for Siemens plcs.

Most likely upgrade path will be some sort of AB system, who knows what will be available 3-5 years from now.


Ken

Now that I've had a chance to read the original question... please ignore number-four! What was I thinking? (I quickly read it as a PLC replacement scheme involving hot-switching between the old and new PLC... oops! Nevermind!)

The pump can not operate under two bosses.
The pump must be designed to respond to only one boss.
The two bosses must arbitrate to determine the final state of the pump.

It is apparent that the TI is the boss.

As you already suggested, the other PLC should send "request information" to the TI. The request could have various "weights".

For example, the other PLC might send codes for...

Don't Care
MUST be OFF
MUST be ON
Turn ON, if OK by you.
Turn OFF, if OK by you.

There is certainly the possibility that you might have one PLC demanding that the pump be ON while the other PLC is demanding that the pump be OFF.

Just as in politics, each PLC has their own reason but at least one of them is not looking at the big-picture. YOU need to determine which has the better over-all view of conditions as they exist.

Since the TI has the final say, the TI needs to know how to reconcile contrary demands. You either have to ensure that each PLC "knows" what the other PLC knows (in which case, there will be no conflict), or you have to develop superior credibility in one PLC or the other.

If you know that the other PLC has the better view, then you tell the TI to provide as required by the other PLC. If the TI has the better view then the TI takes precedence.

In either case, if the demand by one PLC can not be met, then that PLC needs to know about it and needs to have a way to handle it.

(128)

There are a lot of reasons for "dipping your toe in" approaches to making a changeover. I've done it, and I almost always regret it. The approach that works best is a set of "Old/New" or whatever selector switches, but there are still a lot of pitfalls.

First, you had better have a couple of extra relays and/or switches to cover that one interlock or control circuit you forgot to include in the selector scheme.

Second, be careful to make the transfer from one system to the other as "bumpless" as possible. If you can shut down the pump or process befor making the switchover, so much the better. Depending on the equipment you can get anything from minor "burps" in flow or pressure to major problems and trips.

Third, and the most significant problem, is that the operators never want to let you run the new system long enough to debug it. I've had operators switch from the "new" to the "old" system at any unexpected, by them, event. This is true even if the event isn't a problem. This is true even if the old system at it's best is a piece of **** compared to the new system at it's worst. This is true even if switching to the old system actually makes the process run worse!

As Hamlet said, people are wierd, and there is something in us that:

".... makes us rather bear those ills we have
Than fly to others that we know not of? "

Avoid the dual system if at all possible. In most cases the extra expense, hassle, and time just aren't worth it. If you need to keep the process running, put in manual overrides, rip out the old, and put in the new.

Regarding I/O Cards

Hej Ken

I have seen TI I/O-cards, replaced by the new S7 I/O-cards, I think they used som sort of adaptorcard in the TI Main RACK.

Maybe, it is something worth investigate?


Jesper

beerchug