Programmers who go off script

_Dock_ said:

Have you ever seen a Tesla spec, the go I great detail for their software spec and how they want it done.

Click to expand...

I have not seen Tesla software spec but I would like to see it. Do you have it?

Programmers don't have a monopoly on Prima Donnas. Many years ago the company I worked for frequently hired a free lance draftsman for spikes in the workload. He had years of experience with many different companies. While his drawings were correct, he held to his own standards, a mishmash of practices he'd picked up over the years. Consequently, there were always more questions from the shop regarding interpreting his drawings than from any other draftsman. The joke around the shop was that if he drew three projections of a bowling ball you'd have a hard time figuring out what it was.

Fourpaw said:

Just wanted to get some thoughts on dealing with co-workers who go off script.

We are a large manufacturing facility with multiple/ similar machines and most of the logic can be duplicated (standardized). My co-worker (equal) feels that each new task he is a assigned is an opportunity to reinvent the wheel so to speak, attempting to utilize rogue "logic-vomit" rather than what we have in place everywhere else.

One technique he is using lately (while vigorously talking to himself out loud) is to add a "_CS" at the end of EVERY single controller tag (RSLogix5000). So we now have 100s, sometimes 1000's of these "_CS" tags mixed in with controller tags that do not have "_CS" indicator at the end.

i.e.
Autn_CS
Autff_CS
Start_CS
Stop_CS
Red_Light_CS
Amber_Light_CS
Green_LIght_CS

The purpose - he wants to identify what tags are controller tags in the logic, without having to hover over the tag to see it's properties.

Other things:
- refuses to create an array in size that is anything less than 500.
- insists that there is an NEQ before EVERY single MOV instruction. i.e. if N7:0 does not equal N7:1, then move N7:0 into N7:1.
- HMI screens - lets go with the smallest font possible, and not organize or line anything up.

Seems crazy to me, unfortunately the managers here know absolutely nothing about programming, so I kinda have to live with it.

What would you do if your co-worker went off script and your boss(es) just didn't care?

Any other examples of logic-vomit like this that makes you lose sleep at night?

Click to expand...

It's been my experience that when people don't get along well, details large and small get on each others nerves.


If I was to guess, I'd say that he figured out what annoys you the most and made a point of doing things that way, even if he actually doesn't like it. He does not sound like he plays well with others


You can retaliate - doing things that you know annoy him .. until one of you leaves. Maybe you can convince the other programmers to do that with you. That's the open warfare approach. I'd guess that 'correcting' his code (removing the _CS, deleting the NEQs) would drive him insane.


Or you can do some HR type stuff and figure out how to 'nudge' him in the direction that you want him to go. AND (Important!) convince him that it was HIS idea.



You can likely guess which one of those two I have done in the past .. and which I've tried and failed at


Good luck ... keep us posted with what you tried and the results!

goghie said:

I have not seen Tesla software spec but I would like to see it. Do you have it?

Click to expand...

I don’t think that is something I should share.

It lays out all the tag structure, AOI’s, routine structure, etc. they even go as far to provide an hmi template with their standard layout on it.

dogleg43 said:

Nope, I stand by that statement. Seriously, MOST of them that I worked with rarely showed up at the designated time to meetings or whatever. This would not have been tolerated if others did it but supervision would just shrug and say “well, that’s just how Joe is.”

The above may not be your experience but it has been mine with MOST programmers. It’s just them being unreliable and uncontrollable for “normal” job functions.

Click to expand...

Are they needed for these designated meetings? Generally, mechanical engineers love meetings. Also, some project managers I've been with want a daily meeting. It's a waste of time and you just hear why they couldn't do whatever the day before. Butts in seats meetings is old school and not productive for me.

I've verily rarely heard a programmer say they can't do a job because they can't program it. Then again, a good programmer should have the project done and simulated/tested before install.

_Dock_ said:

I don’t think that is something I should share.

It lays out all the tag structure, AOI’s, routine structure, etc. they even go as far to provide an hmi template with their standard layout on it.

Click to expand...

That seems logical, but your previous post it I got idea that it is something available to public.

VAN said:

