Getting Started

[DriPLC]

Hey Guys,

First post here and looking through, there are a lot of people that have different expierences and practices. A little bit of my background, I have been in my position for a little over 2 years now. PLC related work involves me troubleshooting downed machines, adding components to machines and working with prexisiting logic. I even had to do a little of reprogramming a machine a vendor had made for us that was not to our standards. My question is that, how would I get my foot into a intergrators door? I really want to learn how to code from scratch and go through the whole process. My dream is to work for an automation company and to make a customers idea a reality. Looking for some guidence on key stuff to learn that I could help me with the interviewing and scouting process. Any criticism is appreciated.

Thanks!

 

[TheWaterboy]

California companies always seem to be looking. Of course there is probably good reason for that. :0 Not worth moving here.

 

[Steve Bailey]

how would I get my foot into a intergrators door?

Do any integrators do any work for your current employer? If so, introduce yourself to them and find out who to contact.

Do you know the integrators in your area? Contact them directly.

Looking for some guidence on key stuff to learn

There aren't too many jobs where you only program PLCs and HMIs. You need to become familiar with all of the hardware necessary to make automation happen. Look through the Automation Direct catalog and ask yourself how comfortable are you with everything they offer. Because sooner or later you'll be dealing with all of those items.

If you want to be the person who designs automated systems starting with a clean sheet of paper you'll also need to be up to snuff on the 'forever' knowledge underlying how the components work together. That includes math, physics, thermodynamics, chemistry, etc that you learned (or should have) in school. For example, given the mechanical drivetrain for a mechanism and the work that it needs to do, could you select the proper size motor for it?

 

[zachary.wilson]

Howdy, there are 1000 ways to skin a cat, only if the cat is alive is it wrong, like mentioned above, I trouncing yourself to I tegrators is always a good thing, even more so, if they offer a training course to go over the basics of how they have done things. That is how I got an open invitation for a job interview at one company. Biggest thing is look at the different machines you have and how they program, so.e use indirect addressing, some use latch bits, some don't, some call alarms on the hmi, but use words typed into the plc as the display, so you don't have to do an hmi update to add one alarm. (One of my favorites) find what you like and don't like, and focus on that to get better at those things and how to correct items you don't.
You'll find lines of rung that u latch themselves, which are annoying, they work until they don't and then it's hard to find. Stuff like that.
Another great thing to do is get an old plc, doesn't matter what it is as long as it runs the programs you want, and start playing, make it turn on a light, turn on a buzzer when your chair is pulled out, stuff like that

 

[JTCat]

I highly recommend you learn Pascal. Most Structured Text is based on that language.

 

[busarider29]

Hey Guys,

First post here and looking through, there are a lot of people that have different expierences and practices. A little bit of my background, I have been in my position for a little over 2 years now. PLC related work involves me troubleshooting downed machines, adding components to machines and working with prexisiting logic. I even had to do a little of reprogramming a machine a vendor had made for us that was not to our standards. My question is that, how would I get my foot into a intergrators door? I really want to learn how to code from scratch and go through the whole process. My dream is to work for an automation company and to make a customers idea a reality. Looking for some guidence on key stuff to learn that I could help me with the interviewing and scouting process. Any criticism is appreciated.

Thanks!

A few things that will be a must the next time I hire an automation/controls engineer:

1. Must have a STEM degree
I don't care what specifically it is, but must be STEM. I would even accept a 2-year STEM (but preferably 4 year). A STEM degree proves to me that you've at least been through some math past grade school level. That's a must. Working for an integrator, you are going to be required to write all the code, not just simply going online with a processor and following code someone else wrote (that's easy). That means you need to be able to come up with formulas to calculate things. You'll get the math you need in any STEM program. A STEM degree also proves to me that you have the persistence and perseverance to drive on and finish when things get hard, and it will get hard. In this profession, you will be faced with challenging problems. Giving up and quitting when it gets hard is not an option. So, no STEM degree, no job.

2. Must have a passion for programming/coding
In this job, you're an "Industrial Software Engineer" first. All the other skills you might have are bonus and secondary. I'm going to want so see what you've done and what you know in programming languages. Be prepared to show projects you've worked on, languages you know or have familiarity with, even if it's stuff you've only done in your personal time. Prove to me that you love programming. It's not enough to just tell me it's something you "always wanted to do". Show me and prove it to me.

