Coding PLC ladder methodology?


Thread Starter


Hi guys:

I have a question about how to write ladder diagram properly and methodology.

Since I have been reading and coding PLC ladder for about 6 months, then one question occurs to me. Is there a proper and good process of coding PLC ladder? The reason for having this question is because that when I reading those PLC code which others wrote, it is hard to understand or catch the background meaning of the code. there are thousands of net and I/O and logic interlock. so I wonder if there is a PLC writing methodology, which can help me design PLC ladder that others can understand code without pain?

Any website or book or insight would be appreciate.
sorry for my poor English...
thanks in advance

William Sturm

There are countless methods, depending on many variables. Some PLC's are easier to write well structured code than others. I think an reasonable method of organization is better than none. If you group your I/O and logic in some resonable fashion, then you are doing well, in my opinion.

Bob Peterson

Ladder logic is very good for certain kinds of coding. If you have a lot of stuff that is essentially operating in parallel using mostly Boolean logic it works very well, especially if you structure it that way and think about it that way. A surprising amount of industrial automation actually runs like this, although it is not always obvious at first glance.

It is less well suited for other kinds of control but if you are careful in your structuring you can make it handle tasks that are sequential in nature quite well too.

The problem with ladder logic is that it is easy to write code that is poorly thought out because it is so easy to write the code. A lot of ladder logic appears to me to have been written using the trial and error method. The programmer keeps changing the code until it works rather than writing code that works.
I agree with the other posts. I was brought up with Ladder logic by a mentor/friend who was learning ladder and understood sequential languages such as assembly and C. In learning on our own all those years ago and investigating what others do it amazes me at how diverse the industry is.

Your style should change with your equipment. If you hit a start button and a bunch of motors turn on with interlocks and warnings then ladder is quite easy to step into. You should not have a ton of sequencing, it is more of a "monitoring" application.

If you are getting into sequencing operations, motion control, digital/analog feedback and fully automated error handling it can get tough to just walk in without some guidance from one or more mentors. It is one of those industries where people that don't know what they are doing can get in and cause havoc so it does pay to follow good practice. I encourage you to find out who at your company is producing consistent predictable and maintainable code. This person may not be the fastest at the outset but doesn't spend all of their time budget fixing problems in his/her code. Also, start slow with a simple machine if you can. Big projects are broken down into smaller chunks so start with them if you can.

There are some books and resources often cited on this site, I encourage you to look into them.

Good Luck!
I don't know if you'll find anything formal written down. If you do, it'll probably consist of "Write lots of comments".

Personally, I don't write a lot of comments on most rungs. I find that if the individual points (I/O, registers, internal relays, etc.) in the ladder are well described, the function of the rung is obvious without having to take the time to write descriptions per rung. You only have to write the point synonyms / descriptions once.

Then at times there are ladder constructs that even with that are hard to follow, or you want to record some background information or leave a revision date and description and your name. In those cases I do use rung comments.
Amen to that!

I've often seen the organization of code done in a process flow manner (at least on a macro level). In processors such as a ControlLogix, separating physical groups of I/O and then having individual (or small groups of related) outputs with all logic within that file has worked well.

Even older PLCs (such as a PLC-5 or SLC series) can support multiple files that are sequentially solved and can hold a relatively small group of I/O that are related.

Of course, rung comments are vital to help others understand any logic. Paperwork is always a pain but I've found having adequate comments means I typically don't get callbacks. If I do get questions from the support staff, that is the first place I will look - did my team document well enough or are some of my clients just not adequately trained? Sometimes its a little of both.

There is never enough budget but there is always $$ to have someone come back to solve a problem (whether it is your cost of theirs is often an issue). No matter what language you use, telling others what you did pays back big time. I've found that if a plant likes what you did they will often call you back for the next project. A big part of that "like" is how well you told them what you did in the code.

Russ K

Curt Wuollet

I would think that reading a lot of ladder code would have shown, that if there is a proper method, it's not widely practiced. Not that there isn't some highly organized and/or structured code out there, there is just not a lot of commonality. I've been doing it a lot longer than 6 months :^) and I still find it rather hard to get the idea behind the ladder. Lately I've been doing a lot of state machines to make the code more understandable, but that only works for some types of programs and I'm sure state machines aren't obvious to some people either. I know some folks can spot the essence right away, but I'm unfortunately not one of them. And some people do write extremely bizarre RLL. Or it starts good and stuff is added and modified until it's a mess.