Control Technology Virtual Controls for Motion And Robotics

Related Vendors

CODESYS GmbH A member of the CODESYS Group

FAULHABER Drive Systems

Automation with virtual controllers promises considerable savings potential in terms of procurement, maintenance and operation compared to conventional control technology. But what about applications in which, for example, coordinated movements have high requirements in terms of real-time behavior?

The first applications with virtual controllers are now in productive operation: hosted on IT servers, they are replacing physical PLCs in Audi AG's production lines, for example. A major advantage of virtual controllers over hardware solutions is that they are much easier to maintain. Security updates can be rolled out much more quickly and comprehensively in order to harden production systems against targeted or random attacks. And because virtual safety controllers such as Codesys Virtual Safe Control SL are now also available with IEC 61508 certification for SIL3 applications, there are no longer any restrictions on their use.

Nevertheless, doubts remain: if virtual controllers are operated on remote industrial PCs (IPCs) close to the machine or even on remote servers in the data center, can real-time applications with high performance and jitter requirements still be implemented? Especially if coordinated movements are required, as is the case with motion controllers, CNC and robotics controllers. Can larger distances between the controller and drives or I/Os be bridged?

Gallery

Suitable servo drives with digital fieldbus interfaces are required to implement coordinated movements for motion, CNC or robotics tasks. Due to their real-time capability, CANopen and increasingly Ethercat have established themselves as bus systems. They are implemented by many manufacturers, meaning that there is a broad portfolio of compatible drives from different manufacturers to choose from. The motion solution integrated in Codesys alone offers specific drivers for CANopen and Ethercat drives from more than two dozen manufacturers as well as generic drivers for CiA402/CoE and SoE-compatible systems.

Motion, CNC And Robotics on PLC

Whereas in the past, dedicated controllers were used to control coordinated movements, the approach points of the drives and their dynamics can now also be calculated in the PLC and transmitted via fieldbus. This reduces both hardware requirements and costs. On the hardware side, a suitable CPU performance and available interfaces on the PLC are essential prerequisites for this. If the performance of the controller used is insufficient, a change to a more powerful model is necessary - with consequences that can be expensive and time-consuming. When estimating the performance requirements of an application, it should also be checked very carefully whether motion control, CNC or robotics functions are required. The selection of suitable controllers can then be filtered according to the available performance. SoftPLC or virtual controllers offer significantly more flexibility here.

Of course, the performance reserves of IPCs or servers with several CPU cores are also used up at some point if several virtual controllers are executed on them. But compared to dedicated PLCs, the reserves are many times greater and can be called up as required.

An application case: During project planning, it becomes clear that a motion controller is required in addition to the logic controller. This can now simply be "upgraded" by obtaining a license. This allows complex axis groups to be used and the associated called library blocks to be enabled. With physical devices, this is simply unthinkable in many cases—a clear advantage for virtual control systems.

There are basically two architectural approaches for motion control, which have a strong influence on the requirements for real-time communication. In the central approach described above, the trajectory is calculated in the controller, with the individual axes following this specification. This requires constant, jitter-free communication. This contrasts with the decentralized approach, in which intelligent drives or subordinate controllers implement this motion function and only receive commands from the higher-level controller. This does not require cyclical, synchronized communication.

Industrial robots in particular can therefore manage without special programming languages such as Karel, Inform or Rapid. Instead, commands are sent from the PLC to the robot controller via standard fieldbus systems such as Profinet, which ensure the desired movement. While proprietary libraries such as mxAutomation were offered for this purpose in the past, the Standard Robot Command Interface (SRCI) is currently establishing itself as a comprehensive standard with a set of 115 commands ranging from linear movements to more complex commands such as force control. In such applications, the virtual PLC can be executed remotely without any problems and send its commands via fieldbus, as the actual robot control is still carried out locally on the robot.

Remote Industrial Drive Systems

