I have just commissioned a PLC program for valve sequencing of 5 Water Filters on an oil field injection system. The program is split into 24 files with the first file, File 2 a set of subroutines for the remaining files. The PLC power is not hooked up to a UPS system and is on 120Vac mains.

The system is working at a desert location and power outages are common before diesel backups kick in. So, twice now in one month following a power outage and reset, the PLC program did not auto start, the Input leds were on but the output cards were all off.

The technician called out tried the logic reset on the PLC panel with no success. He then switched the CPU keyswitch from Run mode to Rem & Program then back to Run mode again...the PLc rebooted with Output cards online and the system is OK again.

Is this normal? Is this why PLC's are connected to UPS normally?

Best regards
Gray

 

Maybe there's a fault condition and that's why the PLC doesn't restart in run mode. Next time, ask the technician to check if there's a fault light flashing.

 

There is a narrow window with most electronic devices where the power supply can neither hold up, nor is the processor completely shut down before power is restored. PCs commonly show this one of two ways, the power supply stops functioning until completely reset or the machine goes off into la la land executing who knows what mix of expired bits and original content. I would expect it's close cousin, the PLC to be subject to the same phenomena. And yes, you can either use a UPS, or if a reboot is safe, a relay latch and/or timer can ensure that the power stays down long enough to cleanly reboot.

This window tends to widen as equipment ages, particularly with switchmode power supplies.

It is also possible that some nasty transients that occur on switchover are disrupting the PLC. Both of the above solutions will tend to prevent this with proper design. For PCs, I use a UPS with a short timer, on loss of power, in 2 -10 minutes, I shut the machine down cleanly if power hasn't been restored and _shut off_ the UPS. This way it's positive, it either rides out a short disruption or is shutdown completely in the proper state to boot cleanly when power is restored. The reason for the short time is that there may be more than one of these events and the UPS retains enough reserve to handle it. If you run the UPS to it's shutdown point, it ceases to be useful. I've done software that does this with the APC Smart UPS, not all UPS are capable of accepting a command to shutdown in X minutes after the computer is safely down. With a PLC, I suppose you would need a BASIC module or some such to send the commands to the UPS and receive it's warnings. I've had power bounce 5 or more times during a storm with varying lengths of no power and this has maintained sanity. Even the manufacturers haven't figured out how best to use their products and the multiple outages will kill you with their software.

Regards

cww

 

Gray---

The behavior you see has been programmed into the 5/03 by bits set in the status file, possibly with ladder logic setting them. The programmer might have had an objective in mind when making the choices, but they clearly aren't choices that you wanted.

By default, with no choices set, a SLC 5/03 will shut down gracefully when power is lost, remembering all data. Then, on restarting, it will work with the old data and new inputs to continue running the process as if it never stopped. A UPS could help you avoid this sequence, but most 5/03 users just program a graceful restart.

If a Major Fault had halted the processor, other choices could help clear the fault and then proceed to a graceful restart.

You need to bring in an expert on SLC500 programming and have that person change the choices that are programmed into your 5/03 to the choices that you want. This could be as simple as changing one bit in the Status File, or it could involve complex changes to your ladder logic. The simple solution is more likely than the complex one, but it all depends upon why your system was programmed this way in the first place.

The original programmer is the best candidate for solving this problem. If that person is not available, contact your Rockwell distributor for other alternatives.

Hope this helps!

Larry Lawver
Rexel / Central Florida

 

Dear Mr.gray.

Usually the Program is stored in RAM in PLC. which is a volatile memory so, power goes off then no prog is in RAM...

Common pratice to avoid is using Flash EEPROM with battery pack in the PLC itself... and in the program option we have to select power on loading from EEPROM... so, once the power is restored the PLC automatically takes the program(ladder) from EEPROM... no need to switch between run & prg.

check whether EEPROM is available in ur PLC if so, check the status of battery..

karthikeyan.s
[email protected]

 

On September 2, 2003, gray wrote:
> The PLC power is not hooked up to a UPS system and is on 120Vac mains. <

We are putting all of our critical PLC's on UPS's for >:30 min runtime. Comsidering the remote location, I recommend you giving some consideration to UPS for your application.

> ...the PLC program did not auto start, the Input leds were on but the output cards were all off. <

Sounds to me like the SLC was faulted, the keyswitch sequence you described is the method to clear the fault without going online with the SLC. Power glitches can and do cause SLC major CPU faults. If this is the reason for the fault, a UPS should solve the problem.

Dan

 

This is abnormal behavior. There are two things to check out here.

1) Your PLC power supply. I encountered an instance where a faulty power supply was screwing up a PLC, but only on power failure, the PLC came back up always in PROG mode. Changing the PS cured it for some reason, but this was on an old system.

2) Make sure that nothing is overwriting the S:1 register. This includes the PLC program itself and any attached HMI unit. The S1 register controls the PROG/REM/RUN mode. See the SLC500 insturction set reference manual (status file) for more information.

Also, post this one up on the RSLogix forum, others may have encoutered something similar.

 

Hello Gray,

On September 2, 2003, gray wrote:
> Is this normal? Is this why PLC's are connected to UPS normally?

