Programming a PLC vs. industrial PC: which is best?

Figure 1: PLC programming software (ladder logic and structured text) vs. VBA.

(Source: Panasonic) 

In addition, an IPC demands attention, care and expertise to maintain its operation. This is often tested during the downtime of the machine. Many process and control engineers have commented in the past about PC registry issues after updating a program or adding a PCI driver. When compared to an IPC, PLCs have reduced machine downtime, thanks in part to built-in functions like backup programs or early-failure-detection subroutines.

As for the PLC, the programming environment is clear, concise and consistent. For instance, the definition of a variable is done beyond the actual PLC program; this minimizes the number of lines required for your code to operate (Figure 1).

PLCs offer a graphical method for the development and control of the machine’s behavior. It is called ladder logic, and it is simple and amazingly effective. This is achieved by graphically mimicking an electrical circuit, emulating how a machine operates. However, PLCs have more to offer. Since the definition and implementation of the IEC 61131 standard, PLCs have shared a common logic and program foundation, regardless of the manufacturer. PLC programs that are structured under this standard can be debugged efficiently and effectively. On the contrary, IPCs do not follow a recognized standard, making it difficult to decrypt the actual logic defined by the programmer which makes the transfer of IP difficult in systems designed for long life or to be sold. The IEC 61131-3 standard promotes the use of five different programming languages in the PLC:

• instruction list (IL)
• functional block diagram (FBD)
• ladder logic (LL) for digital inputs and outputs logic
• structured text (ST) for advanced mathematical formulas, sequence of events (FOR or WHILE loops) and decision making (IF THEN ELSE, CASE) statements
• sequential function chart (SFC) for complex process iterations or branching.

PLCs also offer built-in PID functionality which provides accurate control of the film unwind mechanism by controlling the servo’s speed or start-stop routines, as in the case of the packing machine mentioned earlier. How to use a PLC’s PID strictly implies the proper definition of its inputs, such as sensor, thermocouples or encoder, and outputs, such as ON-OFF control or pulse with modulation.

The PLC’s PID executes cyclic tuning drills, finding optimal PID constants. Consequently, the controls engineer’s attention remains focused on the process and not the PLC program. On the contrary, an IPC programming platform, such as Visual Basic, demands a workaround to create the algorithm that defines the PID function. Such workarounds lack the industry exposure time that’s required to vet its efficiency and work out any bugs in the function. This adds delays during the testing and troubleshooting of the program and limits the precision of the algorithm to the experience of the programmer.

To deliver maximum performance while requiring minimum time, the PLC uses what is known as the reduced instruction set computer (RISC) structure. Typically, PLCs have 32-bit microprocessors with a clock frequency around 100 Mhz. Designed with the intent to be operating during most of its lifetime, a PLC requires less maintenance than an IPC. IPCs, however, with complex hardware architecture, often require updates to the operating system, which in many occasions requires the program to be altered.

Figure 2: PLC programming software ladder vs. generic PCI view, depending of dedicated programming language.

(Source: Panasonic)

Another example is related with the use of stepper motors. The interaction between the IPC’s CPU and a PCI motion card will require advanced instructions or ActiveX apps (.Net platform) to operate properly. Consequently, a set of constraints will limit how the IPC’s program executes a motion profile, corrects high positioning deviations and controls interrupts for emergency stops or rapid speed changes. The PLC has evolved around motion, making its implementation much easier. Dedicated PLC motion cards provide friendly user interfaces, such as motion tables, to quickly build complex motion profiles. IPCs do offer similar solutions. The difference is that, with the PLC, the programmer can read and write over the PLC motion card’s shared memory. This allows for deeper access to hardware features, which helps with the debugging of motion issues. In addition, PLC motion cards offer hardware and software interrupts, alleviating headaches for machine builders who require the use of sensors to detect label edges, gaps, registration marks and more (Figure 2).

Human-machine interaction: IPCs can host SCADA programs. The issue is that SCADA programs come with higher price tags and utilize a large amount of resources to implement and run. SCADA programs also require the addition and integration of an OPC server. This adds a high level of complexity that may impact your project efficiency. However, more is less when thinking of effective human-machine interaction; this is the case when using PLCs coupled with an HMI or touchscreen. Connected through serial ports, the PLC and HMI can perform at the same level as that of a SCADA package. HMIs are simple to program and provide an intuitive feeling when using them. The HMI itself is a self-contained piece of hardware that offloads the graphic requirements of the PLC. In this case, the user just needs to deal with the right PLC driver and incorporate memory addressing and/or tags. Limitations typical of HMI are the available widgets and the parts library. PLCs and HMIs are the on the front line of packaging machines, thanks to industrial protocols and PC-oriented hardware.