3. Must have a strong work ethic
If you're one of those that can't work a minute past 8 hours a day, 40 hours a week, then forget it!! When we're behind on projects, the expectation is that you put in some extra time (without an expectation of OT pay). This also shows that you, hopefully, love what you are doing, which ties into #2 above.

 

[James Mcquade]

For any given homework assignment or task at work, you must consider these instructions as the customers specifications.
1. read the specifications several times.
2. write down your understanding of what you read in a step by step fashion.
3. review what you wrote down and see if it makes since, modify if necessary.
4. Get with the mechanical designer and discuss the project openly and honestly. When your opinions differ in regards to an operation, discuss it, don't ignore it.
there must be a reason for a difference of opinion. modify your instructions and i/o to accommodate the mechanical design if possible. Mechanical design may have to be changed due to plc programming limitations.
YOU BOTH MUST be in agreement on all points of operation before going to step 5. you may have to modify/rewrite step 2 and 3 based on the discussion.
5. step through your notes again this time, you are the one following the instructions. In other words, you are the plc. Write down on paper the events you are doing.
For example, turn on hydraulic motor 1, write down hydraulic motor 1 on. If a sensor is needed, write that down.
6. continue through the instructions. When you turn off the motor, mark a line thru it.
7. go through your instructions with all the sensors, motor aux. contacts, outputs documented. Modify if necessary.
8. repeat step 6 until no changes are made.
9. Try to group your data words into some organized fashion. The more programs you write, the more organized you become
10. write the plc program using your notes in a step by step manner.
10A Over half way through writing the program you WILL realize a different/better way of doing something you are almost done writing
(or a new spec will require it) and you will completely rewrite it
10B It WILL happen more than once.
Note: 10A and 10B added to list. thanks Aabeck, member plctalk.net forum



11. DOCUMENT EVERYTHING!!! You may remember things today, but in 5 years and hundreds of programs later, you won't
remember, especially at 2 am, so DOCUMENT EVERYTHING. use easy to understand tags and rung comments.
12. MAINTENANCE is your best friend and your worst enemy.
if you work with them and find out what they can do, write the program where they can trouble shoot the program. they will be able to fix the problem and everyone will be happy.
BUT
if you write the program to where you are the only one who understands what is going on, maintenance can't fix the issue, the machine is down, production is down,
management hears about it, your boss hears about it, then you hear about it - rewrite the program or else. you get calls all hours of the day and night.
this still holds true, a machine can cost a billion dollars, but it's not worth 10 cents if maintenance cannot trouble shoot the issue and fix the issue.
everyone has their own style of programming and you must develop your own way as well.
13. when the customer is in your shop and brings maintenance, discuss things with them, let them see your code, be open.
if they make suggestions, write them down, don't ignore them. their ideas may save you days of programming.
14. install the program and leave in program mode if possible so you can to debug your i/o
15. when writing your instruction manual(s), use your notes from step 9. Use easy to understand English language. specify the i/o, timers, counters, outputs when possible.
this will help maintenance even more to see what is going on.
16. Question for you, when is a machine and plc the most dangerous and why?
When it’s first powered on – when power is first applied to a machine, you don’t know how things are wired.
When you energize the plc outputs, you don’t know how they are wired.
When the plc is put into run mode the first time, it will do what you told it to do, NOT what you wanted it to do.


17. debug the program.
Remember, the program will always do what you told it to do, NOT what you wanted it to do.
18. IF you can ask a what if this happens type of question, YOU MUST have an answer, EVEN IF its a 1 in a million chance. that what if situation will happen in the first 30 minutes of production runoff in front of the customer.

if anyone else has ideas, feel free to add and i will insert it into my document and give you credit.
james

 

[Frank60]

OMG! nice encouragement in entering a field that is losing more people than ever before.

 

[TheRooster]

Just got a first integrator job this year as a controls engineer.


