Difference Between Robotics Technician And PLC Technician

If you’re studying towards or considering a career in industrial automation, you may be wondering about the difference between “robotics” and “automation”. Some other industrial automation words that sound suspiciously similar are “mechatronics”, “controls”, and “motion control”. Many of these terms are synonymous, or at least describe greatly overlapping domains. With that said, there is a distinction to be made between a Robotics Technician and a PLC Technician or PLC Programmer.

Recently, a reader left the following comment on our So, You Want To Be An Industrial Automation Engineer article:

Your article on Industrial Automation was very insightful. I am a manufacturing engineering technician student from London, ON. I am interested in becoming a Robotics Technician. So, I would like to know the similarities and differences of a PLC technician and a Robotics technician and what do I need to do to reach my career interest.

Eric’s Comment

Thanks for the question, Eric! It’s always awesome to hear from someone who’s getting involved in industrial automation. It’s hard work, but a lot of fun, and the opportunities to learn are endless. Let me do my best below to answer your questions.


What Do Robotics Technicians Do?

Robotics technicians generally do robot setup and programming. As far as I see it, there are three worlds to robotics:

  1. Robot setup
  2. Writing and debugging robot programs
  3. Teaching robot positions

Robot Setup

Robot setup involves getting a new robot out of the box ready to be programmed. This consists of any custom loads for your shop, IP and comm setup, etc. Sort of like getting a new device to talk on your Wi-Fi at home, but more complicated. 🙂

Someone who’s spending their time setting up robots will have to connect power and communications to the robot. You’ll need the right cables for the application. When someone says “application” in this context, they mean: the particular thing that the robot is intended to do.

For instance, if the robot is a “material handler”, its purpose is to move parts around. You would say the robot is, or has, a “material handling application”.

Material handling robots will often have end effectors with sensors and clamps. (You can read a bit about end effectors near the bottom of this article on sensors.) The robot will need power and communication cables to pass through its arm to the end effector. It will need these to provide power to the clamps and to receive feedback from the sensors. This may result in different cabling to the bottom of the robot. The person doing the setup will need to make sure they select and hook up the right cables.

Anyone working robot setup will also need to be very familiar with the robot’s setup menus. There may be a lot of little settings to change to get everything configured correctly. Additionally, you will likely need to understand the process for flashing images or firmware into the robot’s memory.

Writing And Debugging Robot Programs

Once initial setup is complete, the robot’s programming tells the robot when to go. The robot program also dictates what inputs and outputs to set along the way. Robot programming is reminiscent of high-level computer programming. Once you get involved in reading and understanding robot programs, I think it’s fairly easy to start building some skills as a programmer.

Robot programs often employ somewhat straightforward and easy-to-read logic. Usually, you’ll be evaluating some input from the PLC or the End Of Arm Tool (the “IF” condition). The robot then takes some action or sets some output as a result (the “THEN” result).

For example, a robot may enter a program and first check to see if it’s already holding a part. If it doesn’t have the part, it enters a branch of the program that sends it to the pickup location. From there, it may close its clamps (to secure the part in its grasp), and then check to see that its sensors indicate that it has a grip on the part.

If, instead, the robot already has the part, it will jump to a different branch of the program. In this branch, a different set of motion commands will move the robot to the drop-off location. Once there, it will release its clamps, then check its sensors to make sure that it no longer has the part.

If you’ve ever done any programming in BASIC, that’s what robot programming reminds me of. I’ve only ever worked with Fanuc robots, though, so other platforms may be different.

Teaching Robot Positions

Once robot programs are loaded, you have to tell the robot where to go to do its job. Different robot applications (robots that weld, robots that move parts around) require different tactics in terms of the motion necessary to accomplish the task.

For the most part, teaching robot positions is a lot of “jogging” the robot. To “jog” a robot is to drive it manually using the buttons on the teach pendant. Depending on the reference frame, these buttons either move an axis independently or move the End Of Arm Tool in one particular direction.

A Fanuc Teach Pendant. The teach pendant is used to view and control the robot's setup and programming. This image is part of an article describing the difference between robotics technician and plc technician jobs.
A Fanuc Teach Pendant. The jog buttons are the blue buttons on the right.

With that said, simply wiggling the robot around is only scratching the surface of position programming. Each position taught can be setup in a variety of different ways. Good programmers understand how the robot will move depending on the settings that they select when they teach a position. Skillful position programming can improve the performance of the robot (by reducing cycle time) and extend the life of the robot’s mechanical components.

Position programmers will also need to understand how motion is programmed for different applications. Material handler motion may be programmed differently from weld gun motion. Large, heavy robots with payloads of several hundred pounds may be taught differently than small robots that carry only a few pounds.

Are you ready to take the next step in your industrial automation career?

The Industrial Automation Connection’s goal is to help you connect with opportunities to advance yourself.

Let us put you in touch with organizations that are looking for people like you.

This service is always free, and it takes only a few moments to register. Click one of the buttons below to get started!

Being A Well-Rounded Robotics Technician

Each of these elements is a bit of a world unto itself. If you get into robotics, then depending on where you work, you may specialize in one or two of these domains. Or, maybe your shop’s policy is that you own each robot for the complete process, from setup through customer acceptance.

Robot gods – guys or gals who are really, really knowledgeable – are likely to be proficient in both setup and programming.

What About PLC Programming?

A little snippet of ladder logic. Click for full-size image

The Programmable Logic Controller, or PLC, is the brains of the operation in many modern factories and processes. PLC’s tell the robots, valves, actuators, conveyors, and other systems when it is their turn to move. For instance, the PLC will tell the robot which program it should execute:

Run your program to…

  • …pick up a part and set it down somewhere else
  • …move to a maintenance position so a cable can be repaired
  • …drop off your end effector and return home
  • …etc.

The PLC will send several bits to the robot telling it that it is safe to move and that it wants it to run a program. It will also typically send a combination of bits that represent “program select”. In other words, the PLC will send the robot a code telling it which program to run, and other bits telling it it is safe to run that program.

This is just one example of what the PLC does. The PLC is the mastermind of the operation, evaluating all of its inputs, processing those inputs according to its programming, and setting all of its outputs on every “scan”. A scan is one complete execution of all of the PLC’s programmed logic.

What Does A PLC Do?

Think about some decent-to-high-end electronics purchase you’ve made recently. For instance, consider a smart home hub.

That smart home hub comes out of the box, ready to do its job of controlling your smart home devices. In order to do so, it uses its microprocessor, which is equipped with a set of programming instructions that were loaded at the factory. If you and your friend have the same smart home hub, both hubs will have the same programming.

Now, consider an automation line in a factory. An automation line in a factory is analogous, in some ways, to a smart home hub. It accepts inputs from many sensors. It processes those inputs, and depending on the inputs it receives, turns on outputs.

In the case of the home automation hub, it might be accepting voice commands, time of day, and RF signals as inputs, and it might be setting outputs such as locking the front door, turning on a light, or closing a set of motorized blinds.

What Does This Have To Do With PLC’s?

In the case of a PLC, it might be accepting proximity sensors, motor temperatures, and operator pushbuttons as inputs, and it might be setting outputs such as telling motors to turn, flashing lights on panels, or moving an actuator to position a part.

The PLC even shares the trait of using a microprocessor to perform its functions. Where the PLC differs from the smart home hub is that whereas manufactured devices like smart home hubs all have the same programming, each PLC running an automation line or process typically has custom programming.

In other words, two automation lines that connect with each other may have the same foundational “template” of logic loaded. Even if they start out similarly, however, they will both have many small differences in their programming to reflect different processes or equipment that are used on each line.

What Do PLC Programmers Do?

It is the PLC Programmer’s job to create and maintain the logic that drives automation lines or processes. PLC programmers are generally either developing and implementing new logic, or supporting and debugging existing systems.

Developing New Logic

A ladder logic sample with FAL instructions. FAL's are very efficient, and allow you to perform operations on every index in an array with one instruction. They are, however, very hard to read when you go back through to debug your logic.
FAL’s are a powerful – but cryptic – instruction. Click for full-size image

One of the most fun aspects of PLC programming is developing new logic. You might work with ladder logic, function block diagrams, structured text, or other programming methods. Whatever you’re using to program the PLC, developing new logic allows you, as the programmer, to bring an automated process to life.

