I had said...
"My philosophy is... make ALL of your code every bit as complicated, BUT... Only As Complicated... as it really needs to be to produce the most efficient results!
After all, isn't that the real name-of-the-game? Efficiency?
Otherwise... what the hell are we being paid for??? Perhaps for nothing more than providing a fine hat-rack???
Of course, complicating the code just for the sake of complicating the code is ridiculous... and counter-productive."
I'm not speaking of efficiency in the processor... processor speed or processor memory... rather, I'm speaking of the efficiency expected by the employer that is paying you to provide that efficiency!
By all means, gobble-up any processor memory that you might need! Memory is cheap!
Regarding processor time... gobble-up all of the processor time you want, anyway you want... as long as you don't affect the over-all efficiency of the process!
Ahhh... but then... we might only be arguing the difference between oranges that are "navel" and oranges that are "non-navel"... in either case, not much difference from a user's point of view.
Now, regarding the primary statement...
"...make ALL of your code every bit as complicated, BUT... Only As Complicated... as it really needs to be to produce the most efficient results!"
Can you point out exactly what part of that you are having trouble understanding?
In the original post I clearly insinuated that this is supposed to be from the employers point of view; efficiency is everything. And I also explicitely stated that complication for the sake of complication is ridiculous.
What more do you need in this respect?
How about a little bit of classical "Critical Thinking" as you are reading?
At the very least, consider the concept in the message.
Now... regarding Naming Conventions... I had said...
"Maintaining a "naming convention" across any number of systems, just for the sake of maintaining a "naming convention"... might be ludicrous.
If you happen to have the same type of controller in all of your systems, with the same type of software in all of those systems, then you can get away with it... IF your convention is reasonable... that is... RATIONAL!
However, not all controllers, and not all controller softwares, are created the same.
The reason I raise this point is because, all too often, I've seen "names" that were NON-PROCESS-SPECIFIC! They simply followed the... convention, as it were. Did the names really indicate the true meaning? More often than not... no. Because they were NOT Process-Oriented... they were Convention-Oriented."
The point is... many controllers simply can not handle the same naming convention as some others might be able to handle.
If you are unfortunate enough to only have to deal with one controller-type in all of your applications... then yes... as I said, you can get away with that across all of your systems.
Another point... any canned module, from any vendor, is NOT designed specifically for YOUR particular process... how can it be so? It's simply generic.
(Ron should appreciate this...) Imagine... someone comes in from the cold... unfamiliar with the process... he sees a Name... apparently listed by some convention. For him, the convention is meaningless... it makes little sense, if any, in terms of the particular process. He quotes the "Conventional Name" to the operators... the operators look like deers staring into oncoming headlights...
Why is this a problem? Because the "Conventional Name" came from a Standard, of some kind, that has absolutely NO IDEA what you guys are making at that particular plant!
I guess maybe I'm simply addressing the conflict between "cryptic conventional namining" versus explicit "process naming".
Only fools argue over "buzz-word" positions... unless the "buzz-word" is used to explicitely make a particular, uninformed, irrational, point.
By the way... instead of worrying about "ain't"... how about paying attention to the "content", the "concept", of the message?
Ron...
"How do you keep 'em down on the farm... after they've seen Gay Paree?"
Keeping a program simple at the expensive of productivity is simply not acceptable... at least, not for those of us that have "seen Gay Paree!"
OMG... Ron! If your employers were reading this, how do you think that they would feel if they found out that you were sacrificing process efficiency for the sake of keeping the program simple enough for the... program maintainers???
If I was the employer, I would wonder... who is controlling this process? And why isn't he keeping the process running at maximum efficiency? After all, that is what PLCs AND PLC PROGRAMMERS are supposed to provide!
And then, I would wonder... why are my Electricians not up to speed?
The name of the game is Process Efficiency!
Do you get it yet, Ron?
That is all I've been talking about over these last several years. That's all I've been talking about when I said...
"...Only As Complicated... as it really needs to be to produce the most efficient results!"
You better hope your employer ain't listening to this.
By the way Ron, at your place of work, who is primarily responsible for the content of the program?