Are they needed for these designated meetings? Generally, mechanical engineers love meetings. Also, some project managers I've been with want a daily meeting. It's a waste of time and you just hear why they couldn't do whatever the day before. Butts in seats meetings is old school and not productive for me.

I've verily rarely heard a programmer say they can't do a job because they can't program it. Then again, a good programmer should have the project done and simulated/tested before install.

Click to expand...

I worked for several system integrators. I’m more referring to showing up at a designated time to begin a startup or checkout. A typical scenario was we were supposed to meet several maintenance people to try something out and invariably the programmer would be 20-30 minutes late which would screw up the whole day.

Again, this is not all of them or just one programmer but MOST of them. Sorry, but it’s true.

Another typical thing was/is many programmers would show up to perform a startup or field task and not have an extension cord for their computer, a table or stand to work off of, and expect others to totally accommodate them as if here comes Moses parting the sea. Sorry, but it got old after awhile.

Or

dogleg43 said:

I worked for several system integrators. I’m more referring to showing up at a designated time to begin a startup or checkout. A typical scenario was we were supposed to meet several maintenance people to try something out and invariably the programmer would be 20-30 minutes late which would screw up the whole day.

Click to expand...

Oh yeah, I'd be ****ed if they didn't show up for startup/check out (only if electrical and everything was actually installed). I can't tell you how many times I'd triple check that everything was ready to go or will be. Fly across the country and you know what wasn't ready? Electrical or Mechanical.

dogleg43 said:

Another typical thing was/is many programmers would show up to perform a startup or field task and not have an extension cord for their computer, a table or stand to work off of, and expect others to totally accommodate them as if here comes Moses parting the sea. Sorry, but it got old after awhile.

Click to expand...

I think more is going on than you are letting on.

robertmee said:

If you created six tags like that for scale weight components I would shoot you. Create one tag of a UDT with each element. I loathe opening up a controller tag db and seeing 1000s of tags like this. Organize them into components.

Now, not picking on you, but just demonstrating that one person's convention is another person's pet peeve. So to the OP, nothing that programmers doing is really an issue.

CS - anything that helps identify a tags purpose is fine
NEQ move saves scan time
500 array is better than needing an extra element later which can't be expanded online.

HMI - yeah if not using alignment tools, shoot the *******.

Click to expand...

Ok that was a bad example, because a Scale component should be in an AOI anyways. I don't use UDTs very much except for things like messages, records, recipes etc. Though I am contemplating using them more for poor-man's polymorphism since 5000 doesn't support interfaces or inheritance like Codesys does.



Because there is a huge feature gap between Program and AOIs in 5000 I am always trying to find the path of least pain. So where in Codesys everything for a single machine would be in 1 Program, and that program would basically be a bunch of AOIs (Function Blocks) that interact, in 5000 I have put a lot of logic in the same program, and or split it up in to mutiple programs and just try to using naming and comments to segregate as many different things as I can. It's a mess. This is why I had 5000, and the Rockwell fanboys are like "everything should be in controller tags and you should not use UDTs or AOIs except on extremely simplistic things. Also all comments and descriptions should be in ALL CAPS"

In Codesys really the only difference between a Program and a function block is that a FB can be instantiated and a Program is static. Which means you can write a massivily complete program in a Function Block, and then split it up in to more layers of FBs. It's really a beautiful thing. So then you can have your PLC control 1 machine or 10, and all that needs doing is IO mapping.



Well that was quite a tangent

rupej said:

I may be a knuckle dragger in this regard but I usually stick to using all controller tags for simplicity and maintainability by controls techs. Our processes don't lend themselves to multiple near-identical programs where tag names might be duplicated, though.

But I may be missing some of the advantages if program parameters. Would you mind sharing your thoughts on those?

But back to the original post- OP, you have my sincere condolences. That is an extremely frustrating situation.

Click to expand...

Even if you work with very unique machines, I'm sure there is tons of things these programs have in common.



Really program tags and parameters do you no good by themselves. They are tools for implementing Separation of Concerns. SoC is one of the most fundamental philosophy of programming. This methodology is what makes all modern software possible. Without it programming we would still be stuck in the era of mainframe procedural programming. You wouldn't have GUIs, Games, websites, hell the internet in anything but the most rudimentary form of communication wouldn't exist. Forget smart phones, or machine learning.



