I have always been a proponent of the idea of using every tool at your disposal to accomplish those controls necessary to maximize the performance of any system. Just as a machinist or carpenter needs to be careful with the tools he uses, so too the PLC programmer must be careful with his tools!
Speaking of carpenters, (in general) there are three types of carpenters:
- Rough Carpenter (Framer)
- Finish Carpenter
- Cabinet Maker
Each has their own set of tools. Assuming that the talents of each is restricted to their particular craft, you shouldn't ask one to perform anothers' specialty. You know what you get when you as a ask a Framer to build a Coffee Table (remember 4x4 furniture? Quaint!).
The analogy that I'm trying to present is not about the people, but rather, their tools and the particular talents required to use those tools.
Each set of tools and talents needs to be brought to bear in their turn. The task is not done until the Cabinet Makers' tools are brought to bear.
The Rough Carpenter can work with tolerances of +/-1/8".
The Finish Carpenter can work with tolerances of +/- 1/16".
The Cabinet Maker works with tolerances of +/- 1/32" or even 1/64".
If you consider the job done after the Rough Carpenter is done, then you should expect results no better than a Rough Carpenter (stress on the "Rough") can provide.
Likewise for the Finish Carpenter.
It is only after the Cabinet Makers' tools are brought to bear that the job is really done! (Of course, this assumes that these guys are good at their jobs.)
Bottom Line?
Use all of the Tools and Talents you can get your hands on to produce the best product you can!
Now, back to the subject at hand...
Comments are certainly required for those that get into the program.
It is very easy to make comments for programs that are reasonably organized (modularized, or at least, for smaller systems, properly ordered).
If you write spaghetti-code, you deserve all of the grief that comes your way. Of course, the backlash of spaghetti-code, even if you understand it, is that no one else will understand it! Even if it is commented!
Good Code almost comment's itself! (But don't let that stop you from actually entering the comments!)
The whole battle about how simple to keep code is generated because there are, in general, three different perspectives when it comes to programming and maintaining PLC's.
The three perspectives are...
- OEM (Original Equipment Manufacturers)
- Contract Programmers maintaining any number of different systems.
- In-House Programmers maintaining Local Systems
The OEM wishes to maintain code in as much of a cookie-cutter fashion as possible. This is entirely reasonable. Sometimes, however, the OEM has to build a one-off (one-of-a-kind). Again, the OEM tries to keep the code as close as possible to the House-Standard. This practice is primarily designed to make things easier for the OEM. From the OEM's perspective, it is simply more efficient to do. I can't complain about that too much... after all, the OEM is in the game to make money.
In many situations, users are NOT ALLOWED to get into the program; only the OEM is allowed. In this case, there is no need to consider the ability (or lack, thereof) of those users that would attempt to maintain the system program. Certainly, Peter does not dumb-down his code so that it is easy for
anyone to understand. He needs his code to be only as easy to understand as
he requires.
Generally, as time goes on, an end-user usually finds that the OEM code does not provide all of the bells and whistles that an end-user (operator or maintenance) might like to have. Of course, the OEM will have every right to say "Yeah, but we built it to Spec!"
It's almost always the case that end-users don't really know what they want until they come up against a situation where they say, "Gee, I wish it would..." do this or that. They simply didn't know they were going to need it when they provided the spec.
In this case, if the code is closed, the OEM is contracted to provide the necessary changes. And again, the OEM will build to spec - you should expect no more, no less - a contract is a contract! The OEM is under no obligation to make the code easy for the local maintenance folks to understand - the code is closed. The OEM will, and should, make the code according to their own in-house rules. And so it goes...
If the code is open, then you might get a hold of a "Contract Programmer". And again, the code will be fixed, changed, updated, whatever, according to the agreed spec (or, at least it should be).
The result depends on how good this programmer is. A decent programmer will build the code in a reasonable fashion. If the changes require the use of a For/Next function, then the programmer should use it and explain how it's being used.
On the other end of the spectrum, you have your In-House Programmers. We are on-site, day-in and day-out. We have to suffer, on a daily basis, the consequences of the code we write. Those in-house programmers that care about what they are doing to the production folk and maintenance folk take it to heart when they hear complaints about this or that aspect of the code.
We also have time to contemplate more effective ways to do this or that. Some of the systems we work on are forever in development. We are also on-hand to explain to the operators and the maintenance folks how this or that works. I usually write up a
"Technical Flash" explaining any new changes to the program and provide it to the operators and the maintenance folks.
I do not like phone calls at 2:00 AM and I do everything I can to prevent them from happening.
So, from my perspective...
K.I.S.S. ? ? ? ? Keep It Stupid, Simpleton ???
I say
BULL! I also say...
K.I.C.K.A.S.S. ! ! ! !
Keep
It as
Complicated and
Knowledgable
As necessary to
Support the
Stategy!
When I design code, I make it only
as complicated as it needs to be in order to accomplish the goal. I do not limit myself to using only those tools that everyone knows how to use.
If someone doesn't understand what's going on simply because the code is beyond their intellectual capacity to grasp (despite the comments, and I do make pretty good comments)... well... I can show them where the programming and math books are - then it's up to them. In terms of actual applications, I will not slow down for stragglers!
Anyone that is responsible for maintaining equipment and then, does not take the steps (intellectual steps) necessary to provide that maintenance should be replaced.
I go to great lengths to provide troubleshooting tools for the operators and/or maintenance guys. These are screens that are designed to indicate the status of all I/O for all system modules. Operators can call up a screen at any time, or, when a fault condition occurs, a screen pops up automatically.
One of the more helpful screens I have comes up when an operator tries to do something but the system won't allow it. If the operator pushes a particular button trying to perform a particular action, the screen pops up and indicates why the program will not let the action occur.
If a fault condition occurs, a screen pops up automatically, indicating the affected module and provides a "Go to Page #" for more details and possible solutions.
If operators and maintenance folk choose not to take advantage of the tools that are provided, what can you do?
At some point, after trying to make the program as idiot-proof as possible, you are faced with the need to get rid of the idiots!
This position can be taken only by those programmers that recognize that a programmers responsiblity is to use whatever coding is necessary to make the system as easy as possible for the users - not the programmer! Minimalist Programmers are the Bane of Operators and Maintenance folks!