Controller embeds programming efficiency
A programmable logic controller (PLC) or other controller is selected based on its application, but choice should take into consideration the capabilities of the accompanying controller programming software platform, as this will have a great effect on quick and efficient coding.
It’s possible to start up the development platform, create a new project, and start writing ladder code from scratch with just about any controller programming software package, but this method requires configuration-on-the-fly and is not as efficient as other methods. However, some controller programming software platforms have built-in efficiencies. By design, these platforms lead the developer along the right path, reducing the effort needed to complete a program.
One approach combines two methods for more efficient programming: top-down configuration and device-centric concepts (Figure 1). Top-down configuration provides a clear path for the programmer by showing what is and isn’t needed when configuring a PLC project, all based on menu-driven selections. Device-centric concepts let devices handle common functions "behind the scenes," freeing the programmer from these tasks.
Examples and explanations of top-down configuration and device-centric programming can improve programming efficiency.
For some controllers, configuration is simplified using a top-down method (Table). In the table, the order of the tasks is by precedence, with each item in the list depending on the item or items above it. For example, everything below CPU configuration depends on how the CPU is configured. Serial port, port type, Ethernet input/output (I/O) master options and server options such as Modbus/TCP and EtherNet/IP explicit messaging are configuration selections typically available during CPU configuration. (EtherNet/IP is an industrial Ethernet protocol from ODVA.) These selections add necessary parameters to some or all the items below CPU configuration.
|Table: Top-down configuration steps|
|1. CPU configuration|
|2. I/O configuration|
|3. Module configuration|
|4. Device configuration|
|5. I/O mappings|
|6. Memory configuration|
Configuring the controller in the proper order helps everything below it fall into place, simplifying and automating some software development. Configuring a CPU as a Modbus RTU client only, for example, affects the items below by only exposing the appropriate parameter options, simplifying subsequent steps.
The development efficiencies realized by an orderly configuration lead directly to device-centric concepts. With these concepts, ladder code talks to a device in the middle, not directly to the hardware itself (Figure 2). A device is similar to a printer driver on a PC, where the driver (device) handles all the low-level details so a programmer can send data to a printer, without worrying about printer programming.
A programmer likely thinks of a device as a sensor, encoder, I/O module, variable frequency drive (VFD), EtherNet/IP module, remote rack, or a similar piece of hardware. In a device-centric controller, the devices are instead pieces of code between the program and the hardware. Using this concept, the device is configured, and it handles the details for control of the hardware by the controller, such as establishing communication protocols, handshaking, and defining memory requirements. Much of the hardware details are handled via configuration of each device, not with controller programming.
Once a device is configured, the program instruction talks to the device, not directly to the hardware. The instruction uses the defined memory, handshaking bits, and memory flags created during configuration of the device. The instruction also can talk directly to and from memory using bits and integers to make logic decisions. The instruction also can perform math functions and place the floating-point result back in memory, for example.
A device, such as a serial port, talks directly to memory as well. As data flows to or from a serial port, the device handles buffering and status flags in memory. The device handling the behind-the-scenes details is what makes the programming device-centric, with everything revolving around the device.
A server can be thought of as a device as well. It runs in the background, talks directly to the hardware, and moves data between the hardware and memory. Modbus TCP is an example of a server. It functions for the most part outside of the controller program, but can be accessed by it.
Put efficiency into action with devices
Regardless of the complexity of the hardware selected, the device provides a clean, uniform interface between the hardware and controller program. Each device is set up the same way, for example a Modbus/RTU or a general-purpose serial port, by following top-down configuration steps, which require selecting features and filling in a few blanks.
A typical application, such as a box diverter, contains several pieces of hardware that must be controlled. The application may include an encoder to synchronize the diverter gate to different box lengths, a motor controlled by a VFD, and a barcode reader to scan a conveyed box to determine its destination. Input and outputs also will be needed to monitor sensors for box detection, and to control pneumatic actuators, such as a lift.
As this box diverter application demonstrates, it’s not unusual to have several different pieces of automation hardware connected to a PLC, with each hardware component and its required connections defining the devices. However, in this instance, a controller with a top-down configuration and device-centric concepts is quickly configured, with much of this effort performed automatically.
If the controller lacks on-board high-speed inputs, a high-speed counter module can be used to count encoder quadrature pulses. This module is not a part of the CPU configuration, but it is automatically discovered in the second step, I/O configuration. The third step, module configuration, will then autofill the needed parameters with default values for the discovered module. Any edits to the configuration required can be made here during this step. The PLC will automatically handle the I/O mapping for the added module, and create the needed image register addresses.
The controller’s Ethernet port communicates to the VFD. Starting at the top of the configuration list, the Ethernet I/O Master is enabled as part of the CPU configuration step. This creates an entry in the I/O configuration, allowing IP configuration and other communication options. Nothing more is typically needed for this device’s configuration since the other parameters, like I/O mapping, all are done automatically.
The controller’s serial port is used to communicate with the barcode scanner using simple ASCII text strings. The port is recognized during the CPU configuration step where a general-purpose serial port is configured, including settings such as baud rate and hardware protocols such as RS-232. I/O and module configuration are not needed, and the device configuration is created automatically, providing a pre-configured interface with access to system resources. The memory configuration step automatically allocates memory for the device.
Multi-point discrete input and output modules are used to monitor and control the sensors and pneumatics. These modules are configured in a similar fashion. Some of these devices are easy to set up and some more complicated, but all use the same methodology. Configuration starts at the top of the table list and works downward, filling in only the parameters not automatically defined in prior steps.
As shown in the example above, a top-down and device-centric controller programming platform is quickly configured. Controllers with this type of programming software typically also provide more efficient instructions, such as proportional-integral-derivative (PID) loop and motion control blocks. There are thousands of uses for PID loops, so there is no one-size-fits-all solution. Some controllers have limited options, but others have improved PID instructions to increase efficiency by providing independent, modular, interchangeable, and run-time configurable methods to meet application needs.
Part of this improved efficiency is the result of breaking down the PID loop into smaller pieces. Instead of embedding all the PID parameters, such as filters, scaling, ramp-soak tables and alarm handlers, in one PID instruction, separate instructions are used to access the parameters individually to simplify customization of these control algorithms. These instructions also can include trend views for display to help with understanding of the control loop response, and to assist with initial tuning and troubleshooting.
Motion control instructions can follow a similar path, broken down into different levels of instruction complexity. Simple motion instructions allow quick application of basic move commands with minimal required configuration. Intermediate-level motion instructions provide more user-defined parameters. Advanced instructions enable selection or creation of custom move profiles, often through a simple configuration process.
Newer, advanced controllers are simplifying programming by enforcing a more top-down approach and using device-centric concepts. With proper configuration, much of the device interface between the controller software program and the hardware happens automatically and efficiently without the need to write code. Quicker configuration leads to fast programming, and this is enhanced with the wider variety of available instructions.
- PLC architecture can ease programming.
- Top-down configuration and device-centric programming help with PLC programming.
- Various devices can be programmed similarly.
Would decreased programming and less configuration help with your next project?