This is where your creativity and programming skills will come in. A good PLC programmer has read and debugged a lot of logic and is able to bring solutions to bear in new applications. Knowing how you or other people have solved certain problems in the past gives you a “library” of solutions to reference to overcome new problems.

A good programmer is also resourceful. If you come across a problem you haven’t solved before, it’s important to know where to look and to have other smart people you can call upon to get the information you need.

Another key skill when writing new logic for the PLC is “being able to see the logic running in your head”, as one of my PLC mentors once said to me. It’s important to learn how the various PLC programming instructions work and how they respond on their first and future scans after input conditions become true or false. Understanding how your logic will behave while you’re working offline will help your implementation to go more smoothly and minimize debug time and issues.

Maintaining And Debugging Existing Systems

The other side of the coin is maintaining and debugging existing systems. Many organizations keep PLC programmers, or “Controls Guys” (or Gals), on for the sole purpose of getting the equipment back up and running when it breaks down. If you’re in a production support role of this type, you’ll need to learn the equipment in the area and the PLC logic that drives the process.

The best-case scenario is when you get to own a process from birth and throughout its lifecycle. If you’re trying to troubleshoot something, it sure is nice to have the person that wrote the logic available on site.

If you’re going to support existing equipment, it helps to be able to work well under pressure. Managers will be standing around tapping their feet and looking at you to get the equipment running. You’ll need to keep a cool head and work through the issue to get the line moving.

Other Functions Of A PLC Programmer Or Automation Engineer

There can be a lot more to it than the ladder logic (or other programming method). For instance, the PLC is the ultimate controller for the process, and thus many devices will need to be setup within the PLC software so that the PLC can talk to them. This may require you to obtain specific configuration values from the device’s manufacturer, or to load an EDS for the device. An EDS is a file that helps the PLC understand how to talk to a certain type of device.

Further, PLC Programmers (or Controls Engineers, etc.) often setup and maintain software and backups for any drives that are part of the system. Modern factories commonly employ Variable Frequency Drives, or VFD’s, to control motors. VFD’s allow you to set motor speed dynamically through the logic. This programmatic control enables the programmer to set up high and low speed settings, sync up speeds between neighboring motors, and more.

Another area of responsibility for PLC programmers is HMI development. The Human-Machine Interface, or HMI, is typically an LCD or touchscreen interface through which operators can control the system. As a PLC programmer, you may find yourself designing and debugging custom HMI screens to support your process. A well-designed HMI will provide users with:

  • Information they need to understand what’s going on in the process
  • Buttons and other input methods that allow them to control the process
An example of a  Human-Machine Interface screen. This is an example of something a PLC programmer might have to design. This image was used to illustrate some of the differences between PLC technicians and robot technicians.
An HMI interface for a pump. Image credit. Click for full-size image

Similarities Between Robotics Technician And PLC Technician Positions

Now that we’ve covered many of the differences between robotics and PLC technician roles, let’s discuss some of the similarities.

Programming Skills

To start with the obvious, both roles require you to be a decent programmer. You’ll need to have the patience and curiosity to learn the basic syntax and instructions with which the equipment is programmed. As you are exposed to new situations, it helps to remember programming solutions you’ve used or seen in the past. You never know when you might want to reuse something in the future to overcome a similar challenge.

Programmers working in the industrial automation field must take care in what they do. A single bit in the wrong state or a single number in the wrong register can bring your process to a halt, or worse – cause a robot or other equipment crash. You’ll need to be careful and pay attention to detail as you program and debug your logic.

Troubleshooting Skills

Another aspect of working as either a Robotics Technician or PLC Technician is troubleshooting. Troubleshooting is the process of identifying and correcting a problem to get equipment working.

To be a good troubleshooter, you need to learn your automation and the equipment and software that you’ll use to get the job done. If my factory uses Rockwell Automation PLC’s, for instance, I’ll need to be familiar with RSLogix 5000 and how to use it to quickly debug any issues. In a facility that employs Kawasaki robots, I’ll need to know my way around the Kawasaki pendant and understand generally how the robot functions. If I’m supporting a line with automated weld processes, I’ll need to become familiar with the weld equipment and controller.

Depending on the process, this most likely means you’ll need a good mechanical or electrical background. When you have knowledge of how equipment and components are supposed to work, it can help you to understand why they’re not working. Many PLC and robot programmers first work as industrial electricians or automation technicians. A strong electrical background can be very helpful in figuring out what’s going wrong in your process.

People Skills

Believe it or not, you still need to have decent people skills as a programmer. You’ll need to keep people informed of the work you have going on and often solicit their help in getting the job done. Managers and supervisors will need you to get a task accomplished or to get equipment back up and running, and you’ll need to be able to set expectations appropriately.

Salary Comparison Between PLC Technicians And Robot Technicians

The good news is that both pay pretty decently and both are very comparable. As you’ll see below, there appears to be a wide range of potential salaries within these fields, and I’m sure it depends greatly on the location, years of experience, and contract status. Here are some aggregated salary numbers from some reputable sites:

Robotics TechnicianPLC Technician

How To Get A Job As A Robot Programmer Or PLC Programmer

Within the field of industrial automation, I think there’s a bit of a chicken-and-the-egg thing with breaking into a programming job. This is something that I think is similar between robotics technicians and PLC technicians. When it comes to hiring into these fields, my personal perception is that employers would prefer experience to education.

What I mean to say is that for a technician position, an employer may be likely to choose a robot programmer with 4 years of pendant time over an Electrical Engineer with 4 years of education. The same may or may not be true for an engineering position.

I’m not trying to downplay education, which I think is important regardless of the position held. Experience, however, is a critical element when working with highly specialized platforms like robots and PLC’s.

The Importance Of Hands-On Experience

If you’re looking to get into the industry as a Robotics Technician or PLC Technician, hands-on time is very important to employers. I believe an employer would very strongly consider a candidate for either a technician or engineering position if the candidate had several years of relevant experience doing PLC or robotics work – even if that candidate didn’t have a degree.

I think that employers may even prefer experience over education for certain engineering positions. Because PLC and robotics work requires very specialized skills and knowledge, you just can’t trade time at the terminal or on the pendant. Becoming a proficient PLC programmer using Rockwell Automation’s RSLogix 5000, for instance, can be a life-long pursuit.

Please note that this is just my personal take on it; I’m sure every employer has different policies and expectations.

What If I Don’t Have Any Experience, Yet?

This is where the chicken-and-the-egg thing comes into play. If you’re trying to get your foot in the door somewhere to try to build that foundational experience with PLC’s or robotics, I’d say there are two common paths:

  • Earn a two-year (or even four-year) degree in a field like Mechatronics, Industrial Automation, Electrical Engineering, etc. This will help you to get an interview and hire on as a technician
  • With experience in a related field, get a position where you can start dabbling in PLC programming or robotics so that you can qualify for a more focused position later

A Couple Of Examples

I’ll give you two examples:

  • I know a very talented PLC programmer who works as a Controls Engineer
    • He got a two-year degree in Mechatronics and then worked for an automotive manufacturer as an Industrial Electrician. He transitioned into another Industrial Electrician position with another automotive manufacturer
    • His two-year degree plus the experience he’d built doing PLC debug along the way allowed him to interview for (and be offered) a position as a Controls Engineer
  • I know another very talented PLC programmer who works as an Industrial Electrician. Although Industrial Electricians perform a wide range of tasks within my facility, he is primarily doing PLC programming and troubleshooting
    • He worked as an Industrial Electrician at a government facility. During that time, he made sure to learn as much as he could about PLC’s, drives, and electrical troubleshooting. After several years, he hired on at my facility
    • He has the same job title as others at my facility who are doing less technical work. Because of his knowledge and experience, however, he has been able to specialize in PLC programming. His supervisor has identified him as a Subject Matter Expert for PLC’s and drives, and he primarily works as a PLC programmer and troubleshooter

Additional Information On The Differences Between PLC Technicians and Robotics Technicians

I hope that this article has given you a bit of perspective on the difference between PLC technician and robotics technician jobs in the field of industrial automation. If this was helpful for you, make sure to sign up for our email list below:

Once you’re on the list, we’ll keep you posted whenever we have something new for you related to industrial automation.

Further Reading

For further reading on the differences between robotics technician and plc programmer roles, here are some other resources from around the web:

5 Ways To Know If You Should Be A PLC Programmer

Are you considering a career in PLC programming? Awesome! Learning how to program PLC’s (and how to debug under pressure) is an incredibly fun and rewarding experience. Maybe you’ve been considering attending a tech school, or have been talking to a friend who is a licensed electrician or who works for an automation integrator. Maybe you’ve developed an interest in industrial automation on your own and want to know more about becoming a controls engineer or PLC programmer.

Where are you in your journey? We want to hear from you in the comments!

Are you ready to take the next step in your industrial automation career?

The Industrial Automation Connection’s goal is to help you connect with opportunities to advance yourself.

Let us put you in touch with organizations that are looking for people like you.

This service is always free, and it takes only a few moments to register. Click one of the buttons below to get started!


Should You Become A PLC Programmer?

Whatever your background and level of interest, here are five suggestions for what might make PLC programming the right job for you!

1. You Think Automation Is Cool

But, I mean, who doesn’t, right? If the thought of setting up new systems, developing algorithms and sequences of operation, and programming robots and Programmable Logic Controllers sounds like it’s up your alley, then why not go for it?

Not everyone gets to do what they love, but if you have a true interest in automation, becoming a PLC programmer will allow you to learn how to establish and control automated processes. What could be cooler than that?!

An automated assembly line where orange Kuka robots are performing a joining operation on an automotive body as it proceeds down the assembly line.
How could you not think automated manufacturing is cool?

2. You Love To Learn

Being a good programmer means treating every situation as an opportunity to learn more about the PLC, the programming template, the production line, and the equipment you’re controlling.  As the “controller of the controller,” if you will, it’s not enough to be knowledgeable about just programming. The whole point of the PLC is to accept inputs and set outputs to and from alllllll the many field devices – conveyors, robots, I/O blocks, fixtures, actuators, sensors, servos, … , the list goes on forever.

Industrial automation is home to a thriving ecosystem of devices, equipment, and communications protocols. For instance, every imaginable flavor of communication can be found out there, from modern 10/100 (and faster) Ethernet to 9600 baud serial connections. As someone who designs and debugs PLC logic, you will need to work to grow your understanding at every layer of your production equipment. 

With so many different systems to learn, you must strive to build your knowledge of everything in the plant.  From physical cabling to vendor-specific camera solutions used on your vision systems, eventually, it’s going to break! When it does, people will be looking to you to come up with solutions to highly technical issues.

Long story short, as an industrial electrician, electrical engineer, or anyone else who does PLC programming, you should be learning something new every day. Don’t worry – what you don’t learn on your own, the breakdowns will teach you.  😀

3. You Love Solving Puzzles

Often times, as an automation engineer, you will find recurring issues with the equipment that no one knows how to fix.  As such, it will be your job to figure out what’s wrong.


  • … a bug in the original programming is allowing 1 in every 100 units to go through without a certain part being installed
  • … ten times a day a certain fault occurs and stops production, and there doesn’t seem to be any discernible pattern as to what’s causing the issue
  • … you’re having trouble with a complicated sequence of events that occurs within milliseconds
  • … you have to debug an exchange of data between two PLC’s that takes place over your industrial network

As a PLC or robotics programmer or engineer, people will often look to you to “deep dive” the tough, troublesome, technical issues that evade understanding. When you are working in that role, it’s likely that you will be presented with difficult troubleshooting situations that will require a deep understanding of the equipment and technology in question.

A 2x2 Rubik's Cube showing an orange, yellow, and blue face
A 2×2 Rubik’s Cube is more my speed

4. You Work Well In Challenging Situations

The first rule of PLC programming is: all logic requires debug. Whether you’re setting up a new process or troubleshooting an issue with an existing system, as a “controls guy” (or “controls gal” 🙂 ), people will be looking to you to get the equipment working again.

You know what they say – no guts, no glory. When the equipment isn’t working, excellent programmers or controls engineers are able to enter challenging situations with a cool head.  Once you’ve quickly gained an understanding of the problem, it’s time to work with your teammates to determine and correct the issue.

Adept PLC programmers who work in production (manufacturing) environments will likely be called to the toughest breakdowns. As your skills and knowledge grow, you will become more and more comfortable working in tense, time-sensitive situations. Wherever you are in your journey, the key is to always strive to learn more.

5. You Love To Think Creatively, Logically, And Analytically

Lastly, PLC programmers need to be able to:

  • Analyze a situation or a problem to be solved
  • Think of a possible solution
  • Come up with a way to turn that solution into logic
  • Then, write that logic and debug, debug, debug!

When you’re striving to make equipment run, it’s sometimes easy to get tunnel vision and hone in on one possible solution.  As such, PLC programmers need to be aware of the logic and the equipment with which they’re working, so they can pull the right programming “tool” out of their “tool bag” and put it to work to solve the problem.  Sometimes, you have to step back and think, “is this the only way I could attack this issue, or could there be an easier way?”  This may be the best way to jar yourself out of the tunnel and start thinking creatively. 

What Do You Think?

Do you fit the bill? Tell us what you think in the comments below! We want to know where you’re at in your own journey towards becoming a world-class PLC programmer.

If you want to know more about PLC programming and industrial automation, take just a moment to sign up for our newsletter. You’ll receive only a few emails a month, at most. 🙂

Thanks for reading!

What is a PLC?

If you’re considering a career in Industrial Automation, you are probably starting to hear a lot about PLC’s. If you haven’t worked with PLC’s before, they might seem a bit mysterious; you might be wondering what a PLC is, exactly. Let’s shed some light on the topic for you below.

What exactly is a PLC? A PLC, or Programmable Logic Controller, is a computer that is used for processing inputs and setting outputs. When I say “computer” in this context, I don’t mean what we typically think of when someone says “computer” – although a PC can function as a PLC with the right software.

A PLC is (typically) a computer in the more general sense – it is a microprocessor that is connected either directly or via an industrial network to some inputs and outputs, and it is programmed to evaluate the inputs and set the outputs in such a way that it facilitates the execution of some process. In other words, it is a processor, similar to the one in your computer, that adheres on a very basic level to the “IPO Model“: it accepts inputs, performs processing, and sets outputs.


Try to think of it this way – a factory is, in a sense, a giant machine that takes in a lot of parts and turns those parts into some product or family of products. Within the factory, there are some number of automated production lines, with each line performing some process on the parts.

On some lines, robots may move parts around so that other robots can weld them together. Some lines may have stations where operators use special equipment to install fasteners in each part before it moves to the next station. Some lines may simply convey parts to another area of the facility. In any of these cases, think of individual automation lines as large machines themselves; they perform some custom function within the factory to contribute to the assembly of the final product. Generally, they turn some combination of parts into a larger sub-assembly.

Are you ready to take the next step in your industrial automation career?

The Industrial Automation Connection’s goal is to help you connect with opportunities to advance yourself.

Let us put you in touch with organizations that are looking for people like you.

This service is always free, and it takes only a few moments to register. Click one of the buttons below to get started!

PLC’s run the show

PLC’s are the brains of these machines, much like your car’s ECM is its brain. In fact, in many regards, an ECM is to a car as a PLC is to an automation line in a factory – an ECM is, effectively, a PLC for your car.

  • An ECM accepts inputs from the vehicle, such as:
    • Crankshaft position
    • Oxygen sensor feedback
    • Intake airflow
  • The ECM then performs calculations using the input data, to provide appropriate outputs:
    • Injector duty cycle
    • Throttle control
    • Valve control
An Engine Control Module, or ECM, from a Volvo.
Vroom, vroom. Image credit.

I guess the list above is most relatable if you have a bit of automotive knowledge. Here’s another comparison that might be more broadly intuitive:

  • A home automation hub accepts inputs from sensors in your home, such as:
    • Motion sensors
    • Smart buttons
    • Voice input
  • The home automation hub processes those inputs in accordance with how you have it set up, and then provides appropriate outputs:
    • Turning lights on and off
    • Playing music
    • Closing the garage door

While both comparisons are reasonable, there is one manner in which both examples are significantly different from PLC’s:

ECM’s and home automation hubs come pre-programmed from the manufacturer. Their programming is pre-determined and, while there may be features that you can set up or configure at the user level, the code that the processors are executing is generally not editable.

PLC’s, on the other hand, are blank slates – they are putty in your hands, so to speak, for you to program however you need, in order to control your automated processes.

What do you need to have to be able to program a PLC?

In order for a PLC to do the incredible job of controlling equipment, you must provide it with the programming instructions, or “logic”, that brings your process to life. As a broad statement, you will need the following to connect to and program a PLC:

  • The PLC, with its power supply and any necessary accessories
  • A PC or programming terminal with the PLC vendor’s software
  • A means of communication between the terminal and PLC

Varieties of PLC’s

PLC’s come in all shapes and flavors, from this relatively affordable Electrodepot PLC to this Siemens PLC that can cost a few thousand dollars – which is the refurbished price, by the way. This Siemens NCU is just one example of a high-end PLC – as far as pricing for the cream of the crop, a few thousand isn’t even the upper bound.

There are many, many categories in which PLC’s can differ, but here are some noteworthy parameters:

  • Physical type (stand-alone, modular, or rack-mounted)
    • What are the PLC’s capabilities for expansion?
    • What types of accessories are available in this PLC’s product family?
  • Number of inputs and outputs accepted
  • Protocols supported
    • Does the PLC only accept “discrete” (wired) I/O?
    • Does the PLC support advanced fieldbus protocols like DeviceNet, Profibus, or Ethernet/IP?

PLC Software

Vendor-specific software is an important consideration when choosing a PLC platform, if for no other reason than differences in price:

  • Some vendors include their PLC software at no additional cost
  • Allen Bradley/Rockwell Automation PLC’s, on the other hand, require licensing to use their software – to the tune of $1,000’s for an annual license
An example of ladder logic depicted within RSLogix 5000, PLC programming software for Rockwell Automation equipment.
Rockwell Automation’s RSLogix 5000

Communicating with the PLC

Just as there are many different types of PLC’s, communicating with the PLC can mean many different things depending on what PLC you’re using:

  • Some PLC’s have programming ports that you can hook up to via a USB cable
  • Some require proprietary (read: expensive) programming cords that are vendor-specific
  • Many modern PLC’s can be programmed via an industrial network; like your router at home, you can connect to the PLC over Ethernet cabling.

What language is used for PLC programming?

Trick question? There are multiple languages that are used for PLC programming, but the most common is “ladder logic”, the technical nomenclature for which is actually “Ladder Diagram”. Two other common PLC programming methods are Function Block (or Function Block Diagram) and Structured Text.

Ladder Logic

Shown in the image above), ladder logic is the most common PLC programming method. Ladder logic is highly visual, and shows the truth of each instruction via visual indicators on the programming interface. Once you learn the meaning of a small group of instructions, you’ll be able to start reading and understanding simple bits of ladder logic.

The “ladder” in ladder logic comes from the appearance of the visual interface. Reminiscent of relay systems, ladder logic shows “energized” vertical bars on the left and right side of the screen, with each line of logic represented as a literal horizontal line – or “rung” – extending between the two vertical bars. Multiple “rungs” on the screen are visually similar to a ladder, hence the name.

Despite the high-level, visually simple nature of ladder logic, modern interfaces are extremely powerful and permit essentially any function of the PLC to be leveraged.

An example of ladder logic shown in RSLogix 5000, PLC programming software for Rockwell Automation PLC's.
Ladder logic. Instructions that are true are highlighted green. If enough true instructions on a rung form a path from the left of the screen to the right, the output on the right side of the rung will be turned on by the PLC.

Function Block Diagram

Function Block Diagram, or Function Block, is another visually representative programming interface. With function block, instructions are laid out like landmarks on a map, with inputs and outputs from each instruction branching out like roads to connect to other instructions. Function block can help to visualize a process and its inputs and outputs.

Many of the basic building blocks of ladder logic are available when using function block. These basic functions include comparative operators (equal to, greater than, etc.), counters (increment or decrement a count whenever X occurs), timers, and many more.

Like many ladder logic interfaces, you can develop your own instructions in function block. Creating custom functions allows you to reuse logic when applicable to multiple devices or programming contexts.

An example of Function Block logic.
A small example of Function Block. Image Credit.

Structured Text

A third method of PLC programming is Structured Text. For those familiar with computer programming, structured text will seem very familiar. Similar to high-level programming languages such as BASIC, structured text allows the user to write code to control the PLC.

In the PLC world, it’s important to consider how much trouble it will be for other people to deal with your logic when something isn’t working. Because structured text is less visual than either ladder logic or function block, it may not be as readily accessible to technicians who don’t have experience with the type of computer programming of which structured text is reminiscent.

No logic is immune from future debug when the equipment fails. As such, you want your PLC programming to be easy for others to read and understand. For this reason, I prefer a more visual interface than that offered by structured text, if only to make my logic accessible to a larger portion of the people who might have to debug it.

How can I learn more about PLC’s?

Three ideas come to mind for how you can start learning more about PLC programming:

  1. Attend formal training for PLC programming
    • Colleges offer degree programs such as Industrial Automation and Mechatronics that provide formal training in PLC programming
    • Certain skilled trades apprenticeships (including many electrician apprenticeships) will also require formal study of PLC programming
  2. Find PLC programmers in your network, on LinkedIn, or in other forums who may be willing to tell you a bit about the industry and what to expect
  3. Buy your own PLC and start experimenting to build your skills
    1. Get yourself an inexpensive Arduino starter kit and start building projects that will help you understand the Input, Process, Output Model
      • Arduino is not technically considered a PLC, but, basically, it’s an entry-level PLC
      • One drawback with Arduino is that you won’t be using ladder logic; it’s programmed with C
      • Many of the other experiences with Arduino will be identical or directly analogous to PLC programming
        • You will set up inputs such as sensors and switches
        • You will write logic that will handle or take action based on the inputs
        • Your logic will set outputs to turn on lights, activate motors, etc.
      • Another nice thing about this kit is that it comes with a slew of sensors, lights, resistors, etc., and a project guide
    2. If you have the money, fork over the dough for something like the Electro Depot or EZRack PLC starter kits
      • These kits will provide a very realistic experience, using their vendor-specific software to program in ladder logic
      • Both of these kits have simulation functions, allowing you to experiment with your logic without needing a ton of extra equipment
An Arduino Uno, a programmable controller used for prototyping and learning more about programming controls.
(aftermarket) Arduino Uno

Tell Us About It

We hope the information above will help you in understanding some of the basics regarding PLC’s. Where are you at in your own journey? Are you considering a career in industrial automation or specifically as a PLC programmer? Let us know in the comments.

What Is An Automated Systems Integrator?

If you’ve become involved in the world of industrial automation, you may have heard the terms “integrator,” “automation integrator,” or “automated systems integrator.” The term “systems integrator” exists in both the fields of industrial automation and information systems. There are some blurred lines between those fields, as both involve networking, computers, and programming. In this article, we’ll go over the concept of automated systems integration within the fields of industrial automation and manufacturing.

Working to begin or advance your career?

Our goal is to get you in touch with organizations that are interested in your success.

Let us help you find opportunities for employment and education in your area.

We’ll never charge for this service. Click one of the buttons below to get started; registration only takes a few moments!

What Is An Automation Integrator?

Let’s say you’ve just opened a new business. You want to manufacture pencils.

Several colored pencils.

Your company has a solid business plan, funding, a building, your management team, and employees. You know the colors that you want to manufacture and even how you want to market your products. There’s just one little problem… You don’t know anything about how to actually manufacture pencils. That is where a systems integrator comes in.

An integrator is a company that specializes in bringing systems, equipment, and machinery together to create a manufacturing solution. Thus, an integrator “integrates” whatever types of equipment and controls are required to turn separate machines into an assembly line (or other automated solution). The machines that are integrated may or may not be designed to work together easily. To do the job, the integrator must overcome any technical challenges to build a complete solution.

In this sense, an integrator transforms unrelated machinery and electronics into a factory. You can think of a factory as a sort of monstrous Rube Goldberg machine that converts raw materials into marketable products.

A view of the Frame line in the Tesla Model S factory. Many robots can be seen working on or prepared to work on the frame of the vehicle as it travels down a conveyor system in the center of the automation line. It's likely that Tesla designed this assembly line and then commissioned an automated systems integrator to purchase, setup, and program the manufacturing equipment.
The Tesla Model S Framer

What Kinds of Equipment Does An Automated Systems Integrator Have to Bring Together?

Consider everything going on in the image above (view full size here).

Conveyor Systems

Conveyor Beds

The red and grey assemblies in the center of the image are “conveyor beds.” Conveyors are custom-built fixtures that transport units to each “station” on the assembly line. Integrators fabricate the frames of the conveyor beds from stock steel. Industrial motors and roller systems built into the conveyor do the job of getting the units to physically move down the line.

This is just one example of a conveyance system. Conveyance comes in all shapes and sizes, depending on what is being manufactured. The conveyor beds shown above likely weigh around a ton. At the other end of the spectrum, you have smaller components like circuit boards. Conveyor systems of this size weigh only a few pounds.


The production units themselves ride through the conveyor system on “pallets.” Like a conveyor bed, a pallet is custom-built to hold and carry each unit down the line. Pallets ride through the automation, passing from conveyor bed to conveyor bed.

Additionally, pallets are built to precise tolerances. When a unit arrives in a station, the robots will need to do their work in as close to the exact same physical location on the unit each time. For this reason, pallets must all be almost exactly the same, so that each unit will sit in a very specific position at each station.

Pallets hold each unit in place with carefully sized pins, or by other mechanical means. This helps to ensure proper positioning. In industrial automation, “repeatability” is the name of the game. Repeatability is the idea that, in automation, the same exact thing should happen in the same exact place every time.

Systems Integrator Roles

What is an automated systems integrator responsible for in regards to conveyance? Integrators will likely build, position, level, and program the conveyor systems. Systems integrators must take great care in many details to ensure that the conveyors will run smoothly. As examples, beds must be precisely assembled and leveled, and many parameters must be programmed into each motor and drive system.


You can see many robots in the image above. Each robot is ready to go in and work on the next vehicle.

How does each robot know where to go to do its job? Integrators must carefully plan, teach, and test motion for each robot. Also, each robot must be programmed to control and receive feedback from its End Of Arm Tool, or “EOAT”.

The robot is just a means of moving the EOAT to where it needs to be. What is an EOAT? The EOAT is what actually gets the work done in a robotic factory. There are many different types of End Of Arm Tools. Some examples include:

  • Material Handlers: move parts from one place to another
  • Machine Vision: records data, locates parts, or provides error-prevention
  • Joining: welders, riveters, or other equipment that fastens parts together

The robots above look like they’re carrying weld guns. Weld guns are used to “spot weld” the frame of the vehicle together. Welders work by touching the top and bottom of a part of the vehicle. Then, they pass a high current from one side of the gun to the other. The heat generated by this current flow welds the metal of the vehicle together.

For this reason, each weld gun needs a weld controller. Each weld controller has to be setup to output a certain amount of power. Further, this power setting has to be carefully tested to ensure that the gun generates the right amount of heat to form a good weld.

Safety, Sensors, Feedback, And Motion

  • Gates, fencing, light curtains, E-Stop buttons, and other safety devices exist throughout the automation equipment to protect the people that work in the area
  • Also, sensors, switches, operator buttons, and other input devices inform the PLC on the status and position of various equipment
  • Lights, buzzers, displays, valves, motors, actuators, and other output devices move parts and help humans understand what the equipment is doing

Imagine the variety of these components present on a large automation line. There may be several sensors on one machine. Further, each sensor may work differently and come from a different manufacturer. An automated systems integrator must be able to install and configure all of these many, many different industrial automation devices.

Programmable Logic Controllers (PLC’s)

A “PLC” (Programmable Logic Controller) is the brains of the operation. PLC’s accept inputs from the equipment and sensors. The PLC then performs processing, and sets outputs based on its programming. These outputs then control the actions that take place in the automation.

For example, an air supply line has an analog pressure sensor. Our pressure sensor sends a signal to the PLC that represents the pressure read at the sensor. The PLC has been programmed to interpret the signal sent from the sensor. In the PLC’s logic, the signal’s value is converted back to a pressure reading.

Then, integrators have programmed the PLC to check this pressure reading against a minimum pressure. If the pressure reading is lower than the minimum pressure, the PLC turns on a pump. In this case, the PLC sets outputs to the pump that command it to turn on. This is an example of how integrators might program a PLC to manage air pressure in a supply line.

PLC’s must be carefully programmed for each application. This programming must take into consideration concerns for safety, quality, efficiency, ease of use, and repair.

Human-Machine Interfaces (HMI’s)

To allow operators to interact with the machinery without having to know how to program a PLC, there needs to be one or more “HMI” (Human-Machine Interface) panels. An HMI is a programmable display; it’s basically a fancy computer monitor. Using an HMI, someone can interact with the PLC through buttons and other input devices on the screen. Many modern HMI’s are rugged touchscreen interfaces, built to withstand the industrial environment.

An example of a custom Human-Machine Interface screen. This screen shows several feedback and control points for a well control system. HMI's are an example of what an automated systems integrator might be responsible for.
An example of a custom HMI screen used to control a well

What Jobs Are Available In Automated Systems Integration?

Often, a manufacturer will approach a systems integration company with a system it wants built. The integrator then designs and builds a complete automation solution that will assemble the manufacturer’s product. Building an automation line from scratch requires a variety of skills and talents.

  • Managers oversee the business side of the operation
  • Mechanical Engineers, Electrical Engineers, Automation Engineers, and engineers from other specialties will design the systems. Engineers will ensure that the equipment and programming meets the customer’s specifications and any appropriate codes and regulations. In this regard, engineers must dig into the little details to understand, for instance, what type of sensor will fit a particular application. Engineers may perform PLC programming, HMI design, and development of “templates” of logic for use in the PLC and robotics
  • Millwrights cut and weld large assemblies, operate lifting equipment, and fasten components to the building’s structure. Also, millwrights are often responsible for servicing and repairing large motors, gearboxes, and other heavy-duty mechanical devices
  • Toolmakers fabricate detailed components to tight tolerances
  • Robot Technicians set up and program robotic systems
  • Similarly, PLC Technicians set up and program the controllers
  • Industrial Electricians wire and install a wide range of electrical components, and may also program PLC’s, robots, and other electronic controllers

These are the core positions that automation integration shops employ. That is, at least in terms of building the automated systems. There may also be any number of other administrative positions in marketing, sales, finance, and other fields. On the technical side of the house, integrators may also employ Software Engineers, IT Technicians, and Facilities Engineers.

What Is It Like Working For An Automated Systems Integrator?

A typical work flow for an integration project might be as follows:

  • Firstly, project planning and materials acquisition
  • Machine assembly and programming at the integration facility
  • Transportation to the customer
  • Once on-site, machine installation, debug, and trials at the customer facility
  • On-site support as the customer takes on ownership of the equipment
  • Lastly, project wrap-up

Work Life As An Automation Integrator

Given that many integration projects consist of building an automated assembly line from scratch, integration work often occurs at the customer location. Depending on the size of the integration shop and the size of the project to which you’re assigned, very high travel percentages may be required. In other words, automated systems integrators may spend as much as 90-100% of their time away from home.

Customers who have purchased large or complicated automation solutions may require support well in to the launch of the project. Because of this, on-site support requirements can range from days to years. If you are a competent member of the team or have done a lot of the programming on a certain line, the company may ask you to stay on the road for months. In this case, many companies allow for you to travel home every couple of weeks.

Providing support for the customer can be stressful. The automation equipment that your company has built is what the customer uses to make money. For this reason, they may not be very happy when it breaks down.

On the other hand, you may be able to land a design or commissioning position that does not require any travel. Those performing “machine assembly” at the shop may be able to enjoy a similar lifestyle to other 9-to-5 positions. Even so, many shops will have “surges” in the pace of work. There may be slow periods followed by stretches where your boss wants you working overtime every day of the week.

Pay And Benefits For Automation Integrators

The good news is that many integration shops offer very competitive wages and benefits. While on the road, many shops pay both overtime and “Per Diem.” Per Diem is extra money the integration shop will pay you for each day away from home. This additional pay covers food and other costs.

There can be other perks of travelling. For example, opportunities to visit new places, work in cool facilities, and network with other professionals. When I have had to travel for automation work, I have generally been put up at nice or at least decent hotels and had dinner out on the company dime.

Whether or not you’re travelling, you may have the ability to participate in training and continuing education so that you can continue to grow technically. Not to mention, you’re building industrial automation equipment! If you’re a person who enjoys working with automation, it’s hard to find a more interesting or challenging job.

What Should I Study If I Want to Work For an Integrator?

Of course, the answer to this question depends on what type of position you’re pursuing.

  • For a position as a skilled tradesperson (millwright, toolmaker, electrician), see if you can land an internship
    • In certain areas, certificate or Associate’s programs may be available to help you get a job as a skilled tradesperson
  • For engineering, complete a Bachelor’s degree in the field of your choice (Electrical Engineering, Mechanical Engineering, etc.)
    • Automated systems integrators may also hire persons with degrees in Industrial Automation or Mechatronics
  • If you want to work as a PLC or robotics technician, you may be able to complete a local or online training program to help get your foot in the door
    • Industrial electricians with PLC or robot experience should be qualified for this type of position

In Summary

Integrators make magic happen – they turn disparate systems into one large, cohesive “machine.”  From custom assembly of heavy, metal fixtures, to robot and controller programming, an integration shop has to be able to do it all.

Are you aspiring to work for an integrator, or would you like to relate your own work experience in integration? If so, share your story in the comments below!

If you enjoyed this article, make sure you don’t miss out on future content! Take a moment to sign up below. You can expect about 1-4 emails per month with the type of content you’ve read in this article.

Thanks for reading! Feel free to reach out in the comments below with any questions or comments.

User-Defined Data Types in RSLogix 5000

If you’re starting to dive into the world of User-Defined Data Types (UDT’s) within RSLogix 5000, have no fear. UDT’s are an extremely useful way to package your data and keep your tag list manageable.  Here are some of the things that UDT’s can do for you:

  • Consolidate many related data points into one tag
  • Allow you to share related data over the network with a single explicit Message instruction or Produced/Consumed relationship
  • Simplify and standardize your logic if you are adding more than one of the same device
  • Keep your tag list neat and organized
  • Slightly improve memory storage efficiency

There are a lot of big pluses to using User-Defined Data Types in RSLogix 5000. For the most part, UDT’s are easy to use, as well.  Let’s take a closer look.

Are you ready to take the next step in your industrial automation career?

The Industrial Automation Connection’s goal is to help you connect with opportunities to advance yourself.

Let us put you in touch with organizations that are looking for people like you.

This service is always free, and it takes only a few moments to register. Click one of the buttons below to get started!


What is a User-Defined Data Type?

In RSLogix 5000, User-Defined Data Types are data structures that are defined by the programmer.  For anyone familiar with computer programming, establishing a UDT is a bit like building the fields of a class. When you create a UDT, you are establishing the data points that relate to some object or operation. UDT’s can integrate atomic data types, native structures such as CONTROL and TIMER tags, and even other UDT’s.

Let’s imagine that the ceiling fan in your living room is a device on your industrial network. You want to establish a User-Defined Data Type on your PLC to help organize the logic and data that you’ll use to control the fan.

This ceiling fan has a light kit attached; the fan has a 3-speed motor, and the lights can be dimmed.  The fan has the following inputs, which accept the following data types and values:

Fan InputData TypeMin ValueMax Value
Fan On CommandBOOL01
Light On CommandBOOL01
Set Fan SpeedDINT03
Set BrightnessDINT0255

Additionally, the fan has the following outputs:

Fan OutputData TypeMin ValueMax Value
Motor ReadyBOOL01
Fan On StatusBOOL01
Light On StatusBOOL01
Fan Speed SettingDINT03
Brightness SettingDINT0255

True To Life?

While this is a fictional example, it’s somewhat true to what you might see with a typical field device. The outputs let you know the settings at which the device is operating, as controlled by the inputs.

Additionally, the fan outputs a couple of status bits, which can tell the PLC if there is a problem.  In your logic, it may be useful to check for Communications Ok and Motor Ready bits. Before attempting to operate the fan, you would check that these bits are high. Bits like these indicate that the device is communicating with the processor and is ready to operate.

Status bits of this type are common and are typically programmed at the firmware level by the device’s manufacturer. As a result, you’re often at the mercy of the device manufacturer in regards to how much help a particular status will be in regards to finding the root cause of a problem.

Creating User-Defined Data Types In RSLogix 5000

Making new User-Defined Data Types (UDT) in RSLogix 5000 is easy.  While there are a few limitations you’ll run in to here and there, I think that once you start working with them, you’ll find it simple to use this powerful feature.

To create a new UDT in RSLogix 5000:

  • Open the Controller Organizer Window, or “COW”
The Controller Organizer Window in RSLogix 5000.
The Controller Organizer Window (COW).
  • If it’s collapsed, expand Data Types by clicking the +.  Right-click on User-Defined
The context menu that pops up when you right-click on User-Defined within Data Types in RSLogix 5000.
The User-Defined context menu.
  • Click New Data Type…

Setting Up Your New UDT

And you’re off!  The first thing to do is name your UDT.  When you do so, make sure to follow any standards that your organization has set in regards to naming conventions, or consider creating your own conventions if you’re working independently.  Here is the general format that my organization uses:


For this application, let’s establish one UDT for the outputs and one UDT for the inputs. A quick note here:  Earlier, I described the “fan inputs” and “fan outputs.” Now, we’re looking at things from the opposite perspective. In other words, the fan’s inputs will be connected to PLC outputs, and the fan’s outputs will be connected to PLC inputs. So, as you’ll see below, the “FanIn” UDT we’ll create will correlate with the “Fan Outputs” table you see above.

Given my organization’s naming standards, I’m inclined to use something to the tune of:

Udt_Environment_FanIn_20170817 and Udt_Environment_FanOut_20170817

The UDT name Udt_Environment_FanIn_20170817 shown in the Name line on the New Type... window in RSLogix 5000. This image is being used to describe the process of creating User-Defined Data Types in RSLogix 5000.

Of course, this is just one idea for how to format the name for your UDT. What format does your organization use?  Let me know in the comments section below!

Adding Elements To a UDT

Now that you’ve given a name to the UDT, it’s time to add some elements.  For now, let’s look at the FanIn UDT and add elements to correspond with our Fan Outputs above:

The FanIn UDT shown with its elements filled in.
The FanIn UDT – note that PLC inputs correspond with the device outputs.

A brief interjection:  Although I did it for purposes of consistency, note that all of my elements of type BOOL are listed sequentially, followed by elements of type DINT. Because the Boolean elements in this UDT are grouped together, it will actually require less processor memory to store these elements than it would if each were defined outside of a UDT as separate tags.

This is because the smallest memory allocation for a tag is 32 bits, even if the data type does not require the full allocation. UDT elements that are less than 32 bits can be consolidated into the same address in memory, depending on how they are ordered in the UDT’s definition.

Using Pass-Through Tag Descriptions

One nice UDT feature that you can enable or disable is the ability to pass through the overall UDT description to each element.  Note our UDT description above, “From Fan Controller.”  If you choose to leave descriptions off of your UDT elements, you can set RSLogix to use the description from the UDT itself.  Alternatively, you can set your tags to append the UDT description as a precursor to each element’s description; “Comm OK” becomes “From Fan Controller Comm OK.” This can be a useful feature to provide common text for your tag descriptions.  Here’s how to set up Pass-Through Descriptions:

  • Select Options… from the Tools menu.
Options... on the Tools menu within RSLogix 5000.
  • If necessary, click the next to the Application category to show the Display category.
  • Click the Display category.
In RSLogix 5000, in the Options... menu, the Display category is shown as a subcategory to the Application category.
  • Here, you’ll find the options to Show Pass-Through Descriptions and Append to Base Tag Descriptions.
  • Check or uncheck these settings as desired.

If you want to know more about Pass-Through Descriptions, check out this literature from Rockwell Automation.

To see what the Append to Base Tag Descriptions option looks like, let’s make a tag with our new UDT.

Creating Tags In RSLogix 5000 Using Your New User-Defined Data Type

Creating a tag using your new UDT is as easy as creating a tag using atomic data types.  We’ll follow the typical procedure using the Edit Tags window, and then take a look at the descriptions for your new tag’s elements.

  • Head to your Controller Tags (or Program Tags) from the COW.
In RSLogix 5000, Controller Tags shown within the Controller Organizer Window.
  • In the bottom-most row, type in the name for your new tag, and then type in the name of the UDT that you created under the Data Type column.  RSLogix will auto-fill the data type as you type in your UDT.
Creating a new tag in RSLogix 5000 by typing in the tag name and data type.
  • Once you’ve entered the name and UDT, click anywhere else in the Edit Tags window to add the new tag.  After doing so, you’ll see the UDT description pop up in the Description column.
Te new tag created in RSLogix using the new UDT. The UDT description comes through as the tag description.
  • Click the button next to the new tag to view its elements.  Note that the UDT description (“From Fan Controller”) is appended to the front of each element’s description.
    In RSLogix, the UDT description distributed through each of the element's descriptions in the new User-Defined Data Type.

This can be an easy way to implement common wording in the tag elements that are built from your User-Defined Data Types, while still providing specific notes for each element that identify its purpose.

One Downside to Implementing User-Defined Data Types

While there’s a lot of power in using UDT’s, there’s one hiccup you can run in to when developing and maintaining your logic.

The only problem I’ve run in to when using UDT’s is when it’s necessary to modify a User-Defined Data Type by changing or adding elements.

The problem is that to modify a UDT, you have to go offline, make your changes, and then download to the processor.

Depending on the production demands in your facility, downloading to the processor may not be an easy option for you.  In the factory where I work, for instance, I only have a window of around an hour each day in which I could do a download, and I would have to answer for any issues that delayed the next shift’s startup.

Another Method For Modifying a UDT

Another option, then, is to modify the UDT offline and then import it as a new UDT – our practice is to update the UDT name with the current date: 

Udt_Environment_FanIn_20170817 becomes Udt_Environment_FanIn_XXXXXXXX. This approach, however, has its own concerns:

Any tags that you’ve added to your logic with the old data type will have to be updated to the new data type. You could change the tag’s data type in the Edit Tags window, but again – you would then need to download.

You can simply create a new tag with the new data type, but then you would need to rename every reference to every element of the old tag to refer instead to the new tag. This could be a small or massive undertaking, depending on how many elements are used and how many tags have been created with that data type.

A third option is to update your tags offline and then import duplicate routines or programs and switch your JSR’s to reference the new routines. This has worked for me in the past, and may be the best method, depending on how many references you would need to change.

In Summary

User-Defined Data Types are an awesome feature that can help you to organize and simplify your tags and even improve your memory usage in some cases. UDT’s can also come in handy big time when sharing data with other processors on the network.

How are you using UDT’s? Is there specific information you’re looking for? Let us know in the comments below, and thanks for reading! If you’d like to continue reading in this field of knowledge, check out Atomic Data Types in RSLogix 5000.

If this post was helpful for you, go ahead and take just a few seconds below to sign up for our newsletter. We’ll keep you posted whenever new industrial automation content is available. Thanks again for reading!

Fix for RSLogix 5000 EXCEPTION_ACCESS_VIOLATION on Windows 10

When I first installed and tried to run RSLogix 5000 on my new Windows 10 laptop, I was met with the following ugly Fatal Error for an EXCEPTION_ACCESS_VIOLATION:

A pop-up dialog from RSLogix 5000 showing a Fatal Error for an EXCEPTION_ACCESS_VIOLATION.
The dreaded Fatal Error.

I searched through several forum posts and tried several solutions, but what solved the problem for me was running the program as administrator.  

To change this setting, first right-click the RSLogix 5000 shortcut and click Properties:

The RSLogix 5000 icon on a desktop with its right-click Context Menu shown and Properties highlighted.

In the Shortcut tab, click Advanced…

The RSLogix 5000 Properties dialog. The Shortcut tab is shown with the Advanced... button highlighted.

Check Run as administrator, then hit OK on both dialogs to commit the changes.

The Advanced... dialog. Make sure Run as Administrator is checked.

For me, this was all it took to fix the RSLogix 5000 EXCEPTION_ACCESS_VIOLATION on Windows 10!  Still having issues? Leave a comment with your situation, or check out this forum post on PLCS.net for some other things to try.

Are you ready to take the next step in your industrial automation career?

If so, the Industrial Automation Connection is here to help connect you with opportunities to advance yourself.

Let us put you in touch with organizations that are looking for people like you.

With IAC, this service is always free, and it takes only a few moments to register. Click one of the buttons below to get started!

Was this post helpful for you? Take just a few seconds below to sign up for our newsletter, and we’ll keep you posted whenever new content is available. Thanks for reading!

NO and NC (Normally Open and Normally Closed) Proximity Sensor Basics

When I was learning PLC programming, I remember scratching my head about some of the concepts surrounding proximity sensors. Digital or analog, Normally Open (NO or N.O.), or Normally Closed (NC or N.C.)?  What exactly does it mean for a sensor to be NO or NC? What effect will it have when I’m checking the state of the sensor at the PLC or other controller?

Proximity sensors set up on an automation line.
Common “barrel proxes” (pronounced “prawksez”) set up to detect parts or features of parts as they move down a conveyor. When objects made of certain materials (depending on the sensor type) pass in front of a proximity sensor (sometimes referred to as a proximity switch), it is “made,” changing the state of its output signal.

Want to take the next step in your industrial automation career?

We want to help.

Are you looking for opportunities to advance your career and make more money?

At no cost to you, the Industrial Automation Connection can get you in touch with training and job opportunities in your area. Click one of the buttons below to get started!

NO and NC, and Other Proximity Sensor Basics

NO or NC refers to the way that a sensor is wired and in what state its output signal will be when the sensor is “made.” A sensor is “made” when an object is present that the sensor has been set up to detect. The characteristics of the sensor determine whether or not an object will detected. These characteristics can include its detection type (inductive, capacitive, ultrasonic, photoelectric, etc.), sensing range (how far away the part can be from the sensor), and other factors.  The point of a proximity sensor, or “prox,” is to know that an object is there or not there. When a sensor detects an object, its output state changes.

Digital sensors

Someone might refer to the types of proximity sensors described above as “digital proxes.”  In this context, digital has a somewhat different denotation than the typical use of the word outside of industrial automation. If a sensor is “digital,” it only has two possible output states: on or off.

There are a multitude of different sensors on the market. There are small sensors, large sensors, laser sensors, sensors like the barrel proxes above which have no configuration whatsoever, sensors that require quite a bit of set up, and everything in between. If a sensor’s sole purpose is to detect whether or not an object is present somewhere, its output is typically digital (either on or off). For this reason, people sometimes refer to sensors of this type as “switches”. Like a light switch in your home, they either turn an output on or off.

In this regard, you can think of the behavior of a prox switch or other digital output as being just like that of the paperclip switch that turned on a small lightbulb in your 2nd grade science class. The prox sensor is the paperclip, and the target passing in front of the prox is your hand pushing down on the paperclip to change the switch’s output state.

Analog sensors

Aside from digital outputs, there are devices with “analog” outputs. Analog sensors output a specific value within a range (anywhere from 2V to 10V, for instance). As one example, sensors with analog outputs can be used to tell a machine how far away something is.

Click the following link if you’d like to learn more about the differences between digital and analog sensors. For now, let’s take a look at how Normally Open and Normally Closed sensors differ in their behavior:

Normally Open Devices

A graph depicting an example of sensor output behavior for a Normally Open sensor. By default, the sensor's output is off, or "low." When the sensor detects an object in its sensing range, the output is switched on. When the object then leaves the sensor's range, the output returns to its default state of low.
This graph shows the behavior of a simple, Normally Open proximity sensor as an object passes in front of the sensor and then passes out of its sensing range. When an NO proximity sensor detects its target, its output signal is turned on (energized with voltage). When the object is no longer detected by the sensor, the output state changes back to the original state (no voltage on the signal wire). Click the image to view full size.

As mentioned above, the purpose of a proximity sensor is to tell a machine when something is present in front of the sensor.  So, what actually happens when the sensor detects an object?  Well, the sensor’s output changes state. This means that the sensor either energizes an output signal wire with a small amount of electricity, or not.

Like a light switch at your house that is off, an NO sensor will not, by default, put out a voltage to its output wire. Returning to the paperclip circuit analogy, an NO sensor’s default state is similar to the paperclip lifted off the thumbtack. The switch breaks the output circuit by default; hence, the output circuit is “normally open”. Referring to the graph above, when an NO sensor is in its default state (does not detect a target), the sensor’s output is off.

What happens when the sensor is made?

