Centralized controls: Smart software, networks trump smart hardware
Back to the software side, using a unified PC-based control system is the catalyst to leverage the full power of modern multicore processors to simplify the control architecture and process algorithms centrally. With such software, real-time tasks can be distributed to different processor cores. For example, the PLC run time can run on one core, while motion control and HMI, respectively, run in a second and third core. Tasks are individually assigned to a core, and utilization ratios of those cores can be specified individually. Using this "core isolation" makes individual cores "invisible" to the operating system (OS), enabling them to be used exclusively by real-time automation and controls tasks. Resources on those isolated cores are then fully available for the control software to use for algorithm processing, motion control, communications, or other functions. The OS only can use the core(s) assigned to it and, therefore, the isolated core(s) can be used by the unified software without influence from the OS. Multicore utilization and isolation is quickly configured from within the programming environment.
Optimum utilization of PC processing power can be achieved with a motion control toolset. Repetitious and laborious programming of individual drives has been an optional activity for several years. Available software makes it possible to program and parameterize all drives on a machine on the central controller as far back as in the 90s. With more recent advancements, the capacity of a standard PC CPU enables the position control loop to be calculated on the central controller, rather than in a separate motion control CPU or motion card. In this case, servo drives or stepper drives only need the ability to close the current and torque loop, while closing the position loop in the programming software. This makes it possible to use more cost-effective drives that have a smaller footprint, as well as facilitating easier gearing of an axis or the ability to electronically cam axes together. This can eliminate costly mechanical devices and makes the system far more flexible than is possible with mechanical cams. This power and flexibility make it possible to position many axes simultaneously, add robot kinematics, and execute interpolated motion based on G-code, all concurrently on one PC-based controller. These motion tasks can run on the same controller, either on separate CPU cores or on the same CPU core, all executed in real time. This eliminates the need for separate motion control hardware and logic control hardware. In addition to previously mentioned methods, these can be programmed using a wide range of available software tools, including the typical PLC programming languages, PLC Open function blocks, C++, and more.
Another example where central control reduces the amount of required hardware is in the area of condition monitoring. Among other tasks, these systems can record vibrations of motor bearings, shafts, or other mechanical parts of the machine. This data is analyzed to detect wear and damage to machine operations or hardware before a breakdown occurs. Traditionally, condition monitoring is also accomplished using specialized black box hardware that processes the signals with a typically limited feature set. If more functionality is needed, additional hardware modules often must be added to the system, complicating matters in the ways discussed previously. Alternatively, by using more standard signal input devices, additional functionality or processing algorithms can be added in software rather than in highly specialized hardware. It's possible to gather condition monitoring data via I/O terminals that have the same physical format, network, and software environment as "regular" analog and digital I/O.
Outsmarting dedicated "smart" devices
Powerful centralized controllers combined with smart software and a deterministic network such as EtherCAT enable engineers to add other kinds of devices to the primary network that were perhaps more difficult to integrate in the past, such as temperature controllers. Temperature control is another example of a solution traditionally implemented using stand-alone black box hardware that is connected to a thermocouple as an input and has an output to control the heater/cooler. This piece of hardware typically has only a few navigation buttons, but many parameters that must be set to work optimally for the application. Often, these settings are set in the controller by the machinery OEM and the documentation of these settings can be difficult to properly manage and use in the long run when it's needed most. Selecting an EtherCAT master in software and using standard EtherCAT I/O hardware in this temperature control example will give access to hardware device parameters from within the same development environment used for the overall automation and controls programming.
This also facilitates access to the slave devices' parameter "start-up lists." Once an EtherCAT slave device is configured, those parameters can then be moved into the start-up list. This list of parameters, and their values, will be automatically loaded into the device as the EtherCAT network is initialized. This will happen either on power up of the controller or upon manual reactivation. Replacement of an EtherCAT device is as simple as powering down the equipment and installing the new device. Once the machine is powered up, the parameters will be restored to the new device, greatly reducing equipment downtime.
Additionally, by bringing the parameterization of the hardware as well as the control logic into a powerful, software-based platform, other useful benefits become available to the OEM and end user. For example, programming software can integrate seamlessly with revision control software such as Microsoft Team Foundation Server, GIT, or subversion software. This means that once parameter values have been decided on and stored in the start-up list, the device settings can be archived and revisions controlled along with other project elements such as the PLC program, safety configuration, or even servo drive settings. This archive of the parameters can be imported and applied to future projects using that device type. This extends the strategy of code reuse further than PLC function blocks, all the way down to device configuration, which enables much more efficient use of engineering time.
Machine architectures will always require a wide range of different field devices. At the beginning of system design, however, engineers should select a core control platform that minimizes complexity. It is most efficient to program as much system functionality for as many devices as possible in as few software platforms as possible-ideally, just one. It is also critical to leverage one system-wide network that does not require managed switches and routers, which is driven by one software platform on one hardware controller. Specifying the devices to be used on that network should always allow the reuse of parameterizations and enable automatic re-parameterization upon hardware replacement, while sending the data back to a central controller for processing. Following these points during system design will improve the odds of success and competitive advantages through enhanced architecture simplicity. More streamlined hardware and networking architectures are inherently easier to implement, support, and maintain.
- Daymon Thompson is TwinCAT 3 product specialist, Beckhoff Automation. Edited by Mark T. Hoske, content manager, CFE Media, Control Engineering, email@example.com.
- PC-based control, using a unified programming software, simplifies system design of machine architecture.
- Use one system-wide network that doesn't require managed switches and routers.
- Reusing device parameters helps with enhancements, maintenance, and upgrades.
When was the last time you reexamined machine architecture? Is it enabling or disabling your goals?
This article online includes more information, an added graphic, and related links. For more information: