Steve Bailey, I also don't know how they pick me.

[jvdcande]

I've received another e-mail through the forum. Geoff Robertson wrote me:

Greetings.
Are there standards in how one lays out ladder logic or are we at the mercy of the style of the programmer? it seems to me there are many different ways to accomplish the same task. I've seen pages and pages of logic that could have easily been reduced to one page of logic and accomplish the same thing. any info regarding this would be helpful.
Thanx,
Geoff.

Well Geoff, first of all let me emphasize again, as I did on other occasions like this one, that it is under any circumstance best of all to post this kind of questions on the forum and not direct it at any one of the members personally. I'm only a small fish in the pond. Yes, I know some PLC (sorry iknowsomeplc, not intended to steal away your username ), as so many of my highly appreciated colleagues do. Yes, I've given answers to various questions, again as so many of my esteemed colleagues here also did. And no I don't know more than the numerous people here who try to help others with their questions about PLC's and who I think of as friends.

Our (and not my) strength is in our numbers. If you address your questions to us all, you're bound to get a better, quicker and more complete answer.

Now regarding your question: "Are there standards in how one lays out ladder logic or are we at the mercy of the style of the programmer?"

Well, I for one never intended for a user of the programs I wrote to be "at my mercy" as I'm sure most of us here don't. For me it was always one of the most important things that any service technician should be able to read the programs I write. In this view your remark "I've seen pages and pages of logic that could have easily been reduced to one page of logic and accomplish the same thing." should be read with caution. I've seen programs written in the most compact way possible, but to understand what the darn thing did took me hours, which could easily be filled with more fulfilling work. Remember: a program is written once but serviced numerous times over the lifespan of the machine. Imagine you even don't understand a program you've written yourself only a few years agoo, simply because you didn't document enough and you slimmed it down to minimal size without taking readability into account.

I always try to teach my trainees to write readable, well documented programs. To ensure the presence of structure in these programs I teach them to use structured design techniques such as flowcharts or Nassi-Schneidermann charts for calculations and dynamic state diagrams or sequential control charts for sequential programming.

But this is only my opinion in this. I'm sure everyone else here has strong feelings about this topic. So, friends, please feel free to discuss this topic further.

Kind regards,

 

[Rube]

Jean Pierre (and Geoff)

I echo Jean Pierre's thoughts and would only add one thing. Use of any descriptions, labels, comments, revisions, etc. should not be underrated. Take any program you have written, remove the labels etc, and then try to work your way through the program. When all you have is the stripped down program, you automatically slow down diagnosis and corrective actions, which in my plant equal down time and a lot of ticked off people in suits and ties.

 

[dandrade]

The subject emerges the codification style, resources and knowledge of who codified.

Essetialmente, it has you vary combinations to get a final result. I relate the use of instructions and order of position
Sic count time: a timer or accountant trigger in intervals
It defines, an individual style of programming, codification

Style of programming - Way to compose a set of instruction supported in a way of development

But guy, it supports in a development base. Meaning of knowledge it possesss on the task, the knowledge that it dominates uses to lead the programming.

The illegibility of one programs,it occurs because during the execution it alternated the development base.
I doubt that somebody, in the stage of beginner for intermediary it has not perceived, that its results, for one space of time had started to be confused...
Also, the ones that had reached level advanced, that they dominate the two bases and they alternate, but they had not made this distinction.

It only exists 02 (Two) bases of knowledge, necessary to program, although both to be necessary,one of them evidences. It wants tests? It tries, to interpret programs extracted of PLCs...

 

[DesertDog]

There are many different styles and rite or wrong boils down to suitability for the needed tasks, functionality and serviceability. That said, I have once worked with an individual that did write incredibly long, hard to follow code for simple tasks and found it unbearable.

 

[Rube]

Caution, Caution-----OLD POST ALERT.

 

[Control Freak]

All I can add is...Keep it Simple.

Every PLC I have worked with has the ability to use subroutines. I use them religiously. If the machine I'm building has a dozen functions, then it's likely that I'm going to use a dozen sub-routines plus another for safety stuff, cycle logic, and another to call up the various routines. Some special process...boom, another subroutine.
This way, I can break all my code down into small, manageable sections. I put all the control logic and fault logic into it.
Actually, a "Dereeler" subroutine may only have 2 or 3 rungs in it, but I don't care...It's all there for easy finding later.
It really helps in starting up a new machine, debugging it, or going into it later for revisions. And if I need to, I can ingore the whole routine. Maybe I dont want to enable the dereeler... force it off.
Right way? I don't know.
Best way? Couldn't tell you.
But I do know that anyone that has the aptitude to get into the software and open the program will see a list of subroutines and the code for each process/station/inspection/etc inside.
From there it's all bits and words inside. I've seen a bunch of different styles:
Some very complex, having me dig out manuals or beating on the "F1" key.
Some tedious in simplicity, sending me flipping through bit reference after bit reference, for something that could have easily been done much simpler, and without skipping me across 8 pages of poorly documented code.

In my situation, having to program a variety of different PLC types, and never being the end user of any of them, I tend to get by with a handful of instructions that any programmer should know. (Move, Compare, EQ/GEQ/LEQ, One-Shots, Shift-Registers, Set/Reset, Latch/Unlatch, Keep). I repeat what I can, when I can.
And of course, an over-abundance of rung comments and discriptions never hurts.