Reverse Engineering Complex Logic

Do you know any simple ways to trace out logic and document it in an easily digestible way?
I just spent about 3weeks tracing out logic in Modicon 986 Processors that a contractor put in over a 2 month period. This logic was incomplete and not functioning properly. I was tasked with reworking his existing logic and making it work as we originally intended. There are 4 processors total using MODBUS+ Global reads and writes. I was able to accomplish my goal however I felt as though there must be some methods I can employ in order to maximize my efficiency. I wrote lots of flow charts and IO addresses with arrows to and from machine a to b.

Do you know any simple ways to trace out logic and document it in an easily digestible way?

Click to expand...

For some things in life, there are very few short cuts. Figuring out someone else's poorly-documented logic usually takes a lot of time and effort with your nose to the grindstone.

As for documenting logic, I think that is best done with rung comments that actually explain what the rung logic is supposed to do. If you can identify the purpose or reason for that rung, and write it in one or two sentences, then you will make the next guy's job much easier and he may even think, "why, this program is great and the logic is so simple anyone could understand it"! That feelong only comes from much hard work and time spent figuring out that "simple" logic.

rootcon said:

Do you know any simple ways to trace out logic and document it in an easily digestible way?
I just spent about 3weeks tracing out logic in Modicon 986 Processors that a contractor put in over a 2 month period. This logic was incomplete and not functioning properly. I was tasked with reworking his existing logic and making it work as we originally intended. There are 4 processors total using MODBUS+ Global reads and writes. I was able to accomplish my goal however I felt as though there must be some methods I can employ in order to maximize my efficiency. I wrote lots of flow charts and IO addresses with arrows to and from machine a to b.

Click to expand...

Sounds familiar I made my thesis work from similar case. At that point I didn't find anything really usefull written to books nor software. Everything I found were books related to pure PC and similar software not for realtime systems. Now I have been balling the idea to take an another look for the subject, but until now I have been too busy on other project. Task weren't any easier with zero comments on the code, nor existing knowledge of Siemens S5 statement list programming. Learned more than in the years studying these.

I ended up printing whole code to paper (about 70 pages) and after that made excel sheet of all memory and I/O addresses and gradually working through of that swamp to name everything and double checking my sources that it is what I though it was. Took me one long summer, some bottles of whisky and too many iteration rounds.

This book published under creative commons were helpfull to get the right mindset, but again there weren't much usefull methods to do this in automation world.

http://scg.unibe.ch/download/oorp/

A lot of the times when faced with poorly documented equipment and doesn't function properly, its quicker to just start over from scratch. I have a tendency to rip out old obsolete PLCs, relays, and ESPECIALLY custom OEM built circuit boards, and replace them with off the shelf replacement parts that are in stock at our electrical distributor. I also can't stand OEM PLC programs that are programmed for 100s of different models, then "modified" for your application, leaving TONS of unused and useless tags and causing things not function properly. If you can sell the idea to management and you have the ability to do it, its far better to do most of your electrical work "in house" making it far easier to maintain. And a lot of times its quicker and easier to start over from scratch than try to "fix" something that is flawed from the beginning.

I agree with Lancie1 about commenting.
I usually start by commenting the program to document what each rung actually does then go back and read the comments to see if the logic makes any sense.
In some cases what you find is that the existing program is not worth saving. It may be quicker and easier to scrap the program and start over re-using just the I/O that is connected to the PLC.

helliana you are so good, i have in my hands a new renesas RX100 processor, when you start their program just to blink a LED on the board it comes with a program with lots of options, btw the led does not go on, due to a FET that needs to be powered low.

reverse engineering is always tricky, i make my own flowchartset with a running machine if possible. trying to find all possibilities.
then make a new program.
esspecially communications are difficult.

The only hindsight I have on your problem is this: I once TRIED to reverse engineer the logic on a machine. I gave up after 2 days, went straight to the operator and ask: ok, what does it do? ...then I took the Principle of operation and the troubleshooting guide in the manual and whipped up my on software.

A lot of the times when faced with poorly documented equipment and doesn't function properly, its quicker to just start over from scratch.

Click to expand...

I once TRIED to reverse engineer the logic on a machine. I gave up after 2 days, went straight to the operator and ask: ok, what does it do? ...then I took the Principle of operation and the troubleshooting guide in the manual and whipped up my on software.

Click to expand...

A lot of people seem to think like this, but it can be dangerous. Often when you think you know exactly how a machine and program operates, there are really some hidden issues that never entered your mind.

I say every case is different. If your boss buys an old palletizer system from another shut-down plant, labels the wires, cuts it up and takes it apart, moves and reassemblies it, but needs it to work differently (stack bags of a different size for a different pattern with a different number of layers), then would you still rip out the old program and start over, knowing that the only information on how it works was the old program itself?

In that case it might be wise to first try to get it running like it ran previously, and only then try to modify it to do the new stack. If you boss is like mine always were, you don't get paid to reinvent the existing wheels.

Very valid point. You said it yourself... depends on the situation I guess

I agree with the note about making a spreadsheet of addresses and populating it as you go - use paper if you dont have multiple screens - this helps tracing things out.

The first sequential function chart program I ever had to work on was written by a German engineer. He was very good. The problem we had was terminology. At first this system was junk that didn't make since to anyone at the plant.
I printed out 3 of the SFC on a plotter. I spent a day going over each step of the system to see what function happens when. The system had loops inside it. Instead of going back to the first step it would return to the third step or second depending on conditions. Once I spent the time on this system it was a very well layed out system.

Tom Jenkins has said it several times (paraphrasing) people look down on what they don't understand. I was guilty of that. I try not to that anymore.

I start with the I/O. All of it, even if I think that the some of it isn't relevant to the issue I'm trying to troubleshoot. Once you get the ins & outs tagged then the stuff in the middle should make a little more sense. But, ...you know, sometimes it still doesn't. I've retagged some internal bits 5+ times, thinking I finally figured out 100% what they were for.

Hi Rootcon,
There are a few techniques that you could employ to reverse engineer the program. Take a look on the web for FSM (Finite State Machines) or Transition State Diagrams as a couple of methods that you could use. The latter may be the easiest technique to use when you list out all Inputs/ Outputs and determine there transition using the diagram.
I can root out some college notes if your stuck but I am sure there is plenty of information on the net that would help get you started.

Regards,
Donnacha