As for the case for processing information, this topic will shift favorably toward the IPC. IPCs can process vast amounts of data in a short amount of time, due to their processors, and IPCs have the capability to deliver data in any accessible network. Memory capacity of IPCs exceeds that of the PLC in several orders of magnitude. If an application is highly sensitive to data management, then the argument is in favor of IPCs. Nevertheless, PLCs have been making significant improvements in this arena. PLCs offer memory cards for data collection, high-end mathematical instructions for error detection, data encryption for safety data management, client-server broadcasting protocols, Web server functions and much more. All of this is accomplished with minimum hardware and programming effort.

Product quality: This topic has already been validated at this point. A flexible machine that can be operated efficiently, with minimal setup time and for a long period should produce a high-quality product. Although a true statement, it is not without its issues. It is good to remember that not all PLCs are created equal, and not all PLCs have the same performance record. Recall that an IPC has the capability to perform any industrial task it’s programmed to perform. The issue extends from the costs associated with the software and hardware required to perform the task.

In the end, PLCs are cheaper and easy to maintain but this does not ensure quality. Major PLC brands deserve our gratitude and trust, but not our loyalty. Your product quality depends of choosing the right hardware and software, technical support and resources to encourage creativity and positive ROI. PLCs have been used for so long in this field that process and controls engineers rely on this knowledge to deploy solutions in shortened timeframes. Currently IPCs lack such valuable resources.

The best of neither world

Kenn Anderson, President, Nova Systems, Milwaukee, Wisconsin, member of Control System Integrators Association (CSIA): In my opinion, neither of the options is ideal.

VB.Net has pros and cons.

Pros:

• appears to be the only tool in the programmer’s toolbox.

Cons:

• appears to be the only tool in the programmer’s toolbox
• difficult to debug; more startup time
• difficult to reload if CPU needs replacement
• almost impossible for a user to troubleshoot
• requires special I/O hardware
• difficult to access motion (EtherCAT)
• hardware will likely be more costly.

PLC with ladder editor has pros and cons, too.

Pros:

• economical hardware
• easy debug if you understand the code
• user access for troubleshooting
• quick download if processor dies
• standard off-the-shelf hardware
• easy to integrate third-party evaluated safety (must for machinery these days).

Cons:

• ladder not the right editor for machinery sequence
• using the ladder editor, machinery sequences can lead to complicated, hard-to-understand code.

Our recommendation is a PLC with sequential function chart editor.

Pros:

• can implement PackML state machine for control
• widely accepted; easy-to-follow architecture; ISA 88 standard
• easy-to-debug state machine using step mode
• uses off-the-shelf hardware
• runs fast (only one state is executing at a time)
• easy to incorporate motion blocks
• easy user access for troubleshooting
• easy to integrate third-party evaluated safety (must for machinery these days).

Cons:

• have to learn new editor but able to use VB-like structured text in state blocks.

An experienced system integrator (SI) can help in this process, but it will add cost. However, the project will get to market more quickly and the in-house controls engineers can learn from the SI at an accelerated rate to be able to support the program after the first one or two machines are out and then be mostly self-sufficient.

Compete on price

Don Pham, product manager, IDEC: Either programming language will work, but an IPC will almost always be too expensive for an 80-I/O-point application, as compared to a PLC. The exception would be if there are extraordinary requirements for features typically found in an IPC and not in a PLC, which doesn’t seem to be the case here. The cost of automation components is particularly important for OEM machine builders, who often must compete on price, so cost is a big factor and will probably override any perceived programming issues.

In terms of programming, modern PLCs have many features included with their free or very low-cost PC-based PLC programming software packages to simplify ladder-logic programming, making it simpler to program than VB for machine control applications. VB is a general-purpose programming environment, whereas ladder logic is specifically intended for machine control, making it a better fit in this application.

Finally, very few OEM customers would object to ladder logic, whereas many might have an issue with VB. In the worst case, this could cause OEM customers to reject the bid up front. In other cases, the OEM customer might accept the VB programming, but then expect the OEM to provide free support due to a lack of familiarity.

Who’s running the machine?

Max Gorbunov, control and automation engineer III, performance materials, Laird: I understand where your programmer is coming from. To a person trained in object-oriented programming, ladder logic can seem very daunting and impenetrable. Thinking in object-oriented programming is a tough habit to break. It took me several years and several PLC software suites before I found my groove with ladder logic and saw it as a good alternative to PC-based systems. PCs absolutely have their place in automation control, but they need to be used with care.

There are a number of big advantages to using a PC; it is much more computationally powerful, compatible with a larger number of interfaces and protocols and is often times less expensive. Microsoft’s .NET is a very powerful platform to build on. It can be made compatible with any number of network protocols to communicate with devices such as servo controllers. It has libraries available for advanced industrial applications such as true parallel thread routines, machine vision, point cloud analysis or HMI bells and whistles such as animations or remote support. However, there are some shortcomings to take into account when designing a system. The first is reliable timing. A running PLC will cycle through every ladder rung in a program at a very consistent speed. This makes sequence timing very reliable. A PC on the other hand will have an operating system with dozens of services running in the background. These services will ultimately compete with your control application for system resources. If you were to write a program in .NET which required the use of a 500-ms delay, for example, you could see the real delay time sway 50-75 ms in either direction, while on a PLC you would see much more stable results. This becomes especially apparent on multi-threaded applications. To avoid any timing errors, it is a good practice to not rely on timing alone and instead make sequencing more event- and feedback-driven. Another big drawback to PC-based systems is system startup. When you power up a PLC-based system, you can have a dedicated run once startup routine and then your system boots to its main routine within milliseconds. A PC system startup is a much longer process. The system has to boot into the operating system and then launch the control application. In those few minutes, you will have no control over any of your I/O. A good practice would be to interlock your software application with the safety controller to make sure the system boots safely.

Ultimately, the decision should come down to the person who is going to develop and support the program. Learning ladder logic and learning to use a PLC software package for a particular PLC brand from scratch takes a lot of time and work. If your programmer feels they are better equipped to use a PC-based solution and have no need to learn ladder logic, this may be the best way to go. The hardware itself would be plenty capable of running the machine provided that all of the proper precautions are taken.

Implementation, support, acceptance

Branch Bissette, control designer and programmer, Solvere, Belmont, North Carolina, member of Control System Integrators Association (CSIA): A larger portion of our business is to design and build control systems for OEM machinery builders. The majority of these systems are similar in size and scope to what you are asking about. We almost exclusively use PLCs for the core portion of the control system for reasons I will outline below. While we may utilize PCs in conjunction with PLCs for some systems, the PCs are mainly used for data collection and to provide a bridge between a plant network and the outside world. The machinery control functions are dedicated to the PLC. Our preference for PLCs over PCs is based on the following.

PLC are a more rugged and stable control product, designed for industrial environments. While there are some industrial PCs that hold up well in harsh environments, we have found PLCs to be much more reliable than PCs. PLCs are also a very stable platform since the software is specific to the hardware by that manufacturer. We have had PLC-based systems running for more than 20 years. During this time, modules may have been replaced many years after original installation. It is rare to encounter problems with incompatibility when modules or the program is changed on older PLCs. With PCs you are more likely to encounter problems where operating systems or drivers have to be upgraded when changes are made.

PLCs have better acceptance by industrial end users. Often a factory will specify a type of PLC it wants as part of the machinery. Usually this is to make it easier for them to support spare parts and training of personnel. If your control system is PC-based, you will have a difficult time convincing a customer with a PLC specification to accept your PC-based control system. If your system is PLC-based but a different brand than specified, you would have an easier time gaining acceptance, and, if not, it will be much easier to port your PLC program to the other PLC brand than if your system is PC-based.

PLCs are a more cost-effective control solution, compared to PCs. When using PCs for industrial control, you are usually just replacing the CPU portion of the PLC and still must use PLC I/O modules or a similar product for connection to digital and analog signals on the machine. PCs often require an additional module with the I/O to serve as an interface between the PC and the I/O, which is not required by the PLC.

