Partial program locks up

Hi group, why would part of a program stop executing while some outputs stay high? Sometimes this happens due to e-stop or vfd fault and I have to toggle a bit or power down the controller. (PLC5/40 & 80's 11 controllers 10 yrs old) Sometimes one will lock up for no apparent reason. This doesn't happen often but I'm just curious if there is a logical explaination.(it happened today) Seems most of the time the code affected has quite a bit of math instructions and N-bits being moved. Oh well, thanks for any input.
Jeff

Are the outputs in a subroutine that is not being called when a fault or e-stop occurs?

peoplehouse said:

Hi group, why would part of a program stop executing while some outputs stay high? Sometimes this happens due to e-stop or vfd fault and I have to toggle a bit or power down the controller. (PLC5/40 & 80's 11 controllers 10 yrs old) Sometimes one will lock up for no apparent reason. This doesn't happen often but I'm just curious if there is a logical explaination.(it happened today) Seems most of the time the code affected has quite a bit of math instructions and N-bits being moved. Oh well, thanks for any input.
Jeff

Click to expand...

It is hard to make an educated guess without seeing the PLC Program and Rack I/O Setup. It has been a long time since I set up a PLC5 Rack, but there are Dip Switches on both the Chassis and Processor that affect how it operates.

Does this happen to I/O in a Local or Remote Rack, or both?

You mention N-Bits being moved, are they being moved to Output Addresses?

Is it possible for you to post your PLC Program for us to look at?
If you can, zip it first. If you can't, the more detailed information you can give us, the better chance we have of giving you some useful suggestions.

There is a logical reason why this happens, we just have to figure out what it is.



Stu.....

You need to better describe what is happening. If the program is truly 'Locking Up', the watchdog timer on a PLC5 will trip, and the processor will hard-fault. Is this happening?
Do you see any math errors? Floating point going to INF or NAN? Overruns in integer math (32767 + 1 = -32768)?
What bit are you toggling?

Attached is from one of our controllers, the conveyor ST100 O:024/4 sometimes decides not to run after an e-stop or vfd fault. Once all faults are cleared, we restart the MCC and everything will run except for this conveyor (3-1 merge) and the conveyors feeding it. This doesn't happen all the time but when it does I have to power down the remote I/O, yep this MCC does not house the processor, just RIO chassis. I've never had time to diagnose the code when it happens so here you guys go!

Mickey I'm not sure about the subs, I'm not that good to know what you mean

RDrast, on this issue I've never seen any type of faults on the processor. The whole program doesn't lock up, just a portion. On this particular problem I haven't toggled any bits, just power down.

Let me know if you need more info, I've confused myself at this point.
Thank you
Jeff

Sorry my zip file exceded the limit by 3 kb. I'll think of something.

Hopefully this works, sorry there are thousands of rungs of code.

peoplehouse said:

Hopefully this works, sorry there are thousands of rungs of code.

Click to expand...

Jeff:

Is this the full Program, or did you delete some Subroutines to make it fit?
Which are the subroutines that give you a problem during an E-Stop or VFD Fault.
Are you using AB VFDs?

Stu.....

Edit" It's S100 O:063/14 I'm sorry wrong merge. I'm a dumb_ _ _
I did delete Lad 22 energy management, but e-mgt is not the problem.

I'm not sure which routine is the coulprit, I'm guessing Lad 58 but not sure. Alot of math intructions. RDrast asked about math overflow, I've seen that happen and that's not the problem. (Processor faulted and went to program mode.)There might be something going on in LAD 35 (motion CP4) but without the failure there is too much code to diagnose.

Yep, using PF70's. On this merge bed it's only used as a soft start and to change speeds from High to low depending on the carton flow.
Thanks again, sorry about the mix up.
Jeff

peoplehouse said:

Edit" It's S100 O:063/14 I'm sorry wrong merge. I'm a dumb_ _ _
I did delete Lad 22 energy management, but e-mgt is not the problem.

I'm not sure which routine is the coulprit, I'm guessing Lad 58 but not sure. Alot of math intructions. RDrast asked about math overflow, I've seen that happen and that's not the problem. (Processor faulted and went to program mode.)There might be something going on in LAD 35 (motion CP4) but without the failure there is too much code to diagnose.

Yep, using PF70's. On this merge bed it's only used as a soft start and to change speeds from High to low depending on the carton flow.
Thanks again, sorry about the mix up.
Jeff

Click to expand...

Jeff:

Ok, thanks for the update. The reason I ask, is when I did a Project Verify, it gave a bunch of errors. Missing Subroutines in File 2, some shorted branches, and two - "Indexed Address is not allowed" in File 58.

Stu.....

Thanks Stu, if you come up with anything or need more info let me know. If your ever in Cal pints are on me!

Jeff

if the program exits a subroutine because of an estop for example in a for next loop it will stack numbers on a memory and stop working because memory is full. Do not use exit or return inside a loop.
always run a sub till the end.

I haven't opened the program yet, but...

This is probably going to be something that you can only figure out while online with the controller during the situation.

Start at the rung that controls the output and backtrack.

Find the condition(s) that are keeping the output low, and search for their sources.

I am still young (been doing this since '96) but, I have never seen any model of Allen Bradley PLC run with a corrupt program. I have never seen one in RUN mode fail to do exactly what it was programmed to do. Every situation I have seen where the PLC-5, SLC, or Micrologix had a hardware issue or corrupted logic resulted in a FAULT LED and shutting down. If the program is corrupted, it will erase it, too, and force you to download a valid program before it will go into run mode again.

If your suspect PLC is staying in RUN mode, the problem is going to be with the way the program itself is written, one of the settings coming from a communication channel or something along those lines.

What you are seeing is not all that uncommon, especially with complex machines with a lot of code. The more code, the more I/O the more likely the programmer made a mistake, or failed to think of everything that could happen.

It is likely that restarting the PLC (power cycle) gets it going again because of what goes on in the controller during prescan.

Now, something you might try to get the whole program attached here:
1) save a copy with a new name...this alone can reduce the size of the database.
2) export the database (comments and symbols and I/O documentation)
3) delete the database and save again.
4) zip the program (with empty database) and attach it to a post
5) zip the database files and attach them separately (so we can put the comments back in it!)

shooter said:

if the program exits a subroutine because of an estop for example in a for next loop it will stack numbers on a memory and stop working because memory is full. Do not use exit or return inside a loop.
always run a sub till the end.

Click to expand...

This comment has caught my eye, is this particular to a certain PLC, or all types?
Do you mean exiting the routine, or exiting the loop? Surely the loop would be exited firers, or at least programmed to...

.....I have to power down the remote I/O, yep this MCC does not house the processor, just RIO chassis.

Click to expand...

I had an Allen-Bradley PLC connected to a remote chasis. When the PLC lost power suddenly, or faulted, often the remote chasis would loose communications, and it would not reestablish automatically upon power restoration to the main chasis. To restore communications, I had to also power down the remote chasis, then bring it back up. While communications was down, there would be all sorts of strange error messages appear on the main PLC.