Programmers who go off script

Fourpaw

Member
F
Join Date
Mar 2007
Location
Florida
Posts
54
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.
Auto_On_CS
Auto_Off_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?
 
Fourpaw said:
- refuses to create an array in size that is anything less than 500.
​
Well, memory is cheap, ...
- 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.
​
but wait, memory is cheap, and CPU time is not?
- HMI screens - lets go with the smallest font possible, and not organize or line anything up.
​
Screen real estate is not cheap, so I get the small font, but to then not arrange things to take advantage of the space saved in fonts seems silly.
Click to expand...

I got bupkis practical to offer you, other than either 1) grow a thick skin and find summat else to worry about, or 2) have all programmers meet and vote on style conventions, with the agreement that any code not meeting the style must be fixed by the original coder. Although with managerial indifference and/or ignorance I doubt you can enforce it.


I'm generally an independent contributor, so I rarely run into this; when I have the style conventions were already in place.


The _CS thing seems interesting e.g. I sometimes prepend i_/x_/s_/etc. for integer/float/string/etc, though most would not think so; maybe suggest this person either update all programs to conform to the convention (a convention is not useful if it is not universal), or drop it altogether?
 
I have worked for a lot of large organizations where standards were put out for people to follow. It works for the most part until someone like you describe comes along.

Maybe he does not understand the big picture?
Is there a plant standard?
If someone does not follow the standard what can you do to get him on the path?
Maybe go route to review his code and make sure its to plant standard before he moves on to other areas?
Get your manager involved?

I remember I was part of a overview display graphics for one company. We had this office that never followed the tag standards, so anyway it always made getting the job done take 2x as long. My manager said we could not tell them to redo it but only suggest that they follow standard and it wont make you late on graphics. I guess you have to laugh sometimes at project work and trying to get some people to see the light.
 
I don't know how big your programming shop is, but go to an agile-ish methodology where everybody reviews all code and none gets in without unanimous consent.


Absent managerial support, not sure if that is any different than your current situation.
 
I feel your pain, i have had the same issue.
the only way to solve this issue was to go to the engineering manager and tell him what was going on. that person eventually gave in and left shortly after that.

when a company standard is set in place it is for everyone to go by. this avoids confusion between various programmers and allows others to debug the programs
more quickly. having multiple machines of the same is also another reason to keep to the standard.
james
 
Last edited:
My take from this is your 'equal' has decided it "has to be done his way"

I have worked with people, even supervisors, that said from now on it can't be done 'that way' it has to be done his way - and one maintenance supervisor could take 2 or 3 days to come up with 'his way' and some of them were so convoluted and weird
 
Standards

It seems that most of my customer's standards concerned brands of equipment and software and nothing about how to do work with it. The 'standard' might not even extend to family of processor so it was of very little value. I think management assumed that as long as you were using a Brand X PLC that they had done their job in setting standards.

Most integrators have standards that they use for projects but they are probably not open published things. This leads to the concept of a 'framework' - a methodology that defines PLC code and HMI interaction.

I never realized that I was developing a framework over the years until I heard the term recently. It's a lot of work to get it clearly documented and established in a way that has enough rigidity to be of value and yet not be overly restrictive.

I think the computer people have gone through the same thought process. Structured handcuffing of programmers can be a good thing sometimes. That may have been the thought behind the ADA programming language where it takes an act of Congress to convert data from one type to another.

I wish you well with your problem. There's lots of sympathy here.
 
I've worked with programmers, machine designers and toolmakers and every place had the one guy that has to show you how smart I am.
 
Have that coder do a cost benefit estimate on each new standard they introduce (we save X hours per day because the tag names end in _CS, and it costs Y hours to do it).


If they cannot justify a decent ROI for each idea, then they should either drop it or be fired.
 
It's a management problem. When guys worked for me they followed my rules or their butts hit the street. The flip side of that was that I was willing to change to their way of doing things, but only after we talked it over. It then became the new standard practice for everyone.

If you feel comfortable asking your boss about it, do so. If not, suffer in silence.
 
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.
Auto_On_CS
Auto_Off_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...


Well first of all you shouldn't use controller tags in any logic, They should be mapped to Program Parameters using Connections. Other wise you are creating a tightly coupled mess.

As for as "_CS" I think it is silly in this instance, but having structured and detail naming conventions for Tags is a good idea. Some of my Tags actually hit the tag character limit in Studio Designer, but no one will ever question what that tag is for, If I have tags that are of differnt Types I will often do something like


  • ScaleA_LiveWeight_Int and ScaleA_LiveWeight_Float
  • ScaleA_LiveWeight_Int_LB, ScaleA_LiveWeight_Float_LBS, ScaleA_LiveWeight_Int_KG, ScaleA_LiveWeight_Float_KG



I think the biggest issue you have is buy in from him on your standard practices. Standards are not intended to be unchangeable. Let him influence them. If you want him to stop deviating then include him and the decision making for your standards. Otherwise you can either live with it or fire him. I doubt you will get him to change otherwise. These things are a 2 way street, everybody needs to give a little, to form a consensus.




Fourpaw said:
- HMI screens - lets go with the smallest font possible, and not organize or line anything up.
Click to expand...
HOWEVER, If he did this with me He would have an unfortunate industrial accident.
 
theColonel26 said:
Well first of all you shouldn't use controller tags in any logic, They should be mapped to Program Parameters using Connections.
Click to expand...

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.
 

Similar Topics

dalporto
Wonderware integrators / programmers - Need opinions
Good morning all. I'm working on a rehab where they had a standalone InTouch 2014 HMI that they called a SCADA, but it's really basic stuff. The...
Replies
4
Views
179
dalporto
dalporto
P
OT Programmers Break Times
Thought this might cheer people up
2
Replies
22
Views
6,625
I_Automation
I_Automation
Peter Nachtwey
Should there be a minimum internaltional standard for PLC programmers?
Yes or now and if yes what would you include or test for as a minimum standard? I can think of things like DeMorgan's theorem Karnaugh maps -...
3 4 5
Replies
60
Views
23,145
JLand
J
M
Any London based Siemens S5 programmers out there ?
Hi All, Looking for someone to help one of my customers with a very old Siemens S5 PLC that we need to try and get up and running again while we...
Replies
8
Views
2,069
sigmadelta
S
B
Siemens Programmers Birmingham UK
Hi, if you know of anyone who is a genius with Siemens working around the Birmingham UK area and wanting some easy money. I am having a lot of...
Replies
1
Views
1,279
janner_10
J
Back
Top Bottom