Good programming practice

[cjh]

The point is... the least capable program-maintainer always wants the programmer to Keep It Stupid... (for) Simple.

How nice, the world you live in...

You get to program however you want and everyone else must follow you...

Unfortunately, most of us live in a different world to where we HAVE to program in a manner more condusive to an environment where the maintainers have many different responsibilities and don't have the luxury of working with ladder logic every day.

 

[rsdoran]

Terry, I think I understand...

How nice, the world you live in...

You get to program however you want and everyone else must follow you...

Unfortunately, most of us live in a different world to where we HAVE to program in a manner more condusive to an environment where the maintainers have many different responsibilities and don't have the luxury of working with ladder logic every day.

I have been debating this with Terry for 4 or 5 years now because I thought the same way y'all are. I think I understand, now, what Terry has been saying all along.

A plc may offer a variety of ways for programming but you should not base your program simply because someone may not be capable of understanding it.

The programmer should be able to use any instructions required that will provide the best efficiency and use of the PLC. If there are people that may have issues with the program then the programmer may have to provide more information to assist those people, at the same time though, those people must "work" to learn more because it is relevant to their job duties.

In other words there should be no limitations involved, everyone has to work hard to remove any limitations there may be.

 

[kamenges]

I agree with Ron on this. That's what I took away from Terry's comments, too. Terry's writing style (some might say 'combat style' ) can sometimes obscure the salient point in his post.

I do conceptually agree with Terry on this. However, sometimes reality gets in the way. I tihnk Terry is in some ways an ideal example of his point. He is an intelligent, detail oriented perfectionist (all meant in a good way) who has a long-term relationship with the process he is involved with. I can't remember the exact topic but I once saw a post by Terry that said he has been working on one of his processes for 8 years. I would suspect by this time Terry has that process telling you what is wrong well before it actually goes wrong in very operator-oriented terms.

I am on the other side of the coin. I am with a custom equipment OEM. We design build everything from the ground up per customer requirements. Sure, we try to reuse as meuch as we can. But quite often there isn't much we can reuse. If I'm lucky I will have 8 weeks to conceptualize, develop, code and test a control system. Then it's gone.

As a company we are not set up to provide extended field service. The engineering department performs the service work. When we are providing support we are not designing the new stuff coming behind.

All too often due to time constraints I am forced to choose between making a machine that will function correctly and reliably or making a machine that will provide detailed diagnostic information. Most often the diagnostics lose that fight. So I need to produce a program that is easy to read and understand for anyone who may need to look into it for clues to an error. If this means avoiding some of the more complicated concepts and constructs so be it.

Keep in mind that any program you develop no matter how it is devoloped is compiled down to a handful of processor resident instructions. To say that something can't be done using only 'simple' instructions and concepts seems to ignore this.

Keith

 

[rsdoran]

It only took me 4 or 5 years to get what Terry has been saying. I agree there may be differences between in-house and an OEM but Terry was stating that too:

Bear this in mind... always...

Production interests come first...
Then Operators...
Then Maintenance Folks...

At the very end of that line is ease for the programmer.

The first concern, in any situation, would be to make the machine run efficiently and reliably; hopefully with ease of use for the operators.

There are always "what ifs" or "it depends" but if everything is done "efficiently" and properly the need for maintenance to go into the program could be minimal or unnecessary.

Another aspect of this is the fact that "ladder" is not the only language used. A maintenance man or electrician, in the US, may be able to understand ladder but not have a clue about STL etc.

I always thought it was unfair that maintenance men were required to learn more and more but it is the wave of the future. Automation technology is changing and developing more each day and developers or programmers must be allowed to use all the tools available; therefore those involved must work harder to learn more.

Keep in mind that any program you develop no matter how it is devoloped is compiled down to a handful of processor resident instructions. To say that something can't be done using only 'simple' instructions and concepts seems to ignore this.

I am not sure about this aspect, many plc offer special instructions that I am not sure you could roll your own. You may be correct for now but in the future I expect more and more "special" instructions to be incorporated.

What it all boils down to is that you should not arbitrarily be limited because of certain people's limitations, what must be done is provide the means for those people to bring up their level of knowledge to match what must be done.

I am going to use myself as an example. I consider myself a fairly knowledgeable maintenance tech. I have even programmed numerous plcs and used plc software to troubleshoot numerous times. With that said their are many topics discussed here that I just do not understand, the simple fact is there will always be something I do not understand; which means there will always be aspects that many maintenance men will not comprehend, regardless of what you do. Instead of limiting yourself then their must be a method to provide the information to teach others what is being done; in other words remove their limitations if possible.

This may not be an appropriate example but I will use it anyway. Car manufacturers have always looked to improve their cars to make it better for the owners. There are millions of cars with few owners having a clue to how they actually work. At the same time there are numerous "mechanics", do they all know how to work on ANY CAR...NO. Are car makers concerned because of this...NO. They did what they had to do to provide an efficient and reliable machine. It was up to the mechanics to learn the new technology.

I reckon I ain't on the farm no more.

 

[geniusintraining]

I agree with you both and Terry (ah $hit did I say that out loud?)...but the fact still remains that in "our" world our technology changes so much (even if the concept stays the same), you can not expect every maintenance tech to know it all...so you have to try (agreed you can't always) and make life easier (simple)... also I am the in-house go to person (not a OEM), so it would be to my best interest to keep it as simple as I can

"With that said their are many topics discussed here that I just do not understand, the simple fact is there will always be something I do not understand"

By the time I figure out what Peter Nachtwey is talking about in his articles then it will be old technology...


I know by personal experience that some of this stuff we do can be hard to grasp, I even see some of you guys struggle with it as well, so besides trying to teach someone else (that being the best thing) the next best is trying as hard as I can and going out of my way to make the code 'simple to understand'.

 

[rsdoran]

I know by personal experience that some of this stuff we do can be hard to grasp, I even see some of you guys struggle with it as well, so besides trying to teach someone else (that being the best thing) the next best is trying as hard as I can and going out of my way to make the code 'simple to understand'.

You just stated what Terry has all along. It has nothing to do with what instructions you use, use what is needed to make the process work the best, but provide the means to make it simple to understand...i.e. simplicate, be as complicated as necessary but make it, or provide the means for it, to be simple to understand.

Concepts do not change, how a concept is implemented changes all the time because the technologies involved is constantly changing.

Technically I think many of the programmers are already doing what Terry is saying but reading more into his replies than what is being said. I know I am guilty of that.

It has taken me 4-5 years to understand this simple thing just because of my contrary nature.

I am going to leave the rest to Terry.

 

[BobB]

I am on the other side of the coin. I am with a custom equipment OEM. We design build everything from the ground up per customer requirements. Sure, we try to reuse as meuch as we can. But quite often there isn't much we can reuse. If I'm lucky I will have 8 weeks to conceptualize, develop, code and test a control system. Then it's gone.

Boy, you are lucky to get that long sometimes. A typical contractor situation is do the job quickly and efficiently, get paid and it is gone. Already on to the next 2 or 3 halfway through the first one.

I tend to use whatever makes my life easy as far as writing code and commissioning. However, mostly ladder is specified typically on jobs. I therefore look for the best ladder editor and instruction set so that I can get the job done and get out of there.

All too often due to time constraints I am forced to choose between making a machine that will function correctly and reliably or making a machine that will provide detailed diagnostic information. Most often the diagnostics lose that fight. So I need to produce a program that is easy to read and understand for anyone who may need to look into it for clues to an error. If this means avoiding some of the more complicated concepts and constructs so be it.

Agreed. That sometimes means that one cannot use the tools at ones disposal. I often have a client on the phone in a remote part of Australia and I have to guide them through software as part of a trouble shooting excercise. Has to be simple to do that usually.

I am not sure about this aspect, many plc offer special instructions that I am not sure you could roll your own. You may be correct for now but in the future I expect more and more "special" instructions to be incorporated.

Yes, but at the end of the day the PLC only works with machine code anyway. The rest of the functions etc are just programming tools.

This may not be an appropriate example but I will use it anyway. Car manufacturers have always looked to improve their cars to make it better for the owners. There are millions of cars with few owners having a clue to how they actually work. At the same time there are numerous "mechanics", do they all know how to work on ANY CAR...NO. Are car makers concerned because of this...NO. They did what they had to do to provide an efficient and reliable machine. It was up to the mechanics to learn the new technology.

It would be nice if they put more robust computers in the damn things!

 

[jstolaruk]

I agree with Ron on this. That's what I took away from Terry's comments, too. Terry's writing style (some might say 'combat style' ) can sometimes obscure the salient point in his post.

I do conceptually agree with Terry on this. However, sometimes reality gets in the way. I tihnk Terry is in some ways an ideal example of his point. He is an intelligent, detail oriented perfectionist (all meant in a good way) who has a long-term relationship with the process he is involved with. I can't remember the exact topic but I once saw a post by Terry that said he has been working on one of his processes for 8 years. I would suspect by this time Terry has that process telling you what is wrong well before it actually goes wrong in very operator-oriented terms.

I am on the other side of the coin. I am with a custom equipment OEM. We design build everything from the ground up per customer requirements. Sure, we try to reuse as meuch as we can. But quite often there isn't much we can reuse. If I'm lucky I will have 8 weeks to conceptualize, develop, code and test a control system. Then it's gone.

As a company we are not set up to provide extended field service. The engineering department performs the service work. When we are providing support we are not designing the new stuff coming behind.

All too often due to time constraints I am forced to choose between making a machine that will function correctly and reliably or making a machine that will provide detailed diagnostic information. Most often the diagnostics lose that fight. So I need to produce a program that is easy to read and understand for anyone who may need to look into it for clues to an error. If this means avoiding some of the more complicated concepts and constructs so be it.

Keep in mind that any program you develop no matter how it is devoloped is compiled down to a handful of processor resident instructions. To say that something can't be done using only 'simple' instructions and concepts seems to ignore this.

Keith

As a fellow OEMer, I agree. We do the best job we can in the limited time alotted and hopefully one of the customer's maintence people will take ownership after its delivered. The customer and his maintenace people are the folks I strive to make sucessfull.

Oops, look, the shop just finished assembling the next one-off machine to get out the door ASAP. Oh, and BTW, its already late.

 

[Peter Nachtwey]

I saw that.

By the time I figure out what Peter Nachtwey is talking about in his articles then it will be old technology...

I can answer questions but you should start a new thread. I bet there are others that would like the same answers.

 

[Terry Woods]

Does this mean that I can come back in from the woodshed?

If so... Thank You, All!

cjh said...
"Unfortunately, most of us live in a different world to where we HAVE to program in a manner more condusive to an environment where the maintainers have many different responsibilities and don't have the luxury of working with ladder logic every day."

cjh...
All of my comments come from the point of view of a "Process Owner". I am in control of my process.

I have the responsibilty of making the process all it can be for the sake of meeting management's requirements.

I have the responsibilty to make the process as easy as possible for production folks to use... without sacrificing management's requirements!

I have the responsibility to make it as easy as possible for the night-guy to understand the code... without sacrificing either of my two previous responsibilities!

If I faithfully execute those responsibilities... then I do not become the "go to guy" at 2 o'clock in the morning!

This means, ultimately, I, the PROGRAMMER, have to put in the effort to make it so! DUH??? Are you the programmer?

Keith said...
"Keep in mind that any program you develop no matter how it is devoloped is compiled down to a handful of processor resident instructions. To say that something can't be done using only 'simple' instructions and concepts seems to ignore this."

Keith...
I appreciate your Custom Machine, OEM status... been there, done it, got the scars, got the t-shirts and I got the g-damned hats.

But... over my time in that business, I found that it was greatly beneficial, for all concerned, to incorporate on-line, real-time, diagnostics on an equal footing with the process. It only served to generate repeat business. Especially in those places, and there were many, where there were no capable maintenance folks.

Git said...
"...so besides trying to teach someone else (that being the best thing) the next best is trying as hard as I can and going out of my way to make the code 'simple to understand'."

Git...
My point is... the more effort you put in to creating code that TELLS the operator what is wrong... the less need there is for anyone to even look at the code!

Now, the operator might, or might not, be able to see what he sees... but, if you design it for the operator... surely the maintenance guy can see it without going into the code.

And of course, the maintenance guy needs to be aware of the symptom/cause relationship. I regularly distribute a little thing I call a "Tech Flash". It informs the techs of the symptoms and then describes all of the possible causes.

If you really understand your process, you can clearly identify ALL of the possible causes... in order of likelihood.

Ron...

All I can say to you Ron is... Damn it! One of these days... I'm gonna have to sit down with you and burn a couple of cases of MGD! (You can partake in the MGD, or not, as you wish... I'll buy in either case!)

