Are you sometime self-indulgent at work?

Iner

Member
Join Date
Mar 2010
Location
France
Posts
190
Some people can be passionate at work and it can lead to some situations where you do things more for enjoyment and personal interests than the basic needs.


Recently, a colleague programmed a special machine in a very advanced and complex way, spending his time creating new features blocks instead of using the standard, monitoring every possible event, doing in the process way more than needed. His program works perfectly, like a swiss clock, but he basically doubled the estimated time and taxed the CPU so much that he needed to change it because the cycle time was way too high. it will also be hard to for someone else to modify it. The internal project manager was left in tears.


I myself remember spending 3 days testing, demoing , ameliorating another possible solution to see if it would have been better than the one I just used and which worked. Writing a simple VB.net application to read data from a S1200 on a PC and printing it instead of using the CPU taxing (50% of Work memory) FTP client. There was absolutely no need other than my curiosity.


I also remember fighting back against my superior who wanted to throw 2000€ more at a unneeded higher end CPU range, just because it would please him to know we were installaing this product.


Are you also sometime guilty of this?
 
I do my experimenting on my home control system. There I can try new and complex ways of doing things. As for a system I am selling to run production machinery I try to keep it simple to run and troubleshoot.

I had an accumulator for a panel shop that held up to 24 panels, then fed them as needed or they were removed by hand. The program in it was so complicated with sequencers and latched bits that it was impossible to troubleshoot. I wrote an entire new, simple, program in about 2 hours and it has run for years since.
 
There is definitely a discipline required. I have worked in environments where everyone did their own thing and one where we had an established method and worked as a team. Team projects tend to minimize variation, but only if the team understands that it is in the best interest of the project. Experienced people working on teams seem to understand collaboration better than inexperienced. I see it quite often where people on a team are still changing things because of preference, not because it works any different. That is just money out the window.

Seems to be a lacking skill in knowing when code refactoring is required, or when to follow established standards despite personal preferences or when to create a new solution for a new problem while aligning with the team method.

There is a time and place to go, rogue, it's not as often as people think.

My driving factor is if my effort will increase my or my team's productivity, increase feature value or reduce development time. Years ago I took it upon myself to rebuild an excel workbook we used for code generation and general device/instrumentation tracking and configuration. I did it because I had some spare time and it frankly was garbage. I turned it over to the team and within a year the feature set grew substantially as others were able to easily add new fetures.
 
Last edited:
not if you are the one who maintenance calls at all hours of the day with problems. 7 am, 9 am, 2 pm, 7 pm, 2 am, ……

1. when this happens, management will want to know why the machine
doesn't make production.
2. the plant manager calls your boss and chews him out and threatens not to
pay the final payment because the machine is a piece of junk.
3. your boss calls you in his office and chews you out.
reprogram the machine or else !

It has been my experience that taking the time to program the machine to where maintenance can understand what's going on trouble shoot the system when there is an issue will save you lots of grief.

when they do call, you know that they have at least tried to fix it and they can talk to you over the phone and get your help and possibly avoid going 200 miles one way for a broken / loose wire. in my case, the circuit breaker tripped. it was the last time we ever used that brand of circuit breaker.

james
 
There is definitely a discipline required. I have worked in environments where everyone did their own thing and one where we had an established method and worked as a team. Team projects tend to minimize variation, but only if the team understands that it is in the best interest of the project. Experienced people working on teams seem to understand collaboration better than inexperienced. I see it quite often where people on a team are still changing things because of preference, not because it works any different. That is just money out the window.

Seems to be a lacking skill in knowing when code refactoring is required, or when to follow established standards despite personal preferences or when to create a new solution for a new problem while aligning with the team method.

There is a time and place to go, rogue, it's not as often as people think.

My driving factor is if my effort will increase my or my team's productivity, increase feature value or reduce development time. Years ago I took it upon myself to rebuild an excel workbook we used for code generation and general device/instrumentation tracking and configuration. I did it because I had some spare time and it frankly was garbage. I turned it over to the team and within a year the feature set grew substantially as others were able to easily add new fetures.


I think that teamwork can effectively limit these habits, but it's not that easy to implement. To implement a large DCS in a chemical plant, you will obviously need a disciplined team. But in a special machine, it's often a one person project for automation , sometimes another one for schematic or robotic, sometimes not and that's where the door is open if the customer is not a hugely standardized company and is not closely monitoring.


It's less about going rogue, than wanting to do better and in our own way. Sometime the best is the ennemy of the good as we say in french.
 
3. your boss calls you in his office and chews you out.
reprogram the machine or else !


That's one of the most unlikely situation. Has any boss asked to reprogram a working machine after all the hours have been spent?


I agree about trying to make the installations easy to troubleshoot, but if they have to enter the program for that, that's already a big hurdle for a lot of maintenance people.
 
I'm kind of lazy* so the easiest/simplest way to do the task is usually the best way for me.


I always think of the old operating system QDOS, which originally stood for "Quick and Dirty Operating System" - this pretty much sums it up.


I have a few colleagues that are very thorough on the border to extreme. Don't get me wrong, it works well and they are really great at what they do - but i would not do it the same way.









*(Not to be confused with less/bad work moral)
 
I probably do around 100 projects a year, 80% being bespoke. I wish I had time to mess about with stuff like this but experience has taught me, KEEP IT SIMPLE!

When you return in 3 years to make changes, you thank yourself.
 
I agree about trying to make the installations easy to troubleshoot, but if they have to enter the program for that, that's already a big hurdle for a lot of maintenance people.