Most of our PLC-based machinery control systems are programmed with ladder logic. We find this the easiest to implement and certainly to support, and it has the best industry acceptance. For a machinery control system, the time it takes to write the original program is just one of many factors to be considered. The program should be written so others can easily follow and make future changes. This may not only involve other programmers at the OEM, but technical personnel at the end user, often many years after the original program was written. We have found the control programming language best suited for long-term support by others of varying levels of training is ladder logic.

If the application requires a certain feature which is better suited to another form of programming, such as statement list or STL for Siemens PLCs, we will write most of the program in ladder and call an STL subroutine for the special feature.

What creates value?

Dan Cole, controls engineer, Pearson Packaging Systems: Machine control has been addressed using PLC programming for many years. It is the industry standard. The PLC is a stable device that will continue running long after the machine has mechanically failed. However, there are some downsides to using a PLC. If the machine is going to be connected to a network, the PLC will require additional equipment, such as switches. A PLC is also a pricey solution, sometimes twice as much as a PC. Visual Basic (VB) programming is also a simple way to program machine control, but it comes with the added benefit of being easily connected to a plant-level network. Using a PC with an embedded operating system protects the controller from the dreaded Windows updates, maintaining solid performance for the controller. As a developer, I could argue either solution. However, I prefer the flexibility that VB provides.

The best way to settle this debate is by considering the application and the customer. Most customers are comfortable with PLCs. As a machine builder, you need to be prepared to have a solid case for using a PC-based controller when selling your product. I am of the belief that you should do what is best for the customer, even at the sacrifice of your own hardware and software preference. Our job as OEMs is to create value using innovation—value that can be transferred to our customers.

PLC vs. VB programming

Eelco van der Wal, managing director, PLCopen: There are always two aspects to selecting a programming environment:

1. What programming language do you want to use? This depends in many cases on what you are used to.
2. Which components, such as sensors and actuators, that I want to use are supported in the programming system?

You mention that you will be using mostly pneumatic actuators and a few servo motors. Most PLC environments will have direct support for this, and PLCopen has taken care that the motion-control programming is harmonized across the different systems, giving you the possibility to choose between suppliers.

If a programmers want to use VB, he or she probably has to program these interfaces to the separate actuators completely. This can be a tedious job, wasting human resources as well as money. Moreover, the resulting program can be difficult to maintain within your organization if this person is the only one who programs in VB.

Also, if a programmer is not familiar with industrial automation, I certainly would advise to stay within a PLC development tool since the tools are much more oriented to the industrial environment.

You mention that the program comprises a 21-step sequence. Excellent decomposing done here. For this, I would use sequential function chart (SFC) to map this directly and easily to SFC steps, including the transitions between these steps, and then use any of your other known languages to specify the different actions at the action blocks. This gives an excellent overview and a fast track to your application program. I do not think that VB can give you a result here that quickly.

So, I would propose to use PLC programming since, especially due to your decomposition, it helps to create your program more quickly with less errors and with a better lifecycle support, regarding future updates.

Why reinvent the wheel?

Donald Labriola P.E., President, QuickSilver Controls: A big question between the PLC and the PC, at least to me, is how long is this configuration going to be maintained, and does the company have multiple programmers to maintain it? The code for the PLC can more easily be handled by the next PLC programmer. Specialized Visual Basic or C# or C++, unless there is a lot of discipline to put the time into documentation, are much more difficult to pass to the next person, especially if the original programmer is no longer available. Mature software groups have the methods in place to succeed in passing on information; ad hoc will lead to issues.

Another issue is how hard of real-time is required. Does the PC operating system support real-time? The PLCs normally have a lighter overhead and will specify the update rate according to the number of rungs being processed.

There is also more of an issue of maintaining the product line in the face of changing PCs. Sometimes that really good price was because the manufacturer was closing out that product line. Significant effort may be needed to re-qualify the new PC more frequently than desired, especially if there is much regulatory compliance involved. Much of this is normally hidden from the customer by the PLC manufacturer. If you decide to go for an industrial PC, be sure to see how long they will make that particular configuration available.

Be aware of whether the operating system will be going through regular updates and how this affects any testing that may be needed when the update happens. This problem typically is less of an issue with the PLC.

The PC route may be justified where the complexity and interfaces are just not available in an affordable PLC, but be sure to be careful of the pitfalls. Getting all of the interface protocols up is not always as easy as one would guess, and you may need to get closer to the operating system than you would prefer. If you don’t really need to reinvent the wheel, try to avoid it.

Don’t roll your own

