This article aims to provide an overview of the evolution of programming systems for Motion Control (hereinafter MC), from those of three decades ago to the present day. It also seeks to clarify that a standard programming environment does not imply that the same tasks can be performed in the same way with any Programmable Automation Controller (PAC) that incorporates it..
Note: The chronological order may not be entirely accurate.
The first programming languages for Motion Control (MC) systems.
They were programming systems using mnemonic commands, such as MOVD (move to a distance), with control structures such as IF THEN, DO WHILE, subroutine calls and, in general, the necessary functions to structure the program. The oldest one I remember is the programming system of a positioning device from the manufacturer ELAU (now Schneider Electric), which was programmed from its own terminal as portable PCs did not exist in those times.
In the program shown in the image, the value 134.8 is assigned to the variable V1, and an absolute positioning is performed to its value. If input 1 is deactivated after the positioning is completed, subroutine U12 is executed. Otherwise, the program continues at line 40, where the speed is set to 80% of its maximum value.
In this case, we are dealing with single-axis equipment, which only allows for basic movements. As we move forward a few years, when having a portable PC became a reality, more capable programming software started to emerge. However, symbolic programming was not yet available. The number of variables and data types depends on the control equipment mapping. For example, from V1 to V64, there are non-retentive 16-bit integer variables, from G1 to G64, there are retentive boolean variables, from B1 to B64, there are non-retentive variables, and from F1 to F64, there are retentive variables. The availability of variables and data types varied depending on the equipment’s level.
The example program shown in the image corresponds to an ElectroCraft device (acquired by Allen Bradley) called IQ, which was quite good for its time and is likely still in use in some machines.
The execution speed was not very high due to the fact that these were interpreted languages. The CPU would load each command of the program, interpret it, and execute it. Additionally, the CPUs at that time were limited to a maximum of 16 bits. Typically, it would take around two milliseconds per instruction.
There were also some simple programmable positioners using G-codes, which made it straightforward for users with basic knowledge. However, the control capabilities were also quite limited in those cases.
The diagram displays a simple program, as an example, where the comments speak for themselves.
Motion Control (MC) Graphical programming languages.
Manufacturers were researching ways to make General Motion Control (GMC) technology more accessible to users, aiming for the most user-friendly programming methods possible. When it comes to being “user-friendly,” Allen Bradley has often been a step ahead.
Allen Bradley developed a graphical programming system called GML (Graphical Motion Language), where commands are represented by icons and users only need to input values such as acceleration, speed, position, etc., and connect them to establish the execution sequence. It is worth mentioning that even in those times, GML allowed programming of interpolations and synchronized movements of up to four axes.
These graphical systems can be somewhat deceptive as they may give users the impression that they have mastered MC technology due to their simplicity. However, they can be ideal for very basic applications that technicians with limited knowledge of this technology need to perform. For more significant applications, certain parts of the program need to be written in script, which fortunately the system already accommodates.
These graphical programming languages have become less popular as they do not meet the current requirements of Industry 4.0 machines.
Another similar example, which goes even further, is Bosch Rexroth’s Visual Motion. It is more closely tied to the application, and its icons can be considered higher-level in terms of functionality.
For example, in the control of an Unwinder, there is already an icon available that includes everything necessary to control the servo motor. It is simply a matter of configuring it by indicating whether there is a diameter meter, whether it is torque control, dancer control, etc.
And at the end of the millennium, Programmable Automation Controllers (PAC) emerged.
With the introduction of Programmable Automation Controllers (PAC), a significant step forward was taken. Firstly, in terms of architecture, as these controllers are multidisciplinary, there is no longer a need for a separate PLC and GMC. The PAC itself has motion control capabilities, allowing for the unification of all functionalities within a single program. Secondly, in terms of programming, symbolic programming with various 32-bit data types is available, limited only by the available memory. However, the most important aspect is the integration of all control functions into a single system.
To illustrate this, the following figure demonstrates an example of how motion control would be achieved using a PLC and an external GMC.
Basically, since the PLC itself lacks the capability to directly control an axis, it activates an output signal indicating the desired motion to the external GMC. Once the axis reaches its position, the GMC then activates an output signal indicating this back to the PLC. In the example, the PLC activates the output signal PLC_GMC_GoPlace, which connects to input I2 of the GMC. The GMC, in turn, activates output O2, which connects to input GMC_PLC_InPlace.
This handshake process and the need for separate programs between the PLC and GMC could be cumbersome. However, with the integration of PLC and GMC disciplines in a PAC, the application is significantly simplified. The program structure would be streamlined, as depicted in the image.
The example illustrates the program in ladder logic, but PACs comply with the IEC-61131-3 programming standard, which means that users have access to all programming languages according to their preferences.
Standard Programming Languages in PACs
Within platforms based on the Codesys standard and all those that comply with the IEC-61131-3 standard, the programming language options can include ST (Structured Text), FB (Function Block), SFC (Sequential Function Chart), CFC (Continuous Function Chart), IL (Instruction List), and of course LD (Ladder Logic).
What’s interesting about having all these languages is the ability to combine them according to the functionality of each part of the program. If it involves a (more or less complex) calculation, ST may be the most suitable language. For the “conductor” or main sequence, SFC might be the best choice. It also depends on the preferences of each programmer.
The reality is that machines are becoming increasingly complex, which means that programming requires techniques that are closer to the IT world. It has become common to develop many programs using OOP (Object-Oriented Programming), and in a few years, it will be unthinkable to find parts of a program written in Ladder logic.
Diversity of options
Some manufacturers have chosen to build their programming environment on a standard system, predominantly Codesys, while others have developed their own programming environments for their platforms. The main ones are Studio 5000, TwinCAT, Sysmac Studio, Automation Studio, EcoStruxure Machine Expert, PLC Designer, and TIA Portal. In some cases, the hardware works with standard operating systems like VxWorks or Windows, while in others, proprietary systems are used. Most of them are based on Codesys, and what is downloaded to the PAC is a compiled code. This means that without the source program, nothing can be done, although there is always the option to download the source code to the PAC’s memory, which is the only way to recover the program from the controller. In these cases, it is important to have good control over the source program and its versions on a server and to perform regular backups.
In the case of Studio 5000 or TIA Portal, a highly optimized code is sent for the PAC to interpret. This has the advantage of facilitating online editing and allows the program to be recovered from the PAC. The disadvantage is that its execution is not as fast as with other methods.
The difference lies in the libraries.
When we talk about MC in Codesys, we tend to lump everything together, but that’s not the case. Codesys is the programming environment, but each manufacturer offers its own motion control libraries. In most cases, these are the well-known PLCopen motion libraries. However, standard does not mean identical. The same function block (FB) will have more or fewer options depending on the capabilities of the equipment used, which will vary depending on the chosen manufacturer.
On the other hand, all the instructions from different manufacturers are quite similar. To perform positioning, the required parameters are the same since it is a physical matter, although one device may have more options than another. The following figure shows examples of blocks in Studio 5000. In many cases, the difference lies in the name of the function block (FB), but in others, there are significant differences in terms of capabilities..
There are also devices with “Premium” motion control libraries, and in this case, there can be significant differences in terms of programming ease and capabilities.
For example, let’s consider the task of performing something as “simple” as moving a rotary axis at a constant speed based on the value of the variable rVelFeed. Additionally, when the value of rVelFeed changes, the axis should immediately accelerate or decelerate to reach the new speed value. Furthermore, it is necessary for the axis to come to a stop at the position indicated by the variable rOrientedStoPos when the motion is stopped. Additionally, fault management for the axis is required. This scenario is depicted in the diagram:
Using PLCOpen Motion: In a very generic way, you need to instantiate a MC_Power To enable the axis, you need to instantiate an MC_MoveVelocity for constant velocity movement. You must detect if there has been a change in the value of rVelFeed and, if so, generate a new edge on the i_xExecute input of MC_MoveVelocity. To stop the axis and make it remain in the position specified by rOrientedStoPos, you need to calculate the necessary space to stop the movement based on the current velocity and deceleration. Compare the current position of the axis and check if adding the required braking distance will stop us before or after the desired position according to rOrientedStoPos. If we have overshot, we need to wait for the next cycle; otherwise, we can stop the constant velocity movement and initiate a positioning mode with blending to make the axis stop at rOrientedStoPos.
For the management of possible faults, you will need to decide which faults are more likely or which ones you want to detect, and write “a few” lines of code for querying the axis’s status and faults.
Para la gestión de posibles fallos habrá que decidir cuáles son los más probables y/o cuales se quieren detectar y escribir “unas pocas” líneas de código para la consulta de estados y fallos del eje.
With PacDrive 3: In a very generic way, you need to instantiate a single FB_AxisModule. This function block performs all the necessary functions for any type of axis movement, including error management and a DataLogger for logging all the events related to the axis. Simply “connect” the values of rVelFeed and rOrientedStoPos to the corresponding parameter structure, and the function block takes care of tracking the reference velocity and oriented stop without the need to write any additional code for that purpose.
In both cases, the application would have been developed in a CodeSys-based environment, but using the PLCOpen Motion libraries would have been more costly than using the AxisModule libraries. In this case, Schneider Electric’s libraries offer much more value than PLCOpen Motion.
Summary/Conclusions:
Over the course of three decades, motion control (MC) has made tremendous advancements. It has evolved from hardware with 8- and 16-bit processors, limited memory capacity of a few kilobytes, and execution intervals of 2 to 5 milliseconds, capable of controlling only a few axes. Today, we have 64-bit processors with virtually unlimited memory capacity, executing instructions in nanoseconds and capable of handling over 100 axes. Software advancements have progressed in parallel.
Currently, there is a wide range of MC offerings, and different systems have similar capabilities, making the choice not an easy task. We have seen that “standard” does not mean identical. In compiled systems, without the source program, there is nothing that can be done, but they execute code faster. Other systems are interpreted, allowing the upload of the PAC program but at the expense of reduced execution speed. For high-performance applications, some systems offer libraries that greatly facilitate programming and provide more possibilities. In terms of programming languages, object-oriented programming (methods, properties, inheritance, etc.) is increasingly being used, so it is advisable to acquire knowledge in this area.