My advice is to learn everything you can about everything you can (PLC programming: AB, Siemens, whatever else, HMIs, IO, Motors, VFDs, Servo Drives, Pumps, Sensors, the list goes on). At the same time apply everywhere you can, especially look for smaller integrators that are growing. They will be more willing to hire less experienced engineers who have high energy and work hard.


You DO NOT need a degree at all let alone a stem degree. College is a waste of time and money and only useful to convince boomers you know things. You can learn just as much as an engineering degree in two years for a twentieth the cost. When you know your stuff a good company wont care. There's tons of online training and books to read to learn the info you need.


GOOD LUCK!

 

[saultgeorge]

OMT you might want to consider--with an integrator there will more than likely be lots of travel, overnight travel. Travel for 3 weeks to an assembly plant, come home for 2-1/2 days and go back. Go to foreign countries you may not want visit. I worked at an integrator and although I didn't travel much (I had a 2-1/2 year local project which was cool) they hired a senior engineer from another company that had been to India twice in the previous 6 months and both times got sick and nearly died. Seriously.
He quit when they told him to go back a third time.
I don't like travel so I usually work in a plant and there are a lot of drawbacks to that.
Also most integrators will fully assemble whatever it is they're building in their shop and run it to the customers satisfaction. I've worked on some pretty large projects--a framing machine for GM trucks, weld cells etc. They then disassemble it and ship it to the customer for permanent install. RE: Travel.
I wish you the best. All the folks above have given you stellar advice. This forum has been a priceless help to me over the years. Good luck!!

 

[DriPLC]

Hey Guys,

Thanks for the Tips and tricks on how to land a job in the field. Happy to say I landed a automation controls eng job for a bigger comapny. This job is going to provide me exposure to more AB controls and even simens controls. Also different robots like, KUKA, yaskawa, fanuc, and ABB. Super excited to work for them and they are super excited to have someone with some background that they can build on throughout the future.

 

[jstolaruk]

12. MAINTENANCE is your best friend and your worst enemy.
if you work with them and find out what they can do, write the program where they can trouble shoot the program. they will be able to fix the problem and everyone will be happy.
BUT
if you write the program to where you are the only one who understands what is going on, maintenance can't fix the issue, the machine is down, production is down,
management hears about it, your boss hears about it, then you hear about it - rewrite the program or else. you get calls all hours of the day and night.
this still holds true, a machine can cost a billion dollars, but it's not worth 10 cents if maintenance cannot trouble shoot the issue and fix the issue.
everyone has their own style of programming and you must develop your own way as well.

This is absolutely the biggest item in the list IMO. If MAINTENANCE gets to the point they won't touch it because of frustration that its to difficult to get up and running again, its all over but the crying. Design the software the "long" way (short simple rungs, comments everywhere, diagnostic alarms/faults/warnings) for the sparky that knows just enough to find where a sensor is used, and MAINTENANCE will take ownership; you don't want those late night/early morning phone calls because they can't get the machine running.

 

[dummy_bit]

This is absolutely the biggest item in the list IMO. If MAINTENANCE gets to the point they won't touch it because of frustration that its to difficult to get up and running again, its all over but the crying. Design the software the "long" way (short simple rungs, comments everywhere, diagnostic alarms/faults/warnings) for the sparky that knows just enough to find where a sensor is used, and MAINTENANCE will take ownership; you don't want those late night/early morning phone calls because they can't get the machine running.

I second this.. Stick to ladder logic or function block for maintenance troubleshooting. When you get into more complex calculations, then go into a higher level language but with easy tag identifiers they can follow through the main logic. As much as I hate having too many alarms, it does help from getting those 2am calls. In my experience, most maintenance techs barely touch the PLC so they usually forget how to setup communication paths, go online with a controller, etc.

I definitely enjoy the engineering aspect of an integrator but HATE to travel, so I find myself at a localized manufacturing plant.

 

[cardosocea]

1. Must have a STEM degree
I don't care what specifically it is, but must be STEM. I would even accept a 2-year STEM (but preferably 4 year). A STEM degree proves to me that you've at least been through some math past grade school level. That's a must. Working for an integrator, you are going to be required to write all the code, not just simply going online with a processor and following code someone else wrote (that's easy). That means you need to be able to come up with formulas to calculate things. You'll get the math you need in any STEM program. A STEM degree also proves to me that you have the persistence and perseverance to drive on and finish when things get hard, and it will get hard. In this profession, you will be faced with challenging problems. Giving up and quitting when it gets hard is not an option. So, no STEM degree, no job.