Maybe going a bit off-topic here...but a lot of young sparkies here these days can only use the PLC code as their troubleshooting of default, many cannot even read an wiring diagram....
They get a fault on the plant, go to the programming PC, find the input that is stopping the plant, go to the panel, get the input, pull the wire out the trunking til they find the source, leave the panel hanging like a dog's dinner..but they have got the plant going. Or they force the input on or off, or jumper round it in the code, depending on their needs.

I once tried to make some file moves for alarms to simplify the required logic and save memory. Lasted a couple of weeks -"oh we don't understand how that works, can you break it down into individual bits?" so I had to rewrite it into multiple outputs per rung, so the maintenance guys could understand in simple bits only. They were blind to words...........
 
I probably do around 100 projects a year, 80% being bespok


100 project a year? You are a work beast !

Maybe going a bit off-topic here...but a lot of young sparkies here these days can only use the PLC code as their troubleshooting of default, many cannot even read an wiring diagram....

Once I saw a maintenance technician jump instantly on his laptop PC, connect it to the PLC in order to search for a default , the HMI was telling "default: no air". He did not find why. The main valve of the machine was closed.


When you are programming, you have to comment and document to help people understand it, but you can't make the whole program based on the premise that it will be read everyday for troubleshooting.
 
I have to spend a lot of time travelling shorts distances to jobs. At first it bothered me thinking how much work I needed to be getting done and I am stuck on the road for 3 hours at a time.

I had to keep telling myself "Paul, you are getting paid to drive around in a brand new truck with air conditioning and listen to the radio..."

Now I spend that time listening to 80's metal, which I consider to be quite self indulgent.

On the subject of programming style, with ladder logic, I am pretty disciplined. I may occasionally use indirect addressing or some advanced style of sequencer, but only where it fits and I comment the heck out of all of it. With HMI programming I may experiment with some obscure things occasionally leaving things in place that are not exactly straightforward. Since we use mostly Red Lion HMI and Ignition for PC based SCADA, it is pretty quick easy to go back and simplify things if I find I have done something "over the top".
 
Iner,

I do not know how to reply with quote, but yes, it does happen.
when your customer is a tier 1 supplier to the automotive industry and the machine downtime is about to cost them $10,000 a minute (this is the actual penalty from an automotive plant) when full production starts up and you have a $1,000,000 po on hold because of this issue, the machine will get reprogrammed.

one programmer loved sequencers because he could program the machine so fast. hardly no documentation. he finally left the company.

another programmer when he programmed analog comparisons NEVER EVER used the equal to statement! a > b or a < b never a = b.

This is why I always stress that programmers need to work with maintenance and find out what their capabilities are. I spent 3 months reprogramming a machine programmed in Grafcet ladder logic at another company I worked for. downtime went down from 20 hours per week to around 2 1/2 hours per week.

james
 
Another thing about downtime that relates to machine updates:

Customers frequently want updates done while production is running. No shutting it down to add offline edits. That price per minute for shutting down an automotive plant hovers over them in every decision they make, and if a programmer causes a shutdown they may try to have them cover the costs (might not be successful, but they will try)
 


There is a quote button on the bottom right of the messages.

At the auto manufactures there is little to no programmation freedom. They use extremely heavy standard. You must use their standard blocks, you must use their structure, their tag names, the list of approved material cover everything. They are at some plant even auditing the program in simulation before it even make it to the new machine, and they audit it after as well. They even have tool like programm generators who create the main structure and the blocks following what you selected. They also have dedicated standard control people.

Every specific and out of standard material or code will have to be approved. There is no room for creativity there. Working for them is less about programming and more fulfilling spreadsheets.

This is why I always stress that programmers need to work with maintenance and find out what their capabilities are. I spent 3 months reprogramming a machine programmed in Grafcet ladder logic at another company I worked for. downtime went down from 20 hours per week to around 2 1/2 hours per week.
This topic is interesting. Are you programming a machine the fastest and (according to you) the most efficient way, or are you programming a machine the most basic way to allow even non programmer to understand it?

Why did the downtime get reduced so much? Because the new program was less buggy or because the maintenance understand it better?






I have to spend a lot of time travelling shorts distances to jobs. At first it bothered me thinking how much work I needed to be getting done and I am stuck on the road for 3 hours at a time.

I had to keep telling myself "Paul, you are getting paid to drive around in a brand new truck with air conditioning and listen to the radio..."

Now I spend that time listening to 80's metal, which I consider to be quite self indulgent.


If you are driving during the whole day, you can take it cool. If you are driving 3 hours the morning, working the whole day and then coming back at 2 AM, then it"s a little less cool.
 
Last edited:
Another thing about downtime that relates to machine updates:

Customers frequently want updates done while production is running. No shutting it down to add offline edits. That price per minute for shutting down an automotive plant hovers over them in every decision they make, and if a programmer causes a shutdown they may try to have them cover the costs (might not be successful, but they will try)




For online modifications or failures at start up, they generally charge around 1 000€ in my area per vehicle lost (by lost I mean the time).


That's why they are also charged something like 10 000€ for workd like adding a sensor and an alarm.
 

Similar Topics

I am facing this issue quite often where I want to read from this gateway but it stops after sometime. I am able to read data from it for few...
Replies
8
Views
2,815
Hello friends I think this is the second post about this all over the internet, first one was in 2013 by some guy from Canada who experienced the...
Replies
26
Views
6,331
Hello; We have an Allen Bradley compact logic processor at an auto glue kitchen of corrugator machine which connected with AB HMI. Normally to...
Replies
5
Views
2,419
Hello Friends, I'm starting a new job soon, towards the end of September, that will be using all Beckhoff equipment. I have programming...
Replies
4
Views
1,027
Hi all, Any experience of the above? Happened 3 times now in 1.5 months. Processor is about 10 years old, software major revision is 19...
Replies
9
Views
5,516
Back
Top Bottom