Resources
Deciphering the Puzzle of PLCs, PACs, PC-based Controllers and Motion Controllers
Submitted by Corey Foster || Valin Corporation
There is plenty of discussion in the industry regarding the pros and cons surrounding programmable logic controllers (PLCs) vs. programmable automation controllers (PACs) vs. PC-based controllers. However, there is still uncertainty at times among end users. In fact, I have asked customers the same question about their PLC vs. PC-based controller preferences back-to-back in the same day and received completely opposite answers. Most of this is due to the complexity of the topic. So, the question becomes: “As a distributor with multiple solutions to offer customers, all things being equal, how do we decide which solution to recommend?” The answer isn’t always simple.
There are many factors that go into such a decision. However, there is one factor in particular very few people seem to understand that needs to be taken into consideration. I make it a point to teach both my customers and my team, so they understand the importance.
I always ask the customer who is going to program the system. At this point, we may be talking to a mechanical engineer about an xyz gantry that needs all the mechanics, motors, drives and controls. When I ask that question, the mechanical engineer may be the person who will be programing the system; however, more than likely, it will be a controls engineer or a contractor. Why does that matter when making the decision about which controller works best for your application? After all, isn’t a controller a controller? There are many variations to controllers, but what is the recommendation for an application that multiple controllers can all just as easily solve? Unfortunately, I found out the hard way early in my career why that matters and what kind of impact it can have. Working as a young application engineer for a motion-control manufacturer, I knew all about that company’s motion controllers, but I knew nothing really of what a PLC was or how it differed until many years later. I started supporting a customer who was working on a six-axis wind-tunnel application at an Air Force base.
I learned early during the interaction that he had been programming a big brand-name PLC for 20 years. Thus, I knew he was experienced, but why did that matter to me? After all, our motion controller had a PLC scan mode. I’m sure it could do the job, and it eventually did. At that time, my programming work consisted of scripting languages that executed line by line, much like I had learned in my college Fortran programming course just a few years prior. Like Fortran, the program could be executed one line at a time for better understanding and troubleshooting.
The new controller had a PLC scan mode. However, this only had logic, but no motion commands. Then, it was compiled, so it could run faster. Rather than one millisecond per command on average, it could run through many of them in two milliseconds.
At the time, for a motion controller that didn’t typically handle much logic, it was a potential game-changer. Ultimately, it kept this wind-tunnel application from needing both a motion controller and a PLC. I continued to support this customer by way of long phone calls and many emails over the course of six months. I never met him in person, but we spent so much time together that he sent me a digital Christmas card with a picture of him with his family. He is the only customer in my 25 years to ever do that to this day. The crux of the programming challenge was centered around interlocks. This was a new term for me. The PLC scan mode wasn’t ladder logic, which had been used for 20 years.
Where ladder logic presents a visual representation that helps the programmer keep the logic organized, the scripting programming methodology of Fortran and the motion control world make logic programming a bit more confusing to track. This is unless you adopt good formatting habits consisting of spaces and tabs, such as an outline.
I initially couldn’t understand his discussions and questions about interlocks because it wasn’t an obvious use of the word in a scripting language. Years later, when I learned ladder logic, I finally understood why he kept using that term. It makes so much more sense in ladder logic’s visual representation.
The logic portion of that particular program with that programmer took much longer than it should have. However, the application was all about motion control, which is why a motion controller was used, as opposed to a programmable logic controller. I continued to learn more about both what PLCs do well and what motion controllers were designed to do. This time I was onsite for a week working on a new pork-handling machine.
The programmer that I was there to support was programming the same motion controller with the same PLC scan mode. We were really pushing the PLC scan mode hard and seemed to be finding cracks in its robustness.
I kept getting on the phone with the main motion-controller firmware programmer. After I returned home and the firmware programmer became directly involved, he learned there was also PLC in the system—a big brand-name one with plenty of logic-processing capability. The obvious solution at the time was to simply stop trying to make the motion controller do more than it was intended to do and, instead, make the PLC do what it was designed to do. Years later, I started working side-by-side with a colleague that had been a PLC programmer longer than I’d been a motion-control programmer. As we cross-trained each other, we had a lot of concepts, vocabulary and organizational tips to explain to one another. This completely verified and cemented my thesis that there are motion-control programmers, and there are PLC programmers. Finding one that does both is rare, but possible. More modern controllers make this more likely with their IEC 61131-3 languages and PAC capabilities. If you want an expert, don’t look for the one who has taken all the training courses; find the person who has made the most mistakes in the given field. That is why, despite my pride, I can share these hard-won lessons with you.
Article featured in Control Design Magazine
There are many factors that go into such a decision. However, there is one factor in particular very few people seem to understand that needs to be taken into consideration. I make it a point to teach both my customers and my team, so they understand the importance.
I always ask the customer who is going to program the system. At this point, we may be talking to a mechanical engineer about an xyz gantry that needs all the mechanics, motors, drives and controls. When I ask that question, the mechanical engineer may be the person who will be programing the system; however, more than likely, it will be a controls engineer or a contractor. Why does that matter when making the decision about which controller works best for your application? After all, isn’t a controller a controller? There are many variations to controllers, but what is the recommendation for an application that multiple controllers can all just as easily solve? Unfortunately, I found out the hard way early in my career why that matters and what kind of impact it can have. Working as a young application engineer for a motion-control manufacturer, I knew all about that company’s motion controllers, but I knew nothing really of what a PLC was or how it differed until many years later. I started supporting a customer who was working on a six-axis wind-tunnel application at an Air Force base.
I learned early during the interaction that he had been programming a big brand-name PLC for 20 years. Thus, I knew he was experienced, but why did that matter to me? After all, our motion controller had a PLC scan mode. I’m sure it could do the job, and it eventually did. At that time, my programming work consisted of scripting languages that executed line by line, much like I had learned in my college Fortran programming course just a few years prior. Like Fortran, the program could be executed one line at a time for better understanding and troubleshooting.
The new controller had a PLC scan mode. However, this only had logic, but no motion commands. Then, it was compiled, so it could run faster. Rather than one millisecond per command on average, it could run through many of them in two milliseconds.
At the time, for a motion controller that didn’t typically handle much logic, it was a potential game-changer. Ultimately, it kept this wind-tunnel application from needing both a motion controller and a PLC. I continued to support this customer by way of long phone calls and many emails over the course of six months. I never met him in person, but we spent so much time together that he sent me a digital Christmas card with a picture of him with his family. He is the only customer in my 25 years to ever do that to this day. The crux of the programming challenge was centered around interlocks. This was a new term for me. The PLC scan mode wasn’t ladder logic, which had been used for 20 years.
Where ladder logic presents a visual representation that helps the programmer keep the logic organized, the scripting programming methodology of Fortran and the motion control world make logic programming a bit more confusing to track. This is unless you adopt good formatting habits consisting of spaces and tabs, such as an outline.
I initially couldn’t understand his discussions and questions about interlocks because it wasn’t an obvious use of the word in a scripting language. Years later, when I learned ladder logic, I finally understood why he kept using that term. It makes so much more sense in ladder logic’s visual representation.
The logic portion of that particular program with that programmer took much longer than it should have. However, the application was all about motion control, which is why a motion controller was used, as opposed to a programmable logic controller. I continued to learn more about both what PLCs do well and what motion controllers were designed to do. This time I was onsite for a week working on a new pork-handling machine.
The programmer that I was there to support was programming the same motion controller with the same PLC scan mode. We were really pushing the PLC scan mode hard and seemed to be finding cracks in its robustness.
I kept getting on the phone with the main motion-controller firmware programmer. After I returned home and the firmware programmer became directly involved, he learned there was also PLC in the system—a big brand-name one with plenty of logic-processing capability. The obvious solution at the time was to simply stop trying to make the motion controller do more than it was intended to do and, instead, make the PLC do what it was designed to do. Years later, I started working side-by-side with a colleague that had been a PLC programmer longer than I’d been a motion-control programmer. As we cross-trained each other, we had a lot of concepts, vocabulary and organizational tips to explain to one another. This completely verified and cemented my thesis that there are motion-control programmers, and there are PLC programmers. Finding one that does both is rare, but possible. More modern controllers make this more likely with their IEC 61131-3 languages and PAC capabilities. If you want an expert, don’t look for the one who has taken all the training courses; find the person who has made the most mistakes in the given field. That is why, despite my pride, I can share these hard-won lessons with you.
Article featured in Control Design Magazine
Printer-friendly versionA lesson for me is that I need to involve you earlier in the program.
You were tireless in your support and it will not be forgotten!
Latest from Valin's Blog
The NIST Chemistry WebBook contains a great deal of information regarding the properties of a broad range of chemicals and is helpful for those who deal with chemical processes.In this article, Jon Monsen has outlined the procedure for finding the actual density of a gas using the WebBook.