Sign in to follow this  
Followers 0
sadlerej

PLC Memory

12 posts in this topic

I have a plc that I believe has been adversely affected by current on the ground. I know that plc’s are to be supplied with there own ground, which is happening now. Let me give you a little background of the issue, an existing plating line was upgraded from running cadmium to nickel/tin I modified the program for the new sequence and upgrades (RTD’s, VFD’s… etc). The line ran for about 3 weeks then it was discovered that when the line was switched from auto to manual then back to auto it no longer remembered where it was. As I was investigating this, other errors started to occur, little by little the line was degrading to a point that it could only be run in manual with no process codes. I decided to change the processor the problem went away. After about 6 weeks the issues started to return I found that the motor gearing was being shorted to the rectifier through several different conditions on the flight bars, the short was going into the motor ground and back to the control cabinet. Okay now that you have a small glimpse of the background my questions are these: I just want to verify my troubleshooting. Is there away that program memory can be consumed on the fly? Is there away that the program can slowly degrade over time? Is there away to check the plc’s memory. If so how? Is there away that a program can allocate a certain memory location meaning can I tell n151:0 to use 0x100 memory location? Or is memory picked by location or use in the program.

Share this post


Link to post
Share on other sites
What model of controller are you using ? Although you put this post in the Allen-Bradley section and mentioned a PLC/SLC style address, you did not mention which controller. Program memory cannot be 'consumed on the fly', in the sense that it gets allocated to a no-longer-functioning routine. Controllers are much more careful with their memory than multipurpose computer operating systems. Nor can memory 'degrade over time'. Most controllers run a checksum on their program memory every single execution of the program, which detects defective memory immediately and shuts down the controller. Noise problems are going to show up on the communication ports usually when they are also affecting the controller. There's no acceptable level of memory failure, so any damage at all will fault the controller.

Share this post


Link to post
Share on other sites
I am using a slc 5/04. Is it possible that I have a chassis problem then? I am not sure how it could work for 6 weeks or more then slowly fail. Or possibly a heat issue or power supply issue.

Share this post


Link to post
Share on other sites
It would be rare indeed for a SLC program to "slowly" fail, and the source of the problem not to end up being the user program, something external to the PLC rack, or plain old operator confusion. It's all or nothing with a PLC, sometimes to our chagrin!

Share this post


Link to post
Share on other sites
I've had similar problems, all were caused by power quality. Brown outs were especially troublesome. Seems the SLC ram goes a little screwy under low voltage conditions.

Share this post


Link to post
Share on other sites
So did it actually keep running with corrupted data? that's a scary thought!

Share this post


Link to post
Share on other sites
NO Once the corruption started, it would stop, not exactly like the OP, I guess I mis-spoke. Once it happened, you couldn't go online with the processor, always had to download the program again. The short term fix was to install a EEPROM and load from it at every start, long term was to correct the power problem.

Share this post


Link to post
Share on other sites
First off if you suspect you have power problems, buy a decent UPS from Tripplite or APC, or at a minimum, a power conditioner. You can buy a power quality analyzer but even a Fluke 43B is much more expensive than a UPS. Once you have done this, it will at least take the whole power quality issue out of the picture. Second, there is a way to corrupt PLC "memory". If you screw around with AB PLC internal queues and bits for the block transfers and message blocks, you can cause a crash. I know because I've done it before I understood what was going on. Beyond that though, the basic memory structure is static...you set it when you set up the program. Outside of overflowing communication memory queues (which just cause it to "lock up" and stop talking), there are no memory allocation commands in a PLC. This does not mean buying one of those hateful Sola "CVS" (constant voltage source) things that are anything but constant! The biggest use for a CVS is if you want an inefficient electric heater. I don't know what the hangup with buying these things is and I've seen multiple plants with them. If you find one, get rid of it. You will suddenly notice your power quality getting better even if you connect directly to the supposedly degraded line! I have actually documented and measured this happening. What is usually most likely on any PLC is that the PROGRAM has problems which can cause issues over time. When you read the code, if it is chock full of latches and one shots, if it uses lots of MCR zones, if it uses multiple MCP's or JSR's with conditions on various ladders (or perhaps flips the MCP bits on and off), or if it has a mix of lots of internal state bits and simultaneously relies on lots of limit switches but that the checks on the state of the "external world" vary all over the place, you have a definite candidate for this kind of thing. What happens with these types of programs is that they are chock full of what the boolean logic world calls a "hazard". For example, you can have something like this: If the hopper weight is <100 lbs. and the "hopper filled bit" is cleared, then run the "feeder" relay If the hopper weight is > 100 lbs., then latch the "hopper filled" bit If the hopper weight is > 100 lbs. and the "hopper filled" bit is true, then open the hopper gate If the hopper weight is > 100 lbs. and the "hopper filled" bit is true and "mixer is on", then set the "hopper emptying" bit Imagine for a minute if the scale just hits 101 lbs. on one scan and then goes back to 100 lbs. on the next scan, what happens? Scan #1: The "hopper filled" bit gets set. The hopper gate starts to open. Scan #2: The feeder will no longer run, but the hopper gate never fully opens. The program is "stuck" because there is an illegal state...it can't be "filled" and "not quite filled" at the same time. Worse, what if the conditions on "mixer is on" take a little less or more time than expected and the mixer doesn't happen to be on? Let's extrapolate to what happens next... The operator gets frustrated because the darned thing keeps "locking up" and just sits there, doing nothing. So in desparation, they manually force the actuator to open the hopper or stick a shovel down into the top of the hopper. Everything then may start working or depending on how the code is written, it might do something quirky like it might start working again for no reason. The programmer comes along, sees what's happening, and says aha! There must be something going on that has to do with timing. So I'll just liberally sprinkle everything with one-shot statements and a healthy dose of timers. So everything works again...for a time. Somebody recognizes that it has to do with the scale. So they replace the entire scale unit and call 3 different scale companies to come in and diagnose why the scale isn't working right. The production crew on third shift doesn't know what first shift is doing. All they know is that the darned thing usually locks up for them and then the technician comes over and reloads the program...and then suddenly everything is fine. However, the technician is using a copy loaded on a laptop. The programmer is getting PO'd because every day he gets called in to fix it again right in the middle of his lunch break. And every day, all the changes he made the previous day seem to have disappeared. Somebody or something is obviously altering the program! It is either a malicious technician or some kind of strange memory error, right? The solution is to recognize exactly when and where a program relies on some sort of internal state, when that state can become different from reality, and when it relies on maintaining a certain input condition continuously while other states are changing around it. There are three ways of dealing with hazards in a program. First, remove them if they are unnecessary. If the program detects that a photo-eye is made once and acts on that information, is there any reason to require it to be maintained constantly (just drop the extra condition)? Second, if loss of an input condition would indicate an alarm such as if the bottle in a filling operation suddenly wasn't underneath the filling nozzle, should this trigger an alarm? Third, it can back up a step and check the condition. For instance, when doing a filling operation, the inertia of the material hitting the hopper will give an artificially high weight. So many filling programs pulse or dribble at the end of their cycle to correct for this "overshoot". The simplest version is to have something like this: Step 1: Fill until scale reading reaches set point. Step 2: Wait until the scale reading stabilizes. Step 3: If the scale reading is less than set point, go back to step 1. This is an example of the "back up and recheck" method.

Share this post


Link to post
Share on other sites
Thank you to all who have responded I was able to take the line out of service this morning for troubleshooting. I loaded the old program that was running since 1991 and the program acted the same way as before. Is there a good way to isolate the i/o both discrete and analog to insure that I am not getting bad signals back? Thanks Ed

Share this post


Link to post
Share on other sites
when I said “acts the same way as before” what I wanted to say was that the old program acts the same way as the new program, losing the information.

Share this post


Link to post
Share on other sites
Okay found the issue, first though I would like to thank all who responded to this post. Because of your willingness to help the less experienced I was able to put aside the thought of a memory issue and focus on the problem. After searching the program (online), a bit that should have been 0 was a 1 searching through the schematics I found that the bit was linked to an alarm silence button, apparently there was an alarm and the operator put a 2” piece of air hose in the button to hold it in. The program looks at that button when it is switched from auto to manual and resets the system. I took the hose out and the system works fine. I have the hose on my desk as a reminder to search all possibilities before formulating a cause in other words dive down to the root cause. Again thanks for your guidance. Ed

Share this post


Link to post
Share on other sites
Change the reset contact to a differentiated contact (one shot). Then the operator can stick all he wants in there but it won't matter, he will always have to release and press the button again every time the horn sounds, and it won't stall the program. Then you will probably be notified up front when there is a problem instead of you having to find out afterwards like this

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!


Register a new account

Sign in

Already have an account? Sign in here.


Sign In Now
Sign in to follow this  
Followers 0