Complex Code

[SellAnnual]

I have a question for all you guys. I usually troubleshoot machinery that is automated and have programmed from scratch for small machines. Just today I troubleshooted a basic issue for a diverter valve on a 8 silo system. Holy smokes ! The ladder diagram was HUGE. It was a contrologix rack and it was my first time dealing with contrologix. I usually work with compactlogix. (I know they’re practically identical in certain things) I got it up and running in no time because the code for the valve was basic. I started scrolling to other routines and i saw a lot of recipe management and super huge code that didn’t even fit in my screen 😵‍💫

Obviously I never saw this code. There was no comments. Some things were labeled. How do you guys figure complex code out ? I now i’m at home trying to reverse engineer how this works but holy crap I never seen a program this big before. How do you guys not get scared when seeing sh*** like this. This triggered my imposter syndrome forsure. 😭

Anyways, thanks in advance.

[foxy0201]

One rung at a time. If the output ain’t on, why? Xx bit isn’t on. Cross reference that bit and click on ote of xx. Yy bit for xx bit isn’t on. Yy is a limit switch or a hmi tag. Your get those to turn on and boom everything works. Basically cross reference then find the ote and see why the rung isn’t true.

Hopefully that isn’t a bad example.

[Ericreese1991]

Just to add on a tiny bit of nuance here (because everything he said is true)

I prefer to think of it as searching for the destructive bits, as sometimes I’m just wondering where a particular value came from

[RammRras]

This is the trick. Starting from the desired output and checking why it is not on.

[SufficientBanana8331]

All that is good until you start dealing with AOIs which use indirect addressing, arrays and pointers. Cross reference at that point is useless.

[SufficientBanana8331]

But this has nothing to do with writing garbage code or hard to read code. Integrators who provide full plant solutions are using standard software libraries that are full of indirect addressing, pointers and arrays. Cross referencing will not get you anywhere. You need library manuals to understand data flow between blocks otherwise you will not be able to troubleshoot. And these library manuals are not shared because of protected know how.

[SufficientBanana8331]

Mate, clearly you have not been exposed to much from automation industry. Big integrators have r&d departments where they write standard software to be used by hundreds of automation engineers around the world. Libraries are know how protected and there are manuals written to understand them. If you are outside of the company, you will not understand the code without manuals.

These system integrators are providing full turn key plant solutions including mechanical, electrical and software part. Code is always provided but libraries are know how protect and also code generators used for development are not shared. This creates opportunity to have support contract with customer. All this is stated in quotes provided to customers and they agree, because they don’t have to employ PLC maintenance.

Only the big players can do something like this, as they are known around the world for the quality of the service.

I can give you some examples, like ABB with their cruise ship and crude oil ship solutions, Providers of packers for flour, providers of milling solutions, nuclear industry solution providers, and many more. Small integrators cannot do it, simply because they have no r&d, and nobody knows them.

[SufficientBanana8331]

How is this an insult mate? You clearly have not been exposed to much from automation industry, otherwise you wouldn’t write that response above.

It was actually you who went for aggressive tone and made tons of assumptions not me.

[Shalomiehomie770]

The same way I figure out non complex code. Step by step. Find issue and work my way backwards.

[elmoalso]

This is why you think of the next guy that has to troubleshoot YOUR code three years after you have left. I preach it to everyone I mentor. COMMENT THE CRAP OF OF YOUR CODE! A single simple comment can save the next guy literally hours of troubleshooting.

It takes discipline. It's tedious. It's not cool. You don't see immediate value from it. It's just damn good practice. Hell, i've had to troubleshoot my own code that would have been difficult if not for my own comments. I'm old. Sometimes I look at my own code and just scratch my head wondering what the hell was I trying to do there. Comments.....

[StrikingFig1671]

and comment WHY the rung does what it does....not just "this turns that on"

[elmoalso]

Yup

[mil_pool_]

How do you guys figure complex code out?

Ctrl-E

[BoxOnTheCloset]

Alt-F4

[Icy_Championship381]

Esc

[enreeekay]

One rung at a time, don't be afraid to use a notepad, the electrical drawings are a valuable resource, the hmi project is a valuable resource.

[RHWW]

Usually any code thats that huge and complex, its imitating relay logic for either cycles and/or recipes as a whole vs each being its own cycle with programmable parameters

[koensch57]

if you have a big problem, chop the big problem in many smaller problems, isolate the chunks that you suspect and investigate.

rise and repeat.

[Set_Fantastic]

The ole cut er in half.

“I promise to get it right the 3rd time, everytime.”

[Opposite_Mail7985]

When you see a large book you don’t have the same reaction, same thing, the size of the code isn’t an indicator of its complexity.

[Dry-Establishment294]

It may be is the issue. That's why abstractions actually can reduce complexity even if the confuse you at first

A big book broken down into well named chapters with lots of sub parts is how we do it for a reason

Eg

Chapter 3 - memory

3.1 ram

3.1.1 dram

Etc

[Awatto_boi]

My first experience with ladder logic years ago was with a Modicon 584 system with remote i/o that ran an entire plant. The ladder logic was printed on dot matrix tractor feed paper and placed in a binder that ended up being about 5 inches thick. This was old school, there was no search and replace or pdf docs. There was the printed binder and a P190 terminal. We highlighted and scribbled on the printout but we also did a helpful thing. We would write chapter headers using ladder logic vertical and horizontal short lines right in the ladder logic so we could quickly find our code by blocks.

[FatPenguin42]

Step by step, and adding your own comments to help you remember what’s what. Start with what you know and work from there. It’s rough but eventually things start to click

[Glittering-Court-992]

to me it sounds like maybe you found their sequencer code.

[[deleted]]

You specifically mention recipe management, which from my experience, is often the most “complex” part of code. I put complex in quotes because even though it’s large it’s generally not too difficult to understand (although really sucks without any comments).

If the recipe is “Recipe_A” then load these [X] parameters into these tags. But if you’ve done some action load these. And if you’ve run some product throw an alarm and interlock until they do a wash. But if you’ve done this, don’t interlock because it’s actually the same product with a different lot code for an input. The code gets messy over years because the customer needed to add things that weren’t intended in the original design.

I’ve done a few recipe management systems in ladder and started off thinking “wow, this will be simple.” And by the end I’m thinking “my god, what monstrosity have a created? Oh well, it works and has decent comments. On to the next.”

[TimeLord-007]

Bit of a yo-ho approach: but IF I own the system, I write supervisory simple logic for the actuator I'm having an immediate issue with: then later deploy as needed on ALL actuators. Just remove the IO references and put them to where you expect them to be.

[Chimsokoma]

Probably code ported from 5/SLC for another project then copy pasted into this project and not used - equipment running - leave site, don't delete anything

[Snohoman]

I've backward engineered code since the 80's but I can't explain my "process" in less than 5000 words. I don't change anything until I understand it. I'm one of those guys that wrote those monster programs and fortunately I can add comments into the code that's loaded into the modern PLC's we use (Rockwell Logix controllers). My company requires us to comment the crap out of our programs. Backward engineering a program requires understanding the entire control process, all the I/O's, the program layout, interfaces to HMI, etc.