It is when the SLC faults. If it happens again have your onsite technician look at the LEDs on the SLC Processor. My guess is that the RUN LED will be off and the FLT LED will be flashing red. This indicates a Fault in the SLC. Rotating the Key Switch from RUN to PROG and then back to RUN in a SLC clears the fault and returns the processor back to RUN mode. In RUN mode the RUN LED will be solid Green and the FLT LED will be OFF.

The big question is what is causing the SLC to Fault? Next time the Fault occurs someone needs to connect to the SLC with programming software and read the Fault code. Once you know what is causing the fault you can fix it.

I would guess that you are getting some sort of odd power spike into the powersupply and onto the backplane of the processor. However, that is just a guess.

A good active line filter and small UPS might solve your problem. However, if it was me I would still like to find out what the exact problem is.

Bradley G. Hite
Intertech Inc
mailto:[email protected]
Teaching Practical Skills for a Technological World

 

I don't know the internals of your particular PLC, but safety dictates that you do not restart a sequence after a power failure without a visual 'all clear' and a manual 'reset/start' (of some kind).

Doug M.

 

The SLC may be faulting on power-up for various reasons. You might try creating a Fault Routine to capture and clear the fault or set the Fault Override at Power up Bit S:1/8. When set, this bit causes the controller to clear the Major Error Halted bit S:1/13 and Minor error bits S:5/0 to S:5/7 on power up if the processor had previously been in the REM Run mode and had faulted. The controller than attempts to enter the REM Run mode. Set this bit offline only.

Good luck,

Michael E. Crossman
PLCs Plus International, Inc.
http://www.bkppi.com

 

I have seen this occassionally. The fault word normally will tell you what went wrong. Often it seems an analog I/O card powers up but the cpu does not see it or sees a fault there. This will fault the processor in a slc500 system (who knows why, but it does).

I'd be inclined if it happens again to get online and check the fault register and find out what it is.

I have also seen this error on power up caused by bad programming technique. e.g.- divide by zero will put the thing into fault mode. sometimes people do not initalize things correctly and once in a while they get caught. there is a status table bit that can be unlatched at the end of each scan to stop the cpu from faulting in the case of an arithmetic problem like this.

 

Many thanks to all on the forum for your comments. More info please from karthikeyan.s is greatly appreciated.

When you say on the forum on Sep 4, 2003 that I can change the program options to read from the EEPROM rather than memory direct, what are the steps to take to reconfigure the program?

TO be honest, I wrote the PLC program, but I am not a programmer, however I gave it a go and it works reasonably well except for the glitch on power fail. As you can imagine, the UPS is required but is over the top if I can solve the problem by reconfiguring as you say.

I can only work offline on the program until I go back to the desert location (no email) and I can't see where I can change the options. We can install 1747-M14 EEPROM with already installed 1747 BA lithium battery back up.

Thanks in advance
Gray

 

Hi, We avoid power outages to processors because we are afraid that if once down, it may not get up again!!! However, this is not the way it should be! This is how it should be----Power goes and comes back, processor restarts, perfoms logics and you are ready to start. Also note that this does not occur with all processors, taking us back to a very dynamic state at power restart that affects a processor out of many!!!

I have seen similar problems with a couple of PLC's previously. In one case there were 14 PLC's that went out at power loss and 13 came back without this glitch, all from the same power supply along with several SCADA - Fiber optic hub and MIS stations, HP-UX etc. etc..

The core reason could be transients in power supplies.There are no obvious fault conditions shown in any diagnostic LED / Processor. And the problem occurs randomly and rarely. so you have to break your head to resolve it and you are never sure of the results. Only solace is that it does not happen again duringyour tenure.

Do you have a Separate Earth pit for the processor or the same earth pit for all electrical equipment and control systems? If there is a small transient occuring in your grounding system for very short durations at times, and this is causing the processor to hang up, then nothing can really help you. In other words, check the grounding and whether the earth pit is still wet / moist. Check the ground resistance. Maintain your ground! Use a Separate Earth Pit for the SLC.

Getting a UPS for the processor is a good idea even without the problem faced by you. They are so cost efficient nowadays!

One random doubt after the time of the above mentioned woes was that 'if the RAM is not being cleared by the Processor Program at restart or any such routine at start has a rare bug, then at restart it might occassionally enter into state 'glitch'........' Then there's really nothing that you can do to resolve this except an UPS to avoid processor restarts. But I left this line of thought. AB is a 'solid' vendor likely to have strong testing methods for software to avoid such minor problems coming into the market.

Best Regards,
Anand Iyer

 

A thought just occurred to me on this. I had a site once where the power quality was poor and after an outage the restoration of power was sometimes kind of ragged, often leading to bad restarts on the PLC, a SLC 5/05. For some strange reason, the customer didn't want to install a UPS, so I put in a $50 power monitor (voltage, phase balance, etc.) from SSAC, that would set an input to the PLC for fault recording purposes, as well as delay the PLC restart after an outage until the AC line parameters were within the field-settable limits for a couple of seconds. The power was thus guaranteed to be much cleaner by the time the PLC was restarted, and this fix seemed to cure the problem.