I once worked with a PLC programmer that told me "I don't like abstraction, it's too complicated" I just stared at him. Like I can't even come up with a good analogy to explain how stupid that statement is. On anything more than the most trivial things, abstraction makes things less complicated. SoC splits things up in to modules and those modules can be in bigger modules. They make complex programs simple to understand at a high level.



Scoped variables, and APIs are what we are really talking about with program tags, and parameters. These things give the programmer writing the program the ability to put rules in place for how other programmers are going to use that code. This is so they don't do stupid things like write to tags that are part of an internal process, and were never intended to be written to. They define exactly what tags are support to input data in to this internal process and define exactly what tags are the end result of this process. You can do this is comments sure, but comments can be ignored, the fact that you can can't access internal tags of another program can't be ignored.


So without SoC, you would put everything in one program, if everything is in one program than program tags do you no good at all, but they don't hurt anything at all, and they make refactoring a program in to more modular code, one tiny bit easier.

As for my opinion of Controls Tech needing things simple; they should never be looking at anything more complicated than an IO map in the first place. If they are then they are doing things that are in the realm of a Controls Engineer, which is great but that means they should be learning, instead of you dumbing things down for them.

Things like parameters, AOIs UDTs etc. are complicated tools but their purpose is to make complicated programs simpler to create and to understand.

Don't expect a man to build a house with a hand saw, and a hammer, because a miter saw and a nailer are too complicated, Teach him how to use the damn Miter saw and Nailer!

Programmers must to be able to understand a control problem, break it down and solve it.
That takes some skill and not everyone has got the knack for this.
It is an ability coupled with responsibility. I think that one should be proud when one has solved a task by using ones skill. Obviously there is the risk that the pride turns into arrogance. I dont think that the risk is limited to programmers.
The other side is that often programming tasks are not understood by non-programmers. "How hard can it be ?" or "The machine doesnt work, so something must be wrong with the program".
Couple the ignorance of the non-programmers with the arrogance of programmers, and there is the potential for conflict.

To the OP, I would demand by management that common standards and frameworks are agreed upon by a forum of all programmers, and all must adhere to the commonly agreed standards.
Creativity shall be allowed to a certain degree. The standards must not be a straightjacket hindering innovation. But creativity must happen in agreement with the other programmers.
A programmer that goes rogue and simply refuse to follow standards must be dealt with.

theColonel26 said:

I once worked with a PLC programmer that told me "I don't like abstraction, it's too complicated" I just stared at him. Like I can't even come up with a good analogy to explain how stupid that statement is.

Click to expand...

The comic strip B.C. had one: "I made an improvement to the square wheel: it's the triangular wheel; the improvement is that it eliminates one bump."

To the OP:
If there are maintenance techs at your plant say folks on another shift when the programmer isn't there, his programming style could generate a 2 am phone call. Perhaps you could convince management that there will be a day when they need someone to T/S this code and no one can in a timely fashion, thus the need for a standard. A logical standard. (Pardon the pun).
I'm working for an integrator now and we do a lot of work for an OEM that has very rigid standards in place for almost everything. They have a big tall building in downtown Detroit. I have to get a software certification to continue to write code for this OEM. Seemed pretty daunting at first, however now that I look at it (the code) it makes a lot of sense that they require this. Supposedly I can go into any of their plants and the code structure and organization will be the same. You may only have one plant.
Management needs to get on board and this "do what I want" stuff needs to be addressed. Good luck!!

robertmee said:

CS - anything that helps identify a tags purpose is fine
NEQ move saves scan time
500 array is better than needing an extra element later which can't be expanded online.

HMI - yeah if not using alignment tools, shoot the *******.

Click to expand...

CS - call me irrational, I just don't appreciate having redundant tags all over the program (one program level assigned and then duplicated as a controller scope tag). The fewer rabbit holes I have to jump down while troubleshooting, the better. Also the _CS (on several hundred tags) is visually distracting> I have nightmares of giant _CS floating through the air.