Whether virtual controllers are suitable for centrally calculated motion tasks is therefore primarily determined by the communication between the controller and drive. In hardware-independent systems such as Codesys, the commands and services of the protocol stack are implemented in library blocks. This means that they are abstracted from the actual hardware used. This code is implicitly translated into native machine code for the CPU of the controller used with the aid of integrated compilers in the development environment together with the PLC application. It is only noticeable in the translation time and code size that the fieldbus protocol is now also included in the compilation in addition to the self-created logic program.

To ensure that this code can also be executed cycle-consistently with the PLC application, the drive system must be configured correctly in the programming tool. Depending on the system used, this includes parameters such as network addresses, bus-specific settings and technical properties of the axes and motors used, such as gear ratios, axis types and limits and their dynamics.

Secondly, a motion task must be created in the project with the appropriate cycle time and priority so that drives and motors receive their set values "on time" and run smoothly. By definition, the cable lengths of Ethercat, for example, may have a maximum length of 330 feet. If the number of controlled drives does not exceed 10 to 20, no further measures or devices such as additional switches or amplifiers are usually required. In addition to the hard real-time properties of Ethercat, this is one reason why the system is so widespread.

Motion Communication Over Long Distances

But what if virtual controllers are operated in a nearby data center where the required cable lengths exceed the limit? Or if a large number of drives need to be controlled or other data needs to be exchanged on the bus in addition to Ethercat communication, for example for a vision system? Ethercat providers offer special hardware for this purpose, which transmits data via fiber optic cables and thus bridges large distances of up to several kilometers. This allows motion applications to be implemented with virtual controllers that are executed in a remote server room, for example. Things get complicated if older bus technologies with sensors and actuators are installed on the machine at the same time, whose data cannot be easily embedded in the motion bus. It is essential that this data is also transmitted via the fiber optic cable.

Technically, this data can be packaged in parallel to Ethercat using special protocols and sent via the fiber optic cable. If the data is embedded in integrated circuits (ASICs), this data can be transmitted simultaneously via the fiber optic cable at almost any frequency without loss. This is exactly what an approach with the working title "Robo/TSN" from the company Missing Link Electronics promises. The system was funded as part of the BMFTR projects "Octopus Verano" and "6G Integrated Communication & Sensing for Mobility", among others.

It combines data from different bus systems via FPGA and transmits them deterministically. Depending on the medium, typically fiber optics, several hundred gigabits of data can be transmitted in the nanosecond range. In a patented process, the data is tunneled in such a way that all properties and information of the original system are retained: Functionally safe protocols such as FSoE (Fail Safe over Ethercat) or Profisafe can therefore be used without any problems.

Thanks to the encapsulation, the fieldbus information can even be transmitted securely in open IT networks in accordance with IEC 62443. What is important for users of motion and PLC systems such as Codesys is that, unlike other fiber optic systems, operation and configuration do not change as a result of this type of data tunneling. In initial tests, for example, the Codesys motion application was configured exactly as before: An available Ethernet port becomes the Ethercat master together with the connected I/Os and drives—during configuration, it is not noticeable that this port is tunneled through Robo/TSN.

The Network Card Ensures that All Protocols Are Tunneled

Further parameterization and project planning does not change in comparison to use on a standard Ethernet port. What does change is the "network card": it contains the corresponding ASIC and provides Ethernet and other communication ports. Internally, it tunnels the configured data and transmits it via the connected medium. At the remote station, this data is unpacked again by a PCIe network card and made available as originally. The cards equipped with the ASIC are required both on the host computer, on which virtual controllers are operated, and in the remote control cabinet or in the machine parts in which the corresponding end devices are operated.

In the case of virtual control systems, the physical separation of the underlying computer systems and the drives required for motion control and robotics poses a challenge. However, these challenges can be solved—depending on the application and the components used by using standards such as Ethercat and SRCI. Or by using fiber optic cables as the transmission medium. Thanks to modern, integrated circuits, project planning does not change compared to local systems. This makes it clear that virtualized control technology can be used for all areas of application.

Design simulation for industrial robots

How to make your production more flexible with robotics