Programming Style

[PPjack 0]

Looking for documentation concerning best way to program plcs. The head electrical, at my company, has dictated we are to write all programs as one ladder routine. We are not to use any sub-routines or jumps, as he has had difficulity with previous programmers' routines not working and it is easier for him to troubleshoot one routine than a program that contains sub-routines. I have argued against this policy as, for the most part, our controls do not change from one job to another, and writing sub-routines for similiar tasks would be much easier and faster. This way the repetative functions need only be written once and then copied to the current project. Another reason he does not like sub-routines is that when he searches for a variable, the software will only search in the sub-routine currently open, however, I have tried several programming softwares, (VersaPro, RSLogic, Siemens) and have not experience this. If the variable is declared as global not local, then the software will find all instances. When I question as to which software this is, I am told it is Concept. I have the latest version of Concept and still have not experienced this. So, I am looking for documentation that I can present to the VP of engineering to try and reverse this policy, as I have decided to ignore this doctrine and program with sub-routines. Also, I am trying to get the company to use 24VDC controls and eliminate 120VAC controls, but that is another subject. Any help will be most appreciated. Edited 11 Feb 2006 by PPjack

[gravitar 3]

It has always been my understanding that structured programming is preferable to unstructured programming. Even back in grade school, when the curriculum changed from BASIC programming to Pascal, it was shown to us that the code is easier to follow, more efficient, and more self-documenting when you divide it up into functional blocks or subroutines. You should be able to pick up any textbook on computer programming (not strictly PLC ladder logic.. This is true of any programming) and in one of the first few chapters it should demonstrate for you why one great big block of code is less desirable than something that's reasonably divided. Now with that said, let me suggest to you that you should think this over and pick your battles. The guy that you're defying is your boss, no? What is his personality like? Are you just going to piss him off and turn him against you, or is he open-minded and you think you can reasonably appeal to him with logic and reason? You mention going to the VP of engineering.. I take it this is your boss's boss? Be CAREFUL with that.. It is risky to your job when you break the chain of command. A VP is likely not to care one way or another, and he might just tell you to do what your boss says because it is easier for him than to get in the middle of the argument. And then when YOUR boss finds out you went over his head, he's probably not going to go out of his way to make life easy for you! At my last job, I ran into the same thing. There were two plants, one of them I did all the programming in, the other one was another guy's baby. At first he was just a contractor, but then they hired him in. He had MANY, MANY years of experience, and I regarded him as a good guy and a skilled programmer. In HIS plant there were only a handful of PLCs, but each one controlled a big assembly line. Each one got bigger and bigger to the point where only a 64K 5/04 would hold the program. Since each assembly line consisted of 20-30 distinct operations, it would seem to make sense to have each one in a separate subroutine, and save files 2-3 or whatever for the conveyor logic and what not. But this guy did just what you talked about, he wrote the whole thing, ALL 2000+ RUNGS OF CODE, as one big ladder. I asked him about it and he said that one ladder executes faster and uses less memory than multiple subroutines. He said that back in his PLC-3 days he had to do 'em all that way to save scan time and memory. He did have one clever trick to cope with this though, He put a "divider" between each section of code consisting of a rung with only one instruction, an OTE to a B3/xxx bit, where xxx is a multiple of 20. This actually wasn't a bad idea because if you wanted to find the code for a particular station, you'd just search for that station * 20, and it would take you to the top of that section. All the bits needed for that section were between (station * 20) and ((station + 1) * 20). Now, was he right in his reasoning for doing it this way? Strictly speaking, he was I suppose. It must take SOME amount of time and SOME amount of memory to JSR to a subroutine. But was it worth the lack of structure in the program? Personally I don't think so. I don't think the impact would have been felt in just dividing the dang thing up. So what did I do about it? I could have gone to our manager and demanded that this guy conform to what I think are PLC programming's best practices. But I didn't. Whenever I was doing something in HIS plant, I made it conform to his way of doing things, to the best of my ability. I was up there for many months, and many times wanted to do it MY way.. But I didn't. For one thing, the engineering manager and this guy went way back. He could have claimed the sun rises at night and our manager would have done his best to agree with him. It wasn't a fight I could win, so I didn't take it on. Besides, this guy was MUCH older than me, clearly had MANY more years experience than me, and overall was a nice guy. It wasn't a safety concern, so why would I fight with him over it?

[GerryM 2]

gravitar, it sounds like your guy used some sort of home made structured programming. He just didn't use the file mechanism AB offers. PPjack, your boss is an idiot. It sounds like he doesn't know what he is doing and probably should be the boss if that's all that he is good at. You don't make policy based on one occurrence, or in this case his lack of understanding. Present to him, not your boss's boss, your rebuttle, showing his lack of understanding in a polite politically correct way. He should see the light. If he still doesn't get it, its OK to push it a little. If you still don't get anywhere improvise with what gravitar's buddy does. Going to your boss's boss even at that point probably won't get you anywhere, unless you can somehow bring it up casually over lunch or something.