Would_CS you_CS write_CS a_CS book_CS with_CS CS_CS at_CS the_CS end_CS of_CS every_CS word_CS ?_CS

NEQ MOV - this method is actually slower because the NEQ has to execute before the MOV, the only instance where it could be faster is if the execution time of an NEQ where the numbers are equal is faster than a MOV. Look up the micro 1400, and MOV is a little bit faster than NEQ, so this really doesn't seem to be worth it....

Hardware level code to do a MOV looks like so, at worst:
1. Fetch data from N7:0 and assign to register A.
2. Move register A data into register B (N7:1)
:. MOV instruction can be executed in either 1 or 2 hardware instructions.

In contrast, a comparison instruction such as NEQ would execute like so:
1. Fetch data from N7:0 and assign to register A
2. Fetch data from N7:1 and assign to register B
3. Compare register A and B
4. Jump to label "equal" if equal
a. Return "false" result to calling MOV instruction
5. Jump to label "notequal" if not equal
a. Return "true" result to calling MOV intruction

Here you need 5 hardware instructions to make the comparison and return the result. In addition, you're adding extra overhead processing time (e.g. handling the comparison result) by adding a rung-in condition where it isn't necessary.

6. Fetch data from N7:0 and assign to register A.
7. Move register A data into register B (N7:1)

So, long story short, NEQ MOV costs at worst 7 instructions and 3 memory lookups, whereas a solitary MOV costs at worst 2 instructions and 1 memory lookup.

More so than the burden on the processor however, its annoying.

500 array - I hear you in that it can be a pain to add elements after a machine goes into production, especially when there is very little downtime. When only 5 timers are needed, however - you'd still put an array of 500? 64 error proofs - 500 for that too? To me its excessive. Try copying and pasting 100 recipes (that have multiple instances of arrays with 500 elements) into an excel spreadsheet.

Fourpaw said:

Just wanted to get some thoughts on dealing with co-workers who go off script.

We are a large manufacturing facility with multiple/ similar machines and most of the logic can be duplicated (standardized). My co-worker (equal) feels that each new task he is a assigned is an opportunity to reinvent the wheel so to speak, attempting to utilize rogue "logic-vomit" rather than what we have in place everywhere else.

One technique he is using lately (while vigorously talking to himself out loud) is to add a "_CS" at the end of EVERY single controller tag (RSLogix5000). So we now have 100s, sometimes 1000's of these "_CS" tags mixed in with controller tags that do not have "_CS" indicator at the end.

i.e.
Autn_CS
Autff_CS
Start_CS
Stop_CS
Red_Light_CS
Amber_Light_CS
Green_LIght_CS

The purpose - he wants to identify what tags are controller tags in the logic, without having to hover over the tag to see it's properties.

Other things:
- refuses to create an array in size that is anything less than 500.
- insists that there is an NEQ before EVERY single MOV instruction. i.e. if N7:0 does not equal N7:1, then move N7:0 into N7:1.
- HMI screens - lets go with the smallest font possible, and not organize or line anything up.

Seems crazy to me, unfortunately the managers here know absolutely nothing about programming, so I kinda have to live with it.

What would you do if your co-worker went off script and your boss(es) just didn't care?

Any other examples of logic-vomit like this that makes you lose sleep at night?

Click to expand...

I can understand his logic with the _CS thing. I use a different platform that is not Rockwell Automation, but I essentially do the same thing. I prefix all global variables with "GV" (All Global variable list names are prefixed "GV_"), for the same reason - so that I know just by looking at the name of the variable if it's global or local. Controller tags in RSLogix are equivalent global variables. In a nice way, I would just make it clear that if that's what he wants to do, then make sure all of the Controller tags are labeled that way, not just a few.

As for the other items on your list, doesn't seem too over-the-top. A lot of times doing things differently and understanding the reasoning might make sense, and ends up being a better method than the traditional norm your company has always used. I sometimes get kickback anytime I want to try something different. From my perspective most of that kickback is simply resistance to change. Have you asked this person his reasoning behind some of the other things he's doing that are not the "norm" there? I would do that first. Also, If I were in your shoes, I'd make sure I was understanding it all first. Keep an open mind.