Programmer

[SMOKE]

Wow, there is lots of people out of work... We put out an add for a maintenance worker that can program PLC's etc. I got a ton of apps from people that are basically IT or better programmers, but no PLC experience. I am sure some/most can learn fast, but they will take the job while looking for what they want. I need a PLC programmer and hopefully a FANUC robot programmer that will also be willing to change shear blades, converter belts, etc, your going to get dirty. You want PM me.

[dmroeder]

Although I'm not looking for a job, I am curious as to where you are at?

[SMOKE]

North Utah.

[James Mcquade]

Smoke,

we had an oem that we purchased (3)machines from.
the programmer was an it guy that knew visual basic
and thats how he wrote the code.
It still is hard to debug and understand what he did or what his reasoning was for placing the code in the locations in the program where they ended up.

Just a comment.

regards,
james

[sthompson]

I have to deal with PLC Programs that have been written by outside Integrators. It was before my time, but this guy should have been writing Tax Programs, not PLC Programs. They are a bloody nightmare to Troubleshoot. I have spent many hours fixing bugs in them that only show up randomly. As just one example, he starts all the motors by loading numbers into and Integer file, and then calling a Subroutine. If the Motor doesn't start, why didn't it start? You have to sort through a bunch of numbers, and try to figure out what they mean. Ugh! I have rewritten some of it, but on a running system, it is pretty hard to just shut them down to make wholesale changes. That is just one story, I have many more from systems I have worked on that were written by people that had no business writing PLC Programs.

My advice it to avoid people from IT, Computer Programmers, Rocket Scientists (Yes really, been there, done that) and similar backgrounds. They seem to think their Programs are perfect, and nobody will ever have to Troubleshoot it. So, they are written in a manner that makes Maintenance and Troubleshooting difficult. Having said that, my first programming was in Basic, and Assembler many years ago. However, I had tons of hands on practical experience before I started modifying PLC Programs, and the moved on to writing them from scratch.


Stu.....

[Lynn_2009]

You know, it is so funny how some so called "programmers" can get away from simplistic fundamentals. PLC's can be as complex, or as simple as you make them. I wish I could stick all of the "programmers" on the factory floor for just one week and force them to troubleshoot their own work.

[sthompson]

Originally Posted by Lynn_2009

You know, it is so funny how some so called "programmers" can get away from simplistic fundamentals. PLC's can be as complex, or as simple as you make them. I wish I could stick all of the "programmers" on the factory floor for just one week and force them to troubleshoot their own work.

Amen to that. I would like to see every Electrical Engineer to spend a year on the tools in the real world. I have found that Engineers that have come up through the ranks design better systems, are more practical, and actually listen to input.

Stu......

[harryting]

Just personal observation, PC programmer typically makes the worst industrial control programmer.

"Oh, that's so old tech, let me just roll a quick C# applet..."

Me, "heck no, you don't!"

[Jeev]

I too am of the opinion "PC" Programmers are bad news. Not only for the reasons mentioned above, but when your web site script goes wrong you don't strip a 50mm threaded shaft via a 3kW motor and destroy a 500kg, $50,000 magazine assembly.... And they don't even think to hit the E-Stop as they stand there watching things go wrong.

"Why do I need to stagger starting these motors?"
"What's Pneumatic Latency?"
"It worked when I simulated it!"
"I can program in Basic, C, C+, C++, Java, Pearl, Ruby, PHP, HTML, VB, Python, SQL, , Pascal and Scheme... What's Ladder Logic?"

.... Sigh.

[James Mcquade]

I am an electrical engineer and that's exactly what i did right out of college. I worked my way up.

I have learned a lot. but here's 3 key things to remember,
1. you must always consider othere.
2. you are not the smartest guy in the world, someone else may be able to take your idea and improve on it.
3. the most expensive piece of equipment isn't worth a *!@#$** if maintenance cannot work on it and debug the plc program.

you must work with others, you won't live for ever.

regards,
james

[sthompson]

Originally Posted by James Mcquade

I am an electrical engineer and that's exactly what i did right out of college. I worked my way up.

I have learned a lot. but here's 3 key things to remember,
1. you must always consider othere.
2. you are not the smartest guy in the world, someone else may be able to take your idea and improve on it.
3. the most expensive piece of equipment isn't worth a *!@#$** if maintenance cannot work on it and debug the plc program.

you must work with others, you won't live for ever.

regards,
james

Well said James.

One of the first systems I designed, I was explaining to one of my coworkers with the nice CAD Prints I had generated. His reply was "Well I really don't understand everything you've done, but it sounds like you have a pretty good handle on it. I just have one question though, don't you think you should put some fuses in?"

I was so focused on the process, that those little details hadn't occured to me. Needless to say, I went back over it and put appropriate fuses in where they were required. Sometimes it is good to have another set of eyes look at things.

Stu.....

[kamenges]

Originally posted by Lynn_2009:

I wish I could stick all of the "programmers" on the factory floor for just one week and force them to troubleshoot their own work.

Bad example. No one has any problem working on the systems they develop. They developed them. They know how they work, what they are supposed to do and, generally, where they go wrong when they don't do what they are supposed to. It's the people that didn't develop them that wonder what is going on.

You are really talking about a documentation issue. If the program and, more importantly, the process are documented well, both internally and externally, then even "difficult" code isn't all that difficult.

I do some side stuff occasionally on stuff I have never seen before. It isn't the plc program that is usually the issue. It is that there is no description of what the goofy machine is actually supposed to do. Even the operators don't know much more than "I put stuff in here and get other stuff out here if I push this button". If I have a good process description life is pretty easy.

Keith

[godfrey]

I believe that the original poster would do well to hire the interested student. If you want retention, find the guy who shows interest and the ability to grow into the job.

[SMOKE]

I would love to bring someone up. They would learn to be a bit sequence programmer. I have to have someone that knows even if they drum sequence. We spend a couple of million a year on ground up machines. Well we usually do but the bad times have touched us as well as many, but I am told we are going to do close to 1M next year. I am now the only programmer and I get called in all of the time. Last time the rubber on the hydraulic pump coupler failed. They called me because of a following error. Hard to follow when the pump is not turning.
Our previous programmer used a loose version of state programming, But state 7 might add of remove actions, so its like 7a 7b 7c.

[PLCRookie]

Originally Posted by Lynn_2009

I wish I could stick all of the "programmers" on the factory floor for just one week and force them to troubleshoot their own work.

That would be easy. Let them spend a week troubleshooting SOMEONE ELSE'S work......