John Kowal, director, business development, B&R Industrial Automation: I'm more concerned that the programmer in question has no automation experience. Industrial controls suppliers invest great sums of dollars in their software development environments to provide IEC 61131-3 compliance, documentation and useful functionalities, enable best practices and promote structured, modular code. “Rolling your own" puts that responsibility on the inexperienced programmer and will likely result in a machine that your other programmers will find difficult to troubleshoot or modify in the future.

This doesn't mean that the PLC code has to be limited to ladder. It may be a combination of IEC ladder diagram (LD), function blocks (FBs) containing code written in ST, and/or FBD and SFC. The purpose of programming in IEC 61131-3 languages does not mean that the end users should be encouraged to modify the source code. Rather, I would suggest a state-of-the-art development environment where your code is compiled to protect the integrity of your software, with configuration tools, a software "sandbox" in which the user can apply familiar ladder logic to perform tasks such as handshaking or adding timers and sensors, without touching your code, and using the ISA TR.88.00.02 (PackML) and OPC-UA standards.

Machines like ladder

Cindy Hollenbeck, vice president, SoftPLC: For machine control, ladder logic offers a number of advantages.

Ladder is interpreted, not compiled, which means that run-mode programming and online monitoring of machine states are inherently built in to the PLC software tools. So, whether the end users will be maintaining/troubleshooting the machine or you as an OEM will be doing this, especially remotely, this is a huge advantage. This is especially true of sequential operations.

If someone needs to take over maintenance of the logic in future, ladder logic is familiar to electricians and controls engineers, not just to programmers.

PLCs are not subject to Microsoft's development schedule of updates/obsolescence or to IT department automatic updates of the operating system based on generic policies for office computers.

PLCs are deterministic; Windows and VB are not. This means that, from scan to scan, the I/O processing will be consistent on a PLC.

PLCs include well-tested, field-proven and efficient communications to I/O, HMIs and computers. Using a PLC eliminates the need to develop drivers and/or incorporate third-party drivers or to use OPC, which is not really a good solution for I/O processing vs. HMI type data exchange.

Put the end user first

Deana Fu, senior product manager, Mitsubishi Electric Automation: This is a tough debate. Once people's minds are made up, it is hard to sway them to the other side. Whether it is ease-of-programming, maintenance, scalability or parts availability, it's probably safe to assume that both of you already have a long list of pros and cons. This is natural. When the stakes are high we tend to default to what we are most experienced and confident in. Yet, with minimal effort, both of you could probably become well-versed in either programming method and complete this machine.

Let's put your preferences aside, and consider who are your end users and what do they want? Ultimately, they are the ones who will be making the purchasing decision. Do they have the skill sets to learn and support VB programming with minimal training? If the assembly machine stops during their busiest season, would they be able to troubleshoot and quickly get it running again? Or will they be at a standstill and call you for emergency on-site support? And, when the control hardware becomes obsolete, how much time and effort will it take to convert the program to work with next generation hardware? High-level programming is the norm at some select industries, and they tend to have dedicated programmers on staff to support any custom coding needs. In that case, maybe VB programming is the way to go. But, if your end users simply want an industrial control system they can operate and maintain with minimal effort, then that 21-step ladder sequence sounds like a very good option. Most PLCs use ladder programs and other IEC 61131-3 languages that are designed to do exactly that—keep the program simple and straightforward.

How about a hybrid?

Clark Kromenacker, product marketing manager—PLCs, HMI, RFID, Omron: The biggest advantage a PLC brings to the table and why they continue to be used over straight out Windows PC is something that the industry calls determinism. We have all seen our own Windows-based PC applications slow down when other programs are running in the background or when we start to run a resource-intensive application. If the running of your VB.Net program started slowing down, the I/O could update at different rates, meaning actuators and indicators would vary in their response times. In other words, they would not be deterministic. We all know that with a PLC, the program executes every line of code and updates the I/O at a constant and repeatable rate, no matter what else is going on in the PLC—communications, alarm generation.

The industry has tried to isolate the Windows operating system with things such as Windows Extensions, which bypass much of the Windows operating system and function at a lower level, closer to the PC BIOS. Then machine control would be run on top of these extensions. So, not sharing many of the Windows resources with other programs allows some sense of determinism. However, since this is still part of Windows, when Windows crashes, the machine control goes with it, or, if there is a problem with Windows at that lower level, close to the BIOS system, the machine control gets affected.