It's an indicator, but can still trip you up. Last I hired had a STEM degree and couldn't comprehend the concept of a valve position sensor... It's definitely something worth considering, but by no means doesn it mean that the candidate is better. After all, do you have to calculate filter coefficients for a Chebyshev filter in this line of work? Or simple proportions?

2. Must have a passion for programming/coding
In this job, you're an "Industrial Software Engineer" first. All the other skills you might have are bonus and secondary. I'm going to want so see what you've done and what you know in programming languages. Be prepared to show projects you've worked on, languages you know or have familiarity with, even if it's stuff you've only done in your personal time. Prove to me that you love programming. It's not enough to just tell me it's something you "always wanted to do". Show me and prove it to me.

I guess it depends on the age of the person. I used to be in love with a lot of different kinds of programming and electronic tinkering outside of work and did a few interesting bits myself. However today I have an AOI to calculate wet bulb temperature and a script to get the lifecycle status from Rockwell's website to show for. Not really astounding, but after getting burnt out, these sorts of things fall to the side. So, although it's a good sign, it's not the greatest predictor. I'd actually go the other way and want someone that has other interests as they'll be less likely to be geeks with poor social skills when interfacing with the customer.

3. Must have a strong work ethic
If you're one of those that can't work a minute past 8 hours a day, 40 hours a week, then forget it!! When we're behind on projects, the expectation is that you put in some extra time (without an expectation of OT pay). This also shows that you, hopefully, love what you are doing, which ties into #2 above.

My life is mine and my job is a business transaction. You want more of my life? You're going to have to pay... after all, you can't just walk into McDonalds or Starbucks and demand a large adult menu after paying for a Happy Meal. Sure, I may be so engrossed that I will lose track of time, but make no mistake, you won't bank that time for the company, I'll be sure to compensate in the weeks ahead.

I would fit your requirements if I was given part ownership of the company though... is that on offer?

By the way, I'm not a child either. I'm in my forties and am quite happy that more youngsters don't put up with being ripped off by their employers.

 

[PreLC]

A few things that will be a must the next time I hire an automation/controls engineer:

1. Must have a STEM degree
I don't care what specifically it is, but must be STEM. I would even accept a 2-year STEM (but preferably 4 year). A STEM degree proves to me that you've at least been through some math past grade school level. That's a must. Working for an integrator, you are going to be required to write all the code, not just simply going online with a processor and following code someone else wrote (that's easy). That means you need to be able to come up with formulas to calculate things. You'll get the math you need in any STEM program. A STEM degree also proves to me that you have the persistence and perseverance to drive on and finish when things get hard, and it will get hard. In this profession, you will be faced with challenging problems. Giving up and quitting when it gets hard is not an option. So, no STEM degree, no job.

2. Must have a passion for programming/coding
In this job, you're an "Industrial Software Engineer" first. All the other skills you might have are bonus and secondary. I'm going to want so see what you've done and what you know in programming languages. Be prepared to show projects you've worked on, languages you know or have familiarity with, even if it's stuff you've only done in your personal time. Prove to me that you love programming. It's not enough to just tell me it's something you "always wanted to do". Show me and prove it to me.

3. Must have a strong work ethic
If you're one of those that can't work a minute past 8 hours a day, 40 hours a week, then forget it!! When we're behind on projects, the expectation is that you put in some extra time (without an expectation of OT pay). This also shows that you, hopefully, love what you are doing, which ties into #2 above.

I get these requirements, but I'm sure the culture that these requirements is coming from also creates a very high attrition. The world is a big place, our industry is very resource constraint compared to some other ones. The employees would leave(Rightfully so) if they are not afforded a decent standard of working+standard of living.

Any controls engineer can fit as at least an entry level software developer. Looking at their wages+quality of life, there is no question that it's the way to go. The people who stay are people who like accomplishing real life things, and have an organic passion for our work. If this becomes a bare minimum requirement, then the employees would probably never get there organically.