[Camel 1]

Take a look at the difference between functional and object oriented programming. This is what gravitar means (I think). Ladder is a functional language because it executes in a strictly defined order, top to bottom left to right. Function block diagram is an example of an object oriented language, although there is an execution order in concept, the program does not execute in a specific order. This is why I say it is "almost" pure OO. You mentioned concept, which was schnieder's first crack at creating a pure OO (object oriented) programming environment. After Concept they created Unity, which is almost pure OO.

[rajsiyer 7]

Hi All here.. Take it from one more guy.... that he who still resorts to unstructured programming, in all but the most trivial or small sized programs is well and truly dated. Increasingly, say as exemplified by Simatic manager of Siemens, or the Unity/Concept of Schneider; the goal of PLC companies is to provide Object Oriented tools to the modern day programmer/engineer. The purpose is to create a software OBJECT that would resemble the behaviour of the REAL OBJECT. Which is why you have functions, function blocks, data blocks, instances of functions etc. etc.. .This makes the design of large sized systems easier. Present design approaches are all top down. The larger picture is broken down into the functional/logical elements, as object components of the real system. There is no other way. Whatever models we create in software(ladder programming) has to replicate the behaviour of the real machine/system under control of the PLC. Likewise, Your little plc program has to provide STANDARDISED INTERFACES for other programs/objects that interact with it. Again a powerful argument for structure. As the world becomes more and more digital,PLCs are increasingly resembling computers rather than the switches they once used to be. So whether or not your boss is convinced by this argument is immaterial. It is a career imperative for you to be reasonably aware of not only structured programming but also such things as UML or the Unified Modelling language. I could go on at length over this topic but 've to end it here for now. With best wishes for your success.. Raj S. Iyer.

[TConnolly 13]

It sounds to me like the head electricain needs some training more than he needs anything else. Its time for him to join the 21st century.

[IO_Rack 181]

I work for a medical company that does extensive documentation on just about everything. A long time ago we breifly disscussed a format for programming PLC's. We rejected this proposal as it would take most programmers out of thier realm. I don't mean to make it seem like such an art (or maybe it is! different debate). What I mean is, things that make a programmer good would be lost if he/she is forced to comply to a procedure. Everyone has experienced bugs in thier programming and has adapted and learned from it. Ultimately the programming results to a process. We have developed extensive testing for our processes rather than dictate how it should be programmed. Everyone knows you can program the same thing several different ways. I suggest to your boss that he focus more on the output or the process instead of how it is programmed.

[panic mode 246]

I had customer who wanted me to do the same on a not too big but rather complicated project. Program was about 30k steps and they wanted it all in one ladder file so they wouldn't have to wait for HMI to load logic when using ladder monitor. I refused and said I will finish the project, we will get paid and then they can play with it all they want, but if they call me because of any problem and I see changes, they will loose waranty. Works mirracles every time but I'm not sure it would help in your case... It might be time to gently suggest some training for the head guy... After all good troubleshooting skill is always wellcome.

[Beuwolf_1 0]

I'm a firm believer in subroutines, and most of the people replying in here are also of the opinion that subroutines are the way to go. I also certainly believe in DC control systems over AC just for safety concerns. Maybe one way to show your boss how the world in general sees things would be to have a poll in here on how many prefer using subroutines vs one big messy, nasty, never ending pile of program printed out to work on. Who knows, majority rule may work in your case. Good luck

[gravitar 3]

Well it seems that everyone agrees that subroutines are good (myself included) and everyone BUT me thinks that the original poster should just defy the boss and program as he sees fit. Let's just hope his boss isn't like some I've had!

[benbrad 0]

In the UK there are laws against your current systems, this is European directives, not just one country one idea, many countries agreeing on a very safe practice. I have machines that have come from the US and employ such dangerous voltages on the controls, slowly I'm replacing them with safe 24v systems. I wish the US would take on similar rules to outlaw such foolish, no, bloody idiotic practices that still appear on new equipment today.What says everyone?

[dogleg43 1]

Programming with the "5-Rung Logic" works very well in many applications, especially with systems like assembly lines, lift and transfer applications, etc. The basic premise is to use the same style of programming for every station. "5 rung" refers to the number of rungs in the "motion block". 1-Safety 2-Precondition 3-Command 4-Output 5-Motion complete Depending on your application, it may become only 3-4 rung logic. See link below: http://www.eng-tips.com/viewthread.cfm?qid=87845&page=8

[GerryM 2]

24VDC is alot better. My company recently announced that new push buttons should all be 24VDC, instead of anything higher. Its a step in the right direction. Now we have to work on those 120VAC solenoids and contactors. Edited 15 Feb 2006 by GerryM

[panic mode 246]