The real solution if a PC is needed to manipulate data is to have totally separated operating systems on the same platform. The high ground in industrial-PC technology is to have half of the machine running a conventional operating system from Windows and the other half a true real-time operating system (RTOS). Then a communications path from Windows to the RTOS allows true determinism in the machine control and full Windows functionality together. In a hybrid of this type of industrial PC, the BIOS are partitioned so the Windows and machine control RTOS operate independently with a hypervisor link to coordinate activity. Only this type of architecture can be truly reliable.

If you need Windows functionality and machine control, I would recommend using a hybrid industrial PC with a Windows RTOS system. If you only need deterministic and reliable control, then the stand-alone PLC would be the most reliable solution.

All in real time

Bill Faber, director, product management & new business development, Delta Products: Selecting a programming language is certainly an ongoing debate because there is a lot more at stake as the factors of deployment are considered. This is more of a platform question, and the questions that an end-user production facility would ask are eventually the same questions that an OEM machine designer would need to ask around maintenance, support, compatibility, production level, application complexity and uniqueness, reusability and scalability.

Will this programming platform allow for long-term sustainable support as a machine product, if machine operation stops, or if it needs to be upgraded? Manufacturing facilities purchasing production machinery will factor in how easy it will be to support this machine, not just in installation, but also in the machine’s lifetime in production. Standards such as IEC-61131-3 and PLCopen were established to address that point. Multiple PLC vendors and IPC vendors both allow for use of it; the installed base is already high, and we are seeing the adoption rate of the standard continue to increase in manufacturing. This standard supports multiple programming environments including structured text and function encapsulation which also helps to retain code reusability and intellectual-property (IP) protection. VB.net has open programming benefits, but, if it is not a common programming environment for the OEM machine builders target market, then using the IEC standard will put purchasers at ease when selecting capital equipment. How many engineers and technicians will be supporting this as a machine product and as a production machine? Whether they sustainably have the right training is a good litmus test of this. Additionally, it is very easy to create a state machine in ladder logic which is also simple for a technician to understand, as well as trap error states and conditions, making it easy for anyone with basic IEC standard training to troubleshoot.

What are the production goals, and how critical is downtime? The robustness of the target CPU will need to be considered, especially if the environment is a continuous process or a critical discrete component of a manufacturing line. Assembly machines could fall into that, if in-line. If the end-use facility is concerned about operational equipment efficiency, then uptime, yield and throughput will be of great concerns, as well. A lab environment might be able to sustain a reboot from a Windows PC, but a production environment will need to ensure the system is always in control to reduce downtime costs, reduce material waste and meet volume production needs. It may be possible to split the HMI and control, but of course costs of control systems need to be kept down; a PLC certainly provides that separation and scalability.

Is a PC required? If the machine requires extensive local processing, data collecting or a specific program to compliment the machine solution, then a PC might be necessary or most efficient if tight integration is an absolute need. This could be the case in a machine that has a vision system; however, there are smart-camera systems and fast networks on the market today that can accomplish the same task. Additionally, with edge-computing devices and cloud-platform solutions becoming more available, there are more flexible ways to off-load PC tasks in a hybrid or distributed control architecture and make it more accessible.

How unique is the machine solution? The more unique the machine solution is over the lifecycle of it as a marketed product, the more willing an end user will be to accept whatever programming environment is provided, but the competitive advantage would need to be substantial. It’s also important to look at the application complexity. If the machine requires centralized deterministic motion control and real-time synchronization with strict I/O, then a PLC has historically provided that more robustly, even in an upgrade or component replacement, due to auto-config modules. It’s possible to deploy an IPC with a tightly integrated RTOS, but to be able to maintain that over the lifecycle of the machine asset could prove to be a major challenge when considering upgrades and backward-compatibility. This could be overcome if the IPC supplier provides support for the complete package. Most PLC manufacturers have long lifecycles for their products because they were designed for long-lifecycle industrial applications.

Stick with the proven standard

Jeff Clonts, product manager, Allied Electronics: For machine control applications, I would strongly encourage the PLC over the industrial computer option. PLCs are a proven industrial standard that will provide a platform for application development and troubleshooting. Most PLCs offer preconfigured instruction sets that will allow the user to drag and drop popular instructions such as timers, counters, and compare functions into the logic. Some even provide motion-control instructions that could simplify your servo application.

