Programmable logic controllers (PLCs) have remained the industrial controller of choice among control, automation and design engineers. PLCs are often referred to as the master controller that sequences the main logic and manages network data on automated equipment. They’re considered the hidden workforce that silently executes ladder-logic instructions behind a closed electrical cabinet door. PLCs, however, are generally not installed or integrated alone on automated machines.
Third-party products, such as servo motors, vision systems, testing equipment or robotics, are often used to complement a PLC. These complementary devices are referred to as the slave components that work in harmony with the automated systems and are controlled by the PLC in a master/slave relationship (Figure 1).
Conceptually, integration of third-party devices consists of discrete-wiring I/O to handshake signals between the PLC and third-party controllers (Figure 2). As technology evolved, fieldbus became the integration method of choice for connectivity and sharing of memory mappings between a master PLC and its slave devices.
Even at this level, the concept of data exchange happens in a manner where each device is treated individually or managed separately using each device’s configuration or programming software. PLCs have a programming software suite that must be learned by an engineer, along with other third-party software to program and configure a slave device that will connect to the master PLC. The old-school method of integrating the master and slave devices has been the de facto standard in industrial automation. This entails an engineer writing code in the third-party device and writing ladder logic in the PLC manufacturing software. The software code then has to interact with each other, often referred to as “software handshaking.”
Writing custom handshaking software between multiple devices has been cumbersome over the years. When an engineer wants to integrate another third-party device, the whole process of writing custom code must be thought through and debugged. Most engineers have this thought process engrained in their minds on how to sequence and interlock separate controllers, becoming somewhat of a standard mindset.
The pain level of integration
The problem with this old method of integration is that it’s a point of pain for engineers as they must continually learn a new third-party software package or attend a vendor training seminar to properly write software for the third-party devices. In an industry that demands a great deal of time from a custom machine integrator, engineers simply don’t have time to learn about a new third-party device. This is a large deterrent for potential first-time users. They’re reluctant to try new vendors because of the learning curve involved in understanding how the slave device integrates and communicates with the existing PLC system that’s designed into an automated machine as the main controller. This pain level creates additional costs in a project scope as engineers are forced to learn new software devices, directly impacting engineering time quoted on a project.
Over the past decade, fieldbus has advanced in sharing software memory mappings between the master PLC and third-party slaves. Today, the logic concept still stands that the master PLC is written to sequence the main control on the automated machines as the third-party slave devices have code written in a non-standard ladder logic format. This is, however, dependent on which kind of a device is handling the auxiliary process. In some cases, third-party devices are written in structured-text language sets that must be treated as a stand-alone process. These software subsystems must be written to act independently of the main PLC architecture. Therefore, the pain level of learning comes into effect, as engineers must learn how to write code in these third-party devices that are often not coded in the same way as the main PLC ladder-logic standards.
This exchange of information is generally a single bit level flag that is set in the main PLC from a ladder diagram rung, which instructs the slave devices to go or start the auxiliary process. At this time, the ladder sequence in the PLC must wait for a confirmation bit from the third-party device indicating its process is complete. This is a low level of data exchange, and extracted information is vague once its task is complete. As automation and technology have evolved, the need to share detailed information about third-party process controls has become more demanding in terms of preventing failures or logging statistical data about a part in production. Because of simple mapping concepts of the bit-level exchanges, it can be difficult to extract the scientific data of actual results from third-party processes to and from a PLC’s memory mapping exchange only.
New concepts of robotic control
How do you change the mindset regarding third-party control? With a robot controller, what if there were a way to embed direct control of third-party devices into PLC ladder logic? This type of control methodology would be a different concept or approach in a control scheme. By creating function blocks that communicate with the robot controller directly in ladder logic, it simplifies the integration handshaking between multiple devices such as a PLC and a third-party controller. If you could simply make the robot move with a single ladder-logic function block, this would solve all the issues of integration and eliminate the frustrations of learning another software package.
Allen-Bradley PLCs from Rockwell Automation have provided the ability to create control function blocks called add-on instructions (AOIs), which allow third-party vendors to create control or function blocks that are imported into the PLC. However, not all AOIs are created equally. Some AOIs have been created that try to emulate the old-school integration concept. These can make it easier to interact and integrate with a robot controller, but code still has to be written in the robot controller before the robot is instructed to move via the PLC. How can vendor-provided AOIs take the integration to the next level?
This is done by changing the concept of that interaction to something that simplifies the control of a robot where the PLC commands the robot directly without the need to learn or write a single line of code in the robot controller. It would be a significant improvement to provide PLC programmers the ability to directly control their robots in an integrated manner within the PLC software and sequence direct robot motion from within a ladder-logic instruction block. This is exactly the approach that we’ve taken with our RCX240 controller connected via Ethernet/IP to an Allen-Bradley PLC (Figure 3).
In our controller, special firmware accepts command codes from the PLC ladder-logic AOI blocks. It commands a Yamaha robot to move in the same manner as if a robot programmer wrote Yamaha code using structured text scripting (Figure 4). Specially designed AOIs can create and generate the command code automatically that the RCX240 controller understands and interprets. These commands are turned into instantaneous robot actions.
The AOI blocks are designed to send information that break down sequence control to an upper level code that behaves like an application programming interface (API). AOIs receive programmer parameters that direct the robot to move, change parameter settings or send information to the PLC when requested. For example, if a PLC ladder AOI block was executed in ladder logic, this block receives direct Cartesian millimeter values in the form of x, y, z and r values, along with a speed parameter (Figure 5). When the ladder-logic block goes true, only these parameters are sent to the robot controller, which then processes this information to handle the motion command and moves the robot from where it is to the newly instructed position in 3D space. By controlling the sequencing in ladder logic, the PLC programmer can move the robot around in the work cell with AOI blocks.