Best way to debug a Ladder Logic

Hi Guys,
Iam just plain curious. How do u proceed debugging a SLC 500 program which has no descriptors in it? Recently i has to do one and it took me a hell lot of time to figure out find out each individual inputs and outputs and relate them to the addresses. Is there a better way anyone of u use to find the faults faster and make sure that the patch u applied doesnot create a more sinister fault somewhere else.For me its just difficult to figure out the impact my change(s) will have on other parts of the process. Do u have any structured approach on the path to take while debugging?

There is an old joke about electronic repairs:
all faults are of only two types- necessary connection missing and unnecessary connection present.
Applied to PLC, this sounds "PLC output" instead of "connection" .

With difficulty.

I normally start with the output that's mis-behaving, do a search on it, and work backwards from there.

One machine at work is fully documented - in French.
This is almost as bad as no documentation. I can't read French, but I can often guess.

I had to do this once and I got so frustrated, that i eventually got out the schematic, and labled all the inputs and outputs. it didn't fill in all the gaps since it didn't encompass bits/integers/strings/timers, but it made it a lot easier to follow the logic.

the find all function is also a big aid.

I treat an undocumented program the like a crossword puzzle. Fill in what you know and the rest becomes easier. First, do inputs and outputs. Once that's done, scan through the logic again, and comment any instructions that are directly related to those inputs/outputs. For example, if output 2/0 is motor 5, and is turned on by B3:0/2, then comment B3:0/2 with "Turns on O:2/0 (motor 5)".
Go through the logic again and find out what controls B3:0/2, and comment it the same way. Even if you are only guessing at what an instruction is doing, comment it anyway. Just make sure it's clear in your comments that it's just a guess.
As you progress, more and more of the logic will become clear.

Hello.
I usually work out from both sides, meaning the inputs and the outputs. after I figured them and sorted them accordingly, the rest just falls into place slowly. It's like working on the PL7PRO, which is what I am doing now. *sigh

regards

ST

docs?

Boy Im glad Im not the only one who sees this..

I start with the area that isnt working. Trace the logic back, every output, input and function block. You will have to trace wires and document carefully. Doug has a good idea, start with the output that isnt working.
If you have recent prints this isnt too bad, but still time consuming.
bruce.

Ianman has it exactly right! And, he has the right attitude about it... it's only a game.

Whether you are going through the code for urgent troubleshooting purposes or you are investigating the code at your leisure... either way, as far as resolving the various identities in the program, it's still a game.

Keep that in mind and enjoy the challenge.

I agree with Doug_Adam and lanman. Label The I/O, Start with the misbehaving output, Label what you figure out as you go. I've had to do this a few times, it's not easy but does improve as you go.

HMIs help

Dn't forget to also look for any sort of HMI (Panelviews, Wonderware, etc.). They will retain their annotation, and will be the source of contact bits that have no coils when cross-referenced.

If the inputs and outputs are the "ends", the HMIs will provide clues about "the middle"

Good luck (I'm currently doing the EXACT same thing for a client.) One helpful tip. When you first guess at the function of an address, put "????" in the description. Once you have the AHA moment, and you are no longer guessing, remove the "????". This will help you keep track of what's know and what's still not sure.

And do a thorough search for old floppys. There may be a backup of old code, with annotation SOMEWHERE