gravitar made interesting comment. if the boss is someone difficult it is very hard to compromise. i guess even if that is the case, a bit of diplomacy wouldn't hurt. i would ask him for all such rules and if they are not listed, i would make list with pro and contra and ask to sit down and discuss it. i'm sure all of us have preference that can be seen as set of rules because we stick to certain way of programming for one reason or another. if you find out what is he worried about, it will be easier to work around it. i don't like to use certain instructions, not because i don't know how they work but because somebody else will not know or because this instruction is not standard on all plcs etc. one simple instruction that i tend to avoid is TOF in AB for example, simply because I had to get out of my bed in the middle of night and drive to a remote location because someone trying to make change in the program didn't understand it. you know scenario when phone rings, baby wakes and wife gets mad (and stays mad for a week...). i explained situation to our guys and asked them to avoid certain things (didn't tell them they MUST follow "my" rules, just told them if this happens again, they are called too). we had a brief meeting and together came up with some guidelines so we can aviod or minimize scenarios like that...

[robh 12]

Is he the only other person besides you that has to troubleshoot the programs? If not, I would gather up all the maintenance peoples and techs opinions to bring to the table and show him that it may not be the best way to program, because it is harder for everyone else to work with and less efficent. It is a hard thing to argue about when it could take a tech hours (hours = $$$) to sort through a large unstructured program. I have had this problem before aswell. I had a supervisor that was afraid of PLCs because he didn't understand how they worked. Any time there was a problem, the "magic box" had to be the problem. He also wanted everything I did documented to the key stroke, so he could do simple things like going on line with a MicroLogix 1000. But he was unwilling to take any classes to learn. He wanted me to do it for him. "Step 1-double click on the RSLinx icon on the desktop"

[Spanner 0]

In My Opinion, Programming Styles don't make as much of a difference as is thought. I've had to go through about 875 lines of ladder logic that controlls 4 positioners. The Part I hated was Someone had deleted the comments and all the Coils/relays had their X/Y/M### Labels on them. If the code is Commented correctly and adequately such that you know what's going on and the Tag Labels have a Nomenclature you can follow and Make sense as to what it does, the whole process becomes Much (Much) more managable regardless of Programming style. I've seen some code where someone used a subroutine for the sake of it (only used once, no repeatability and Poor comments) and it made it Very Difficult to jump between subroutines and standard code to troubleshoot. that Said, I'm a Big Fan of Well structured object orientated programming as well when you can get a better picture of what's going on by trawling through the code. One thing though I dispise is Commented out code however. Especialy when it's not partivularly colour coded and still shows up in Cross references.

[TERdON 9]

I never use subroutines, but I do use segments to part different functionality from each other (I'm in the Omron world). Even though there are some repeated tasks, they are different enough that they warrant one customized segment each. It would be a good idea to try to generalize (ie subroutines? FBs?), if it wasn't for the fact that I'm right now trying to separate the reusable parts into separate PLCs... :) I would say - try to use as much functionality to split the code into smaller pieces as possible, but do not let it go overhand - you shouldn't really split a piece of code that handles only "one" real world functionality, or code that's already just one or a few pages. Edited 16 Feb 2006 by TERdON

[panic mode 246]

...and one can always forward this story to his boss: The article is by Alexander Calandra and appeared first in "The Saturday Review" (December 21, 1968, p 60). It is also in the collection "More Random Walks in Science" by R.L.Weber, The Institute of Physics, 1982. Calandra was born in 1911, started at Washington University (St. Louis) in 1950 as Associate Prof. of Physics. B.S. from Brooklin College and Ph.D. in statistics from New York Univ. Consultant, tv teacher and has been AIP regional counselor for Missouri.

[OkiePC 14]

Wow. That is an outstanding story. Can I link to it? I won't copy and paste other peoples contributions, but a link for a few friends would be cool. SUBROUTINES: Very useful, both as program dividers and true functions. I have only passed parameters once, but have used conditional subroutines in every program I have written. How else can you effectively use objects with top down design? Subroutines, even conditional ones when well implemented, not only make the code more efficient, but more readable. ie. XIC First_Pass JSR Power_Up Everyone can understand it. All powerup functions are submerged in a routine, so you don't have to skip over 100 rungs to get past it. If you want to change what happens at power up, you know EXACTLY where to look. To say you never use subroutines I hope you aren't saying you never would. You are missing out on an excellent tool for efficiency for you and your machines. Not to mention potential mistakes are averted. If you have the same logic over and over with an incorrect address in one of them that affects the performance of another, how long i$ it going to take to fix? Not an issue with subroutines. Write the logic once, use it forever after. PEaCe Edited 3 Mar 2006 by OkiePC

[TimWilborne 108]

Thats a great story! When you look back through history, most innovative people did not conform to conventional thinking. And unfortunately many of there contributions were not realized until after their death.