Seasoned senior controls engineers are of great value to just about any machine builder, system integrator, engineering firm or manufacturing facility, and they are harder and harder to come by lately.
Many of these facilities would be happy to hire controls personnel with even basic troubleshooting skills, with the hope that they can quickly learn what is necessary to support the machines.
With the hardware advancements in automation, the many industrial protocols and controllers in use and the complexity of machine applications increasing, should the controls engineer learn to support and program everything on the plant floor, or should he or she specialize? The answer is every controls engineer should master the basics and then pick a specialty to be efficient at because you cannot know everything.
Of course, some controls engineers will want to know everything. Your co-workers know who you are—for good and possibly bad reasons.
In a small operation, an overworked, one-man show is often all that is available. That's all good until vacation time. And, as the size of the operation or system complexity increases, several specialists, available through both internal and external sources, may be better.
However, starting at the basics, all controls engineers should understand the National Electric Code (NEC) and the computer-aided design (CAD) practices used to implement the NEC as it relates to industrial automation. The skills to create an electrical design schematic and then use it to build a control panel and troubleshoot machine power distribution, I/O devices and related electrical equipment are a must for a controls engineer.
Pneumatic circuit design skills are a must, as well. The selection, design and integration of a pneumatic air perpetrating unit, valves, fittings and actuators are just as important as the electrical skills in most machine applications.
Basic electrical and pneumatic skills are the cost of admission to the more advanced controls engineering skills, which include machine integration and program development.
Unless the same equipment is used every time, and it's often not, integration and startup can be time-consuming.
Installation manuals are often needed and the details created during design—the cheat sheets with all the information—will need to be readily available. Configuring a PLC on a small project is easy, but add 20 or more networked devices such as Ethernet I/P, fieldbus and IO-Link and it becomes complicated.
Connecting and testing the operation of multiple controllers, HMIs and field devices on multiple industrial Ethernet networks and other fieldbuses can take a lot of time.
Why not just have an integration expert do it, so the programmer can just walk up and download the PLC program with the I/O and field devices all ready to go? Their experience with configuring devices and starting up systems will speed things up. It works great and this expert is just one of many on the control team.
Ethernet network administration can also be added to the integration specialty, and this work starts at system design. Is a single control network enough, or must it be broken down into multiple networks for deterministic requirements? Field I/O, robots, motion control, vision systems and HMIs may each need to be on separate networks. Configuring the use of managed Ethernet switches is also critical for this requirement. Will the network be fast enough, or will system performance be affected?
Other team members include the PLC programmer, robot programmer and vision system programmer. On a large multi-cell machine with multiple controls engineers working on it, the work is often divided by cell, but it also should be divided by specialty.
Again, these specialties make the guru more efficient. A four-hour robot service call doesn't happen if robots are just one of the many things a controls engineer works on. Working on controllers, robots and vision systems from multiple manufacturers often dilutes an engineer’s efficiency. The work will need to be figured out again, or the brain will need to recalibrate for the new, complicated task.
When wearing many hats, just about the time the programmer becomes fluent with a particular manufacturer's robot or vision system, that same programmer works on another project with a different robot.
While there are many similarities, the new system will require at least a little review time or possibly significant training time to become fluent with the new system's software. The programmer will become fluent with the new software at the expense of training time and may lose fluency in the other programming software.
Following this same scenario, if the programmer works with different PLCs and vision systems on a regular basis, a significant amount of time may be spent recalibrating the brain.
We controls people are amazing and should be well paid, but we cannot be experts with everything. It takes time to learn it or to get back up to speed on a particular product, so consider specializing or standardizing. Less is more. Learning the secrets of advanced automation from several 300-page manuals takes time. You managers and end users out there should consider that, especially when we work our magic bringing an advanced automated machine to life.