one for the Masters

Discussion;
I recently received an inquiry about a position as a programmer of PLCs. First some background... I have been involved in Industrial controls and electronics for over 30 years, and have even been given the honor of teaching. I quit teaching to get back into the applications of control. There are not to many things going on in any industry that I don't have some knowledge of. I have always said give me a well written spec and I will make it work.
Now the kicker to the e-mail, previous machine control programmers need not apply.. this is a process control position.
Well I just thought that the MORON who wrote this has absolutly no idea what goes on in the world of programming. My next thought is that the employer wants an Instrument Technician.
Well needless to say I did not even reply to the inquiry.
I hope the dumb guy is an avid member to this forum and gets his head on straight.
ANY COMMENTS?

just a Bitmore

I would guess that the ad writer has had a recent unpleasant experience with the previous (or current) holder of the position.

But, I agree, just because one person with a machine control background failed to meet expectations (reasonable or otherwise), doesn't mean others with similar background will do the same. I'm sure the guy would like to hire someone with years of experience and stellar performance in his particular process - but how likely is that? And can he afford it?

We all make mistakes and hire duds occasionally, but eliminating candidates with that sort of generalisation only makes the probability greater.

Thanks for your reply but not to quell the enthusiasm, what is the difference? If a control specification is well written then what difference does it make?
Machine or Process? The obvious answer is.... NONE! I am of the adimate idea of "if it works on paper" then it works in control... either machine or process, and if the programmer cannot make it work to spec don't blame the "type of engineer" blame the engineer!

bit

Bitmore,

As I was reading your 1st post I was asking my self "what in the world could be the differnece?"; As the programmer programs a Machine to control a Proceess . When I got to your last post, I realized that I wasnt the only who is so ignorant on this issue.

However to give some benifit to the doubt; in many large orginizations the Engineering Department Head would typlically fill out a employment specification form and send it to the Human Resources Department. At the HR Dept. some clerk takes that form and creates an ad of some sort, based on a computer form. The information may get transposed onto various formats a number of times before a solicitation winds up on your doorstep. Any one, or all of these "transpositions" are subject to human interpertation, and error. The origional specifier may very well be a member of this forum and not even recognize the quote you provided from the final form of the solitiation. With this in mind, if I were looking for a new job, I wouldnt be afraid to send my resume dispite the apparent conflict of terms used in the ad.

Mike

IMHO, process control people are involved in making stuff. The machine control people are involved in making things. Traditionally, process control people program DCSs, machine control people program PLCs.

It sounds to me like the person who wrote the ad copy had his (or her) head where the sun don't shine. When the ad requests a PLC programmer and says they only want process control people, no machine control people need apply, you wonder whether they have any idea of what the job involves.

Traditionally, process control people program DCSs, machine control people program PLCs.

Click to expand...

Well thank you for making that clear and also for your agreement on the knowledge of the "head hunter" but to be more realistic, does not SCADA and other DCS have their birthrights because of PLCs and programmers? And what would we call those who program DCS? Are they not still just plain old "machine" programmers albiet the machine is large and its output may me solid, liquid or gass? I also forgot no "cycle start" button.

Just a bitmore insight to "programming"

Usually I think of machine control being based on a discrete process control and process control being more of a continuous flow. Machine control typically has more high speed requirements, more discrete I/O with a little analog and some motion control thrown in. The process control is usually slower, maybe higher i/o counts and much more analog. But now most of the typically DCS and PLC platforms have started to converge with the hybrid platforms to throw all these concepts under the same control system.

The only other distinguishing features that I could think of is that most process control people will be familiar with S88, batch processing concepts. Most "machine programmers" will not know what batch managment software is.

Is one more difficult than the other? I don't think so, each one has it's own challenges. I think that any engineer that is proficient at one can transition to the other. Especially as the control suppliers have shown with their hybrid platforms that many processes allready require some of all the different concepts.

By the way I agree that the person who wrote the request has no idea of the requirements, just probably a list of negatives from previous attempts to fill the position.

Just my two cents,

Darren

Most "machine programmers" will not know what batch managment software is.

Click to expand...

I beleive it's another form of "machine specific functions per prescribed input conditions" more easily called control.
but yes I agree with all that has been said, but still my point being is...The differences are nothing more than the techniques used. Not the "Learned Engineer"

I think it's safe to ***-u-me that the "head hunter" is looking for more than some kid that has only experience programming PLCs and nothing beyond PLCs. They probably got hung with some guy, or interviewed a lot of people that had limited experience, and want to weed thoes people out of their search.

That's my take on it.

Mike

There is a world of difference between process and machine control. When I think machine, I think making widgets. When I think process, I think oil refinery. Having been in machines for years, I would be a fish out of water if suddenly I had to do process stuff. Not that I could not learn it, but it would take a while before my expertise reaches the same level as with machines.

If I were a potential employer, I would be leery of anyone who thought otherwise, or acted like the difference was no big deal.

If I were a potential employer, I would be leery of anyone who thought otherwise, or acted like the difference was no big deal.

Click to expand...

I guess I have made my point. We programmers are no longer "programmers" but like most other sad sacks must be delegated to one thought, one idea!
B@#$KSH(&^T

but it's just my opinion
bitmore

There is obviously a significant difference between the control system for a refinery and the control system for a transfer line. But to exclude a person with experience on one when you're looking to fill a position involving the other is foolish. The knowledge and discipline that a person brings to the task in either industry is easily transferrable.

I think what you're seeing here is the dark underside of outsourcing the hiring process. The headhunters and flesh peddlers of the world don't take the time to learn enough about the types of jobs they're trying to find candidates for. They simply have a checklist of qualifications. If they cast their net wide enough, they can sift through a large enough pool of candidates so they can filter out everyone that doesn't match up on every single point. The flesh peddler only gets paid when the position gets filled, so it's in his best interest to pass along candidates with the highest percentage matchup with the qualifications.

I believe there are three differnt takes on this.

Machine control
One: The guy that has been in the factory programming/designing machines for a living for years that are unique or propriatary to their process.

Process control
Two: The guy that has been in the factory not necessarily programming, but definetly designing and planning the process. IE: More of a designer than an engineer if you understand what I mean, because to me there is a big difference.

Contractor/Jack of all trades
Three: The guy that is a contractor that has to deal with both ends of the spectrum. They are not only responsible for the engineering but also the interpretation of the process requirements.

I belive the way that you look at this, or better yet what influnces your oppinion on this subject is more of a matter of background than anything else.

The knowledge and discipline that a person brings to the task in either industry is easily transferrable.

Click to expand...

Now... I will rest my case.

bitmore

I do agree with the point that exclusion of people like that is foolish. Or at least their method is clumsy.

However,

Bitmore said:

I have always said give me a well written spec and I will make it work.

Click to expand...

Who writes the spec? Granted, given a map, you should be able to get to from point a to point b. What other kind of value can you add? Will you be able to say, "We tried that method, buy it didn't work so well." Or "Try this, I have found that in similar situations we had good success." Don't take this personally, just outlining what might go through the employer's head.

Of course the simplest way to go about that is to say "Experience with X is preferred"