For this project, you could create individual subroutines for each of your 21-step sequences. This would provide the end user with a clean, organized and easy-to-interpret program. Your end user will likely have technicians or engineers on staff who can monitor this code to help identify hardware failures or equipment fault conditions. However, systems that are programmed in higher-level programming languages are far more difficult for the end user to troubleshoot. If the customer is unable to provide some level of in-house support for this machine, your company’s reputation could be damaged. If your decision comes down to comfort with one language over another, many PLC suppliers offer excellent PLC training classes. Having a working knowledge of PLCs and ladder logic would be a wonderful and necessary skill set for any controls engineer to have.

ALSO READ: A very short history of PLC programming platforms

It's application specific

Matt Schmidt, Engineer, Concept Systems: As you are experiencing, the PLC vs. PC debate is very much alive and well in the world of controls right now. The short answer is that the decision should be application specific.

In your case, with 80 I/O points and several servo motors, a PLC is a great fit. Handling discrete I/O is one of the things PLCs do best. Remember, they are modeled around switches and relays. You will also not find it difficult to discover many PLC-based motion control options for your servo motors.

There are many factors to take into account as an OEM when making this decision. Here are a few.

Robust and Reliable: What environment will your machine operate in? For dirty, dusty, extreme temperature, or generally harsh environments a PLC will continue to run where an IPC may not. A PLC uses a dedicated processor which provides a high degree of control system reliability. The IPC will be running a PC-based OS and will require system updates and security measures to protect against unauthorized access.

Machine Service: What is the service plan for your system? Service technicians, system integrators, and plant maintenance personnel can quickly troubleshoot a PLC with discrete I/O. Similar troubleshooting on a PC application is often more complicated and difficult for those servicing the machine.

Controller Cost: Typically, this is the consideration PC-enthusiasts will tout in their favor. Yet there are many factors influencing cost beyond the base price of the controller. For example, both the PLC and IPC will require I/O modules. The PLC will require HMI hardware/software while the GUI for the IPC can be deployed directly on the controller. Pricing and availability of hardware components now and in the future should be considered. PLCs typically have a longer support and lifecycles than PCs. Development time is often a large cost. While an elegant solution can be achieved on the IPC, it may take a fraction of the development time to write a ladder-logic program.

Hopefully this will help guide the discussion as your team determines the right technology for your application.

Question the tool

Matt Newton, director of technical marketing, Opto 22: Today, there are a lot of options for programming an industrial application. Modern industrial automation controllers are being shipped with new technology built in—like web servers, data encryption, and RESTful APIs. Industrial application developers can literally write their application in just about any language they want, from ladder logic to VB.Net, Node-RED and JavaScript. But in the end, it really comes down to choosing the right tool for the job—or more specifically, the right language for the application. Here are some things to consider.

Is this machine going to be interfacing with IT resources in ERP or MES applications? If so, it’s probably a good idea to go the VB route, since that language is designed to work in applications where IT resources like databases and web servers are being used. Traditional ladder logic wasn’t designed to easily interface with external network assets like web servers and databases.

Is the machine going to be deployed and then never touched or interfaced to other systems again? In that case, a traditional PLC programming language like ladder logic or flow chart/function block-based programming might be the better choice.

Can you easily find engineering talent to support the application? Today, there are more VB.Net and JavaScript programmers than there are ladder logic programmers—which may affect the cost and availability of supporting the application down the road.

What about future proofing the application? There’s a lot of industry buzz around Industrial Internet of Things (IIoT) technology. Traditional ladder logic doesn’t have a lot of support for handling things like edge computing, interfacing to other network assets, such as cloud-based predictive analytics, and machine-learning applications. If you’re concerned about future proofing your design to work with these types of applications as they become more prevalent, a higher-level language might be the right path to take.

In the end, traditional ladder logic is a great tool for automating simple, repeated control of basic I/O points. But if you’re looking for more advanced functionality and capabilities, not to mention a wider availability of programmers to support the application, it may be time to look at VB.Net or even some of the other languages and tools out there, like JavaScript and Node-RED.

Mike Bacidore is the editor in chief for Control Design magazine. He is an award-winning columnist, earning a Gold Regional Award and a Silver National Award from the American Society of Business Publication Editors. Email him at [email protected].