When an appropriate object passes within the sensor’s sensing range, the sensor outputs a voltage through its signal wire. This signal can indicate to a controller that the target has “made” the sensor. So long as the target remains within sensing range, the prox will continue to provide voltage on its output signal.

What’s the point of this? This is how the sensor “tells” the controller: “hey, I’m energizing my output as a signal to you that there is something in front of me right now.”

As you can see in the graph above, once the object passes out of the range of the sensor, the sensor will turn off its output. A controller would now see that the sensor is in its normal, “off” state.

As a brief aside, there are quite a few ways to refer to something as being “on” or “off”.  Below are some other ways you might hear someone refer to a signal as being on or off.  In my opinion, all of these are more or less equivalent:

MadeNot Made

Normally Closed Devices

NC sensors and other devices behave exactly opposite to NO devices in regards to their outputs. NC devices are, as indicated by their name, normally closed, meaning that their output is on by default.  Only when an object makes the sensor does the signal actually turn off.  Here’s a simplified graph of the signal behavior for an NC sensor:

A graph depicting an example of sensor output behavior for a Normally Closed sensor. By default, the sensor's output is high. When the sensor detects an object in its sensing range, the output is switched off. When the object then leaves the sensor's range, the output returns to its default state of being energized.
Here you can see that the behavior of a Normally Closed sensor is directly opposite that of an NO sensor; they are the negation of each other.
When an NC prox is made, the signal is actually “brought low.” Click the image to view full size.

If you understood the behavior of Normally Open sensors, then you also understand the behavior of Normally Closed sensors; one is simply the inverse of the other.  If an NO and NC sensor were set up to detect the same object, the NO sensor’s output would be on when the NC sensor was off, and vice-versa.

Default Output StateOutput State When Sensor Is Made
NO SensorsOffOn
NC SensorsOnOff

Why choose an NO or an NC sensor?

Due to these differences in output behavior, Normally Open and Normally Closed sensors are better or worse for certain applications.

All cables and electrical components will eventually fail.  To get an idea of why you might choose one sensor or another, let’s first talk about how we want our systems to behave when a cable or sensor is damaged, and we no longer get the signals we’re relying on to control machine motion.

The two most common types of electrical failures are “opens” and “shorts,” with opens being the most common.  An open is an unwanted break in a circuit. Cuts, crushing, or other damage to the cable can cause an open.

An example of a Normally Closed application: Emergency Stop

Modern factories are populated throughout with “E-Stop buttons”. Emergency Stop buttons can be used by anyone in the facility if an unsafe condition is observed. Slap an E-Stop, and all machine motion will come to a halt as quickly as possible.

A red emergency stop button that would be present throughout a factory for use in an emergency to stop the factory.
A typical E-Stop button.

Remember that you can think of a prox sensor as just another type of switch. What we traditionally think of as a switch is usually switched by mechanical action. Proxes are typically solid-state devices with internal electronics that turn outputs on and off. An E-Stop is an example of a true mechanical switch. When someone presses an E-Stop, metal contacts inside of the device open or close its output circuits.

NC or NO?

Let’s consider whether the E-Stop should be a Normally Open or Normally Closed device. With a Normally Open E-Stop, the button’s outputs will be off (open) when the button is in its default (not pressed) state.

In an emergency, someone hits the E-Stop.  The mechanical action of pressing the button causes the normally open contacts to close, energizing the button’s outputs. Now the controller can detect those outputs, and we can use this status in our logic to halt machine motion. Cool.

Except… let’s return to the concept of an unwanted break in our circuit. What happens if the cable that connects the E-Stop button to the controller has been damaged?

A simplified schematic depiction of an E-Stop circuit. A power supply on the left feeds power to an E-Stop switch which feeds an input to a controller on the right. There is a break in the connection between the E-Stop and controller.
A simplified depiction of an E-Stop circuit. The E-Stop is shown as an NO switch for the purpose of illustrating the concept; in reality, E-Stops are typically NC. If the E-Stop were NO, a break in the wire would prevent the stop signal from reaching the controller in an emergency. Click image to view full size.

Safety first

If the E-Stop is a Normally Open device, and its cable becomes damaged, then when we go to activate the E-Stop, we will never get a signal back to our controller telling it to halt production. To the controller, a damaged electrical system and the default output of a Normally Open switch look exactly the same. In either case, there would be no incoming voltage to the controller’s input.

If the E-Stop in this example were Normally Open, you would only check for its output signal when you needed it to stop the line. As a result, you have no way of knowing whether the button or cable is damaged until it’s too late. A Normally Open switch wouldn’t just be a bad choice for this application, it would be dangerous. In an emergency, an ineffective E-Stop could contribute to someone being severely injured or killed.

Making the right choice for the right application

For this reason, E-Stops and most safety devices are Normally Closed. When a Normally Closed E-Stop is in its default position, the contacts close the circuit and return a signal to the controller indicating that the system is safe. Because the E-Stop returns a signal constantly, any condition that causes the E-Stop signal to go low will be detected. Aside from someone actually pressing the button, some other possible causes for losing the E-Stop safe signal might include loss of power to the system, failure of the E-Stop’s cable, or failure of the E-Stop button itself.

Now, since our Normally Closed E-Stop is always sending a signal back to the controller when it’s in the safe position, we set our logic up so that we must constantly see the signal from the E-Stop to allow the factory to run.  You could think of this type of Normally Closed signal as a constant “thumbs-up” to the controller that the system is safe.  In the controller logic, machine motion would only be permitted when the expected signals from all safety devices are present.

A view of a pilot in the cockpit of an American military jet. The pilot is giving the thumbs up sign with his left hand.
Who’s got one thumb and flies a jet?

Along this same line of thought, other sensors that detect unsafe conditions, such as tank overfill, are typically Normally Closed. Because NC sensors return a signal by default, any loss of that signal will immediately indicate that the system is not safe.

Are you beginning or advancing your career in the field of industrial automation?

Let us help you take the next step.

There are organizations out there looking for people like yourself.

At no cost to you, IAC will work to connect you with opportunities in your area. Click one of the buttons below to get started!

An example of a Normally Open application: Part Present

For less safety-critical applications, Normally Open sensors work just fine and in fact are found more commonly in industrial automation than NC sensors.  In certain cases, use of an NO sensor would actually be preferable, and many people find it easier to interpret the behavior of NO sensors when it comes time to debug an electrical or programming issue.

“Part Present” applications, for instance, often use NO sensors.  Let’s say that you want a robot to pick up a part and move it to another location. When the robot moves to the “pick position,” you want to be able to verify that the part is positioned in the robot’s “end effector” before allowing the robot to attempt to move the part. An end effector is a fixture bolted to the robot arm that is custom-built for picking up a particular part.

Normally Open sensors are ideal for this type of Part Present detection, as they only send the signal that the part has been picked up if they actively sense material. If a cord or sensor is damaged in this type of application, the sensor will simply never output its signal. Because the robot won’t see the necessary signal, robot motion will halt until the problem can be corrected.

Two yellow Fanuc robots are moving pieces of metal in an automation cell.
Two Fanuc robots performing material handling operations in an automation cell.  Their end effectors are the orange fixtures attached to the ends of the robotic arms.  The end effectors likely use Normally Open “part present” sensors to verify that the part is properly loaded before moving away from the pickup positions.

NC and NO Sensors

There’s a common thread in both the Normally Closed and the Normally Open applications described above. With either NO or NC, you want positive indication before you allow the system to move. By positive indication, I mean that you want the PLC to see the signal from the sensor go high.

In the E-Stop application, you want to be able to move the system by default. You only want to disable motion if a certain condition is met (someone slaps the E-Stop). Hence, you want the signal to be on by default (Normally Closed). You only want the signal to go low if your system isn’t safe.

In the Part Present application, you want the robot to stop at the pickup position by default. You only want to enable motion under certain conditions (the part positioned properly in the end effector). Hence, you want the signal to be off by default (Normally Open). You only want the signal to go high if your part is properly loaded.

Hopefully, this has shed a bit of light on some of the basics of proximity sensors, including the concepts of Normally Open and Normally Closed. There is a lot to be said about the many sensors on the market and their functionality. Click the following link for an in-depth look at the various types of sensors and how they work.

Anything you wish we would add to this article? Send us an email or let us know in the comments section!

If you found value in this content, let IAC keep you posted whenever we have something new for you! Sign up below; it only takes a second. 🙂