By the way... I'll be in Chicago at the end of November.

 

[geniusintraining]

Git...
My point is... the more effort you put in to creating code that TELLS the operator what is wrong... the less need there is for anyone to even look at the code!

Then why dont you say, just that...

Terry the thing that got my goat, was the blatant disregard to the simple fact the KISS concept is a viable rule that anyone should consider, by your own statement "I absolutely HATE the concept of KISS..." those are very strong/harsh words in my opinion.

I don’t think and never will think, that you can generalize a statement like that and not get any ramification (AKA $hit) from it (not that when I speak it means anything) but I’m not just going to sit there.

Terry I like you and enjoy conversing with you, for many reasons one being I can and will have a very good argument, another reason I have learned something from just about every post you have made, but I can’t stand by without speaking my mind when I feel you are ‘bashing’ a viable concept

jtn was the first OEM that chimed in I think (speaking of the KISS concept), But jtn, kamenges, Bob and jstolaruk and all OEM’s are in a different league for several reasons

1.The majority of you know programming in and out, so simple to you may be hard for me, so you need to keep that in mind while you are programming… and for the most part I think you do, mark_hommer a member here has wrote a CLX program for my company, I have used that example here on this site as being one of the best programs I have worked with. Was it simple? You will need to ask him, but for me it was easy to understand, I think he had to take some consideration of the fact he was not going to maintain it someone else was.

2.You make your money by being good at your jobs by writing programs that would take me weeks, it would take you hours, so you are graded on several different things one being on your time spent, making that program. You need to be fast or at least faster then I...

So we get back to bubba’s like me…when I make a program or edit one, I have to consider the other guy, I can complicate things in a hurry by my nature…example using a counter in a flip flop circuit, why would you do that you ask? Because I did not know any better, it worked, but was it the simplest way that someone else could understand? NO, so after reading several examples of a better ways (one I might add was Terry’s)…now I keep it simple, you can't just"...HATE the concept of KISS..."that does not work for me


Peter Nachtwey,
Will do, it will be from your machine design article

 

[rsdoran]

I was going to leave it to Terry but I had a few more thoughts.

First please define:

Simple; as it applies to plcs and automation
Complicated; as it applies to plcs and automation.

Either term can have different meanings for any individual.

A counter as a flip-flop is not complicated to understand, at least it should not be. A counters application is to provide an action based on count, anyone should grasp that.

An example of simple, in relationship, to dumbing down code is when a machine capable of producing 20 widgets a minute only produces 5 because someone thought that it was too hard for others to understand the code involved.

I think Terry is applying the term "KISS" to equate with that kind of situation or similar, any situation where the concern is more toward people reading the code then what the code actually does.

Terry and Peter both love to stir the pot because it makes people think. I can not believe it took me so long to understand.

There is no way anyone will ever write a program that is so simple that ANYONE can understand it AND doing so may mean creating code that is not efficient.

Technically the terms "simple" and "complicated" do not apply, you do and use what you must to make the machine operate efficiently. IF/When a situation occurs that maintenance etc may need to look at the code then that person(s) should be able to understand any instructions used, otherwise they have no business in the code.

 

[geniusintraining]

There is no way anyone will ever write a program that is so simple that ANYONE can understand it AND doing so may mean creating code that is not efficient.

agreed but with reservation, buy documentation and letting the other person see what you are 'thinking' you can limit the confusion...

that was a bad example, that was just bad programming practices, hard to understand for me?, would be

This is well documented but the 'AND' bitwise etc, ladder 31 rung??31ish thats where it gets hard for me...Ron it may be easy for you but to me...its anything but simple and I'm not stupid.

 

[alessio]

Anybody has an experience with UML?
That's mean: To generate STL code from UML. Is it possible?

 

[jstolaruk]

Anybody has an experience with UML?
That's mean: To generate STL code from UML. Is it possible?

I've only seen it used (once or twice) for large computer programming projects that had several to many programmers involved. I think thats where the strengths are; communicating between members of the team. The two projects were storage banks for car bodies betwen paint and assembly and they didn't use PLCs.