Controls Engineers In Over Their Heads?

[Rube]

Casey's Just doin' the Casey thing. Maybe he's from Poll-and?

 

[Rod]

"Sure kid. Here is our latest machine. It has 124 Inputs, 8 are analog and 26 outputs, 6 are 120AC rated at 4+ Amps, 2 are 24VAC rated at 4.5 Amps. I put post-it notes on most of the pages we have to change.

Check with the IT guy. He'll issue you a laptop and the software he thinks you may need.

You should have no problem with your degreed knowledge.
The machine ships in 3 days.
The customer also wants a different set of animated valve controls. You should be able to find them on one of the last 4 machines we shipped.

Don't forget to update ALL the documentation and do a backup to the server.

You can TRY to reach me on my cell phone. I'll be in SouthWest WizzleFutze trying to unscrew what the guy you are replacing did.Because if I don't get it running by Wednesday the customer won't pay the last %50 of the agreed price and our company could go broke.

I gotta catch my plane - see ya"


No stress here

 

[akreel]

I'd say that more than 50% of the logic in my programs is only there to cover the 'what ifs' that COULD happen.

Of course, you can spend all your time dreaming up what-ifs and leave your "base code" full of vulnerabilities.

You have to assign a value to each potential "feature."

AK

 

[Rube]

I started in Maintenance, working on controls;

Then I taught myself the business of PLCs that control the controls;

Now I design our in-house control systems, machinery and conveyance. a benefit of this last item is that if I want to get mad at the controls engineer (can you be an engineer W/O a degree) I'll always know where to find him.

 

[Peter Nachtwey]

Good post, this is not the Control Guy's problem

This is poor management.

"Controls Engineers in over their heads..." It's the nature of the beast. Here's why:

1) The controls are always the LAST thing to be done on a machine or process. Therefore, any delay incurred by anyone else becomes the controls engineer's problem. He is by definition, "always under the gun."

Only if you permit it.

2) The control engineer must know how EVERYTHING works.

yes, that is why you deserve the big bucks.

This is so he (or she) can control it. Ask a machine designer to do something to the PLC and see how quick he will run away. Therefore, any machine design flaw becomes the controls engineer's problem.

Only if you permit it. We discussed on the 'motion madness' thread how some systems can't be controlled. I see screwed up hydraulic designs all the time. I see people wanting to move a lot of mass quickly but don't want to pay for the Saturn V booster.

3) The controls engineer is a slave to many masters. For example, sales, purchasing, the customer, ad nauseum. What this means is if there's not enough money to do it right, or someone wants a device that is not being applied correctly, this now becomes the controls engineer's problem.

Only if you permit it.

4) There is a fascination with technology that only controls engineers understand. Anything goes wrong, it must be the "PLC program".

That is why %50 of the software should be good diagnostics so you can cover your rear and correctly point the finger at the flaws and their creators.

Even a program that has worked for ten years flawlessly. Impossible that something mechanical broke.

I always ask 'who changed the code' If they say no one then obviously it be some other problem. It is possible for PLC I/O to break. That is why you need good diagnostic code and procedures.

Also impossible to tell because we had to use a cheap PLC, and there wasn't enough time or money to provide the documentation or training to the end user to support this beast.

Sounds like a poor sales or management decision to me. Did you tell them that the project was under bid? It is your fault if you didn't tell them. It is their fault if they didn't ask.

I could go on and on, but you all see yourselves stuck in the middle of what I am saying. I'm sure you all could add to my list.

Been there. That is why my integrator is wound up I chewed out the management a few times at my last job over 20 years ago. They couldn't fire me while business was good but they quickly let me go when business got slow. It was all for the better. The company that let me go is now a good customer. The old management has been purged. I had a job waiting for me anyway.

If you know more than the managers then tell them so. You had just better be right. If they listen then you still make them, and the company, look good. If they don't listen then your manager is making you, and the company you work for, look bad. THAT was one of the things pi$$ed me off most and I chewed out the manager that put me in a no win position. I remember that. I never put our guys in that position. I like to make sure our guys are armed to the teeth with tools and knowledge. Even our sales guys can tune drives and hydraulic systems.

Finally, the problem I have with too many PLC guys is that they don't know enough to know when they are being screwed. Assume nothing. Don't assume the mechanical guys know what they are doing. Don't assume the hydraulic guys know what they are doing. You can't do their jobs, but you must have some idea of what the major obstacles are and how obstacles affects your controls. I work with many companies. It is easy to spot the winners and loser.

 

[elevmike]

Even though I insisted I knew what I was doing, the big guy would'nt let me actually build a controller until I finished a 4 year field apprenticeship actually installing & repairing elevators, esclators, dumbwaiters, conveyers.. bla bla.. During that time my "design" changed dramaticly. It's all about the "what ifs" Eric's talking about. During my time in the field, I found out about them the hard way, and am still finding out about them. Time has proven that Pops was right.

 

[stasis]

I think what was intended to be asked is ' are there more controls guys who don't understand the basics of electricity/hydraulics/pneumatics'...if so, the answer is yes!
Ditto for programmers with 'tons of experience'...they get the difficult stuff but miss the simple, neat solutions by overanalyzing.

How many construction electricians understand the simplicity of a 3-way light switch, and can actually wire it correctly the first time? I could go on about other crafts, but as was mentioned in an earlier post, there is an obvious lack of pride in craftsmanship as well as workmanship, and this leads to a decline in professionalism as generations progress. The days where field electricians that could calculate Ohms Law formulas in their heads are all but gone. Sadly, this seems to be the trend in most crafts.

 

[PhilipW]

I suspect that most automation engineers find that the single biggest problem we have to face is that we are, by the nature of our work at the END of the project cycle. We are almost always the last man standing. (Except on timber mill jobs, then it is the optimiser guys.)

On most projects however we are treated as a minor cog in the wheel who trots out at the end, downloads some code and burps it all into life. Problem is that the design intentions at the START of the project have been hacked at by everyone else by the time we get to it at the END of it. Everyone else uses up time and budget, while the overall project timeline and total bucket of money remains essentially unchanged.

One of the hardest lessons I have had to learn is that this inherently makes the work I do high risk, and I have to quote/charge accordingly.

 

[Tom Jenkins]

Well, I'm in over my head on every project, but I alays rise to the top eventually.

Seriously, my biggest problem is that controls guys and the trades don't understand that engineering, and construction for that matter, is a process and not a body of kowledge. They expect that there is "an answer" in a book someplace or on the internet and they just haven't found it. Look at many of the HNC type questions we get here.

The trick, of course, is to teach them to go back to basic principles of how something works, how the energy moves around, and how to work out a step by step sequence that reduces all of that to an NC contact in the ladder logic. That takes patience and discipline.

I don't fault new guys and IT bit weenies for not knowing the answers, I fault them for sloppy mental processes and for not being willing to grind through the steps to get the job done.

 

[MarkTTU]

I don't fault new guys and IT bit weenies for not knowing the answers, I fault them for sloppy mental processes and for not being willing to grind through the steps to get the job done.

Well said