Flexible automation has found in programming languages its most powerful means of expression. These languages have become especially popular for programming machine tools, flexible transfers, robots, automatic machines, etc.

However, there is a whole category of machines, characterized by many axes that rotate continuously and must be synchronized according to more or less complicated laws of motion, which has not yet been able to conveniently enjoy the flexibility characteristic of today's automation. We refer, for example, to the following fields of application:

•printing machines

•textile machines

•metalworking machines

•paper processing machines

•woodworking machines

•in general synchronism controls

Mechanical solutions still dominate in these fields, such as, for example:

•cams of appropriate profile for storing a certain law of motion

•drums with cams and micros for storing programs

•mechanically made synchronisms, i.e., with main shafts from whose movement, by means of gears, all movements for the machine are derived

•more or less ingenious linkages

•etc.

Electronic solutions are then, normally, analog, or derived from analog, unless the digital solution is indispensable; for example, in the synchronism control of two slave motors.

Evidently, under these conditions, the flexibility of the systems, that is, the ability to adapt to new production requirements, is very low and, in any case, linked to time-consuming and, above all, expensive mechanical operations. Costly in itself and costly above all in terms of lost production.

Similarly, centralized management of production in both its managerial and diagnostic aspects turns out to be impossible.

Goals

Robox SpA, building on its experience in motion control gained in robotics, has realized the R3 language for programming the work cycles of these machines.

The R3 language offers many advantages, such as:

•returns usable Robox motion controller, developed for robotics, to the more general field of motion control and synchronisms on axes that can also rotate continuously

•it provides software solution to motion problems

•it allows easy integration of the machines thus controlled into the "automatic factory"

These machines, in general, are characterized by the number of controlled axes, axis being understood to mean a part of the machine whose motion can be controlled independently by an actuator.

The actuator will typically be a CC motor, a brushless motor, an hydraulic rotary motor, but also an induction motor, an hydraulic cylinder, etc.

A typical example is that of a coordinate transformation program for one or more axes, which must perform a series of calculations at a fixed rate, e.g., every 2 ms, taking the information from the master processor and returning the results in real time.

Advantages of languages

Solving problems by programming, that is, by writing software, offers countless advantages.

We recall the main ones:

•the description of problems, in this case laws of motion and operating cycles, is fast, simple and documented

•the time between the beginning of the design of a machine and fine-tuning is drastically reduced

•mechanical parts of machines have a much higher degree of standardization

•mechanical parts that are difficult to manifacture are eliminated

•machine reliability increases, in conjunction with a decrease in mechanical complications

•design errors are quickly and easily eliminated

•it is very easy to optimize machine modes of operation and thus improve operation or adapt to new requirements

•it is very easy to introduce modifications

Practically there are no disadvantages. The only potential disadvantage that may still exist is the necessity of having to change the way of designing and thus having to invest time in learning the new tools of the trade: computers, programming languages, editors, serial transmissions, compilers, etc.; as well as having to assimilate a whole new lexicon made up of software, listings, bugs, files, debugging, etc.

It is, however, a step that, sooner or later, must be taken by everyone, and therefore it must be taken now, since the time is more than ripe.

Programming

Programming machine movements in R3 language has many similarities with programming a PLC. In both cases the designer will have to:

•write a source program, that is, a list of operations to be performed by the machine, written in an appropriate language (R3 language in the Robox case). This is the design moment, i.e., the creative moment

•compile the source program using the appropriate compiler. The compiler, remember, translates the source program, written in a language close to human beings, into an object program, written in numerical codes understandable by the electronic controller that controls the machine

•load the object program into the electronic controller, an operation that is normally done using the serial or Ethernet communication ports

•check the operation of the machine and, if necessary, make changes to the source program

The fundamental difference between the R3 language and the ladder programming language is that the latter is designed for programming quantities of the attach/unattach type, i.e., for example, tele-switches that open and close according to signals coming from pushbuttons, micro-switches, etc., which, in turn, can be opened or closed.

The R3 language, which is designed to regulate continuous quantities such as typically positions, velocities, torques, but also pressures, temperatures, etc., accepts and handles equations that correlate variables of this type.

There is practically no limit to the sophistication of operations: the R3 language handles integrals and derivatives, multiplications, divisions, sines, cosines, etc.

Evidently, the R3 language will also be able to handle switch on/off operations like a PLC, that is, to solve Boolean type equations, but this is certainly a secondary activity, compared to the main activity, which is aimed at controlling with precision, smoothness, rapidity, and obeying more or less complicated laws of motion, the aforementioned kinematic and non-kinematic quantities.

The extension of the R3 source file must be .R3

The extension of the inclusion files must be .I3

Programming with the R3 language is done in three different aspects.

Rules

A first programming step concerns the description of the laws of motion of the axes. For example, in the case of a motor that must rotate in perfect synchronism with a second motor (electric axis), the description of the law of motion will simply be:

that is, the shaft position of the second motor must be identical to that of the first motor (and consequently the speeds will coincide with absolutely zero error).

If, conversely, two motors must have identical speeds minus a factor of K, the equation will be:

that is, the speed IV2 will have to coincide with the speed IV1 minus the K factor, and K can be any real number.

In the case then that a reel with a rocker is to be controlled, it will be written:

Equation number 3. says that the rocker's error is the difference between the current position (i.e., P) and the centerline position (i.e., P0).

Equation number 5. says that the velocity of axis 1 must equal KP times the rocker's error (KP = proportional gain) + KI times the integral of the rocker's error (KI = integral gain).

Equations 1, 2, 3, 4, and 5 are referred to in R3 language as "rules" and will have to be checked with sufficiently high frequency over time, i.e., they will have to be honored continuously by a timed interrupt. The rules will not be fixed, but will vary according to the operational cycles of the machine.

Asynchronous rules

Rules invoked asynchronously are also managed: invocation can be done either by changes in the state of a digital input at a programmable frequency or by position pre-calculation.

The handling of these rules and the rules themselves are executed in such a way that they are not interrupted by any event. For the smooth operation of the system itself, the user must take great care in writing these rules so that their execution is as short as possible.

Operating cycles (main)

A second programming concerns the description of operational cycles and auxiliary functions.

For example, wanting to program that, if the Boolean variable "forward" is true, the electro-valve EVa will be energized or, if not, the EVi will be written:

in this case, instructions should not be executed at a fixed rate, as in the case of rules, but whenever the program flow encounters them.

Categories of languages

The R3 language, as already mentioned, is a compiled language. The source program is translated by the compiler into an object program, and the object program, in turn, must be fed into the system memory.

The advantages of the compiled language are many; to make them clearer, let us recall that languages can be divided into three categories:

•interpreted languages

•compiled languages

•mixed languages

Interpreted languages

In interpreted languages, the various instructions, normally written in AscII format, are read and decoded at execution time. Execution will take place by calling appropriate routines in the memory (normally firmware) of the device.

The advantage of interpreted languages is greater ease of use, immediate executability, and easier debugging.

The disadvantage is the greater slowness of execution, the greater ease of making errors, and the lack of a "file" list.

Compiled languages

In compiled languages, the various instructions, still written in AscII format, are translated into object codes for the microprocessor that controls the controller and entered into its memory.

The advantages of compiled languages are among others:

•they allow maximum speed of execution of the program at the time of execution. This feature is extremely important in the R3 case for real-time solving of even very complicated equations

•they generate a file having the extension .LST (the list file) in which all formal errors are identified and documented and all useful information is given for subsequent program tuning

•ensure complete and exhaustive documentation of the program

Mixed languages

In mixed languages, the various instructions are translated into intermediate codes, which are not yet the object codes of the microprocessor that controls the controller, but are interpreted and executed by the resident software.

Mixed languages sometimes allow for the optimal trade-off, allowing speed of execution, ease of debugging, compactness of the generated object code.

Compilation

As mentioned earlier, the R3 language is a compiled language. The source program is translated by the compiler into hexadecimal codes executable by the microprocessor. The compiled version was preferred in order to give maximum priority to the speed of execution necessary to properly execute the instructions contained in the rules.

In the source file it is possible to introduce special instructions, called metacommands, which allow the compiler itself to vary, according to particular requirements.

The compilation generates, in addition to the object file, an .LST file containing general information, as well as a list of any syntactic grammatical errors contained in the source file. If these are major errors, the object file is not generated.

Robox Development Environment (RDE)

In order to facilitate the user in all these operations, a development environment called RDE has been developed. This development environment, which is usually hosted on Windows Personal Computers, though not being indispensable, creates the ideal environment for properly operating both the R3 language and the ROBOX Family modules.

Two types of programming

The R3 language provides for two types of programming.

The first type of programming is concerned with describing the laws of motion of the machine (rules programming).

The second type of programming, at the main level, concerns the description of the machine's operating sequences (instruction programming).

The rules should be executed at a frequency appropriate to the controlled process. By programming rules, only linear programming is permissible; no blocking loops or waiting for events should be used.

Clearly, the resources devoted by the controller to controlling machine movements (rules) will, in general, have to be much greater than those devoted to controlling operating sequences.

RULE-level programming

This level of programming is entrusted with the actual control of machine movements, in other words:

•the closing of position, speed or acceleration rings

•the control of any rockers

•the generation of appropriate trajectories

•the synchronization of multiple axes

•etc.

These functions must be described in the rules and must be verified by the "execution time" control with sufficiently high frequency compared to the bandwidth of the dynamics of the controlled process.

The modules of the Robox SpA family are designed to work with a rules update frequency ranging from 25 Hz to 2 KHz (default 100 Hz), which appears more than sufficient to control processes with bandwidths up to 200 Hz.

As mentioned, rule-level programming is given the task of describing the laws of motion of the machine.

In principle, a rule will relate to one of the n controlled axes, but it is permissible for a rule to describe the laws of motion of more than one axis. In order to be able to describe the laws of motion in the various operating states, it will be sufficient to write the different rules.

In general, three fields can be identified in a rule:

•REF

•MOTION

•AUX

In the REF field (optional) will be written the equations controlling the generation of the reference voltage to the servo drives (typically speed reference). If this field is omitted the control will use the standard rules.

In the MOTION field the laws of motion will be described.

In the AUX field will be described auxiliiary functions for which the same characteristic time requirements as for rules apply.

We repeat that the equations described in the rules are executed with a fixed frequency normally equal to 100 Hz, to which corresponds a scan period of 10 ms, with a maximum frequency of 2 KHz, to which corresponds a period of 0.5 ms. For each period, up to 32 rules can be executed.

MAIN-level programming

This level of programming is given the task of describing the operation of the machine.

Main-level programming is a classical type of programming, oriented toward the use of flowcharts. The user must define the flowchart(s) according to his needs and then convert them into R3 language instructions, an operation that normally presents neither conceptual nor practical difficulties.

To facilitate this, the R3 language allows multitasking main-level programming.

Up to 8 evolving programs can be described in parallel. All tasks have the same priority level, meaning that the available machine time will be allocated among all active tasks.

In order to facilitate the synchronization of the different tasks, an adequate number of global variables are available, i.e., accessible by the different tasks. Local variables can then be added to each task as needed.

When the control unit is switched on, only task #1 (autorun task) is automatically sent to execution. It will then be task 1 that will start the other tasks, if needed and if scheduled by the task 1 program.

While the program is running, it is also possible to disable one or more tasks by placing them in a waiting state. The system is also equipped with the ability to handle interrupts, i.e., external events at which the normal program must be dropped to allow such events to be handled with due speed.

The control of such an event is done within a RULE, and thus with a maximum latency time of nominally 20 microseconds. The rule in turn will force the execution of an appropriate user-written procedure at the main level.

Real time extended (RTE) inline operating system

The R3 language is supported in the Robox modules by an RTE real time operating system which provides among others the following basic functions:

•assigns the right partition of time to the evolution of rule-level programs

•assigns the right partition of time to the evolution of programs at the main level

•ensures the fundamental services at the axis control level

•ensures the fundamental services related to communications (RS232 RS422/485 ETHERNET)

•ensures the management (drivers) of a variety of I/O boards such as:

odigital input output boards

oanalog input output boards

oetc.

•ensures fundamental services at the diagnostic level

•enables the execution of asynchronous rules

Conclusions

To program in R3, the programmer will first have to assimilate its instructions. The instructions of the R3 language are the classic instructions of structured programming languages, with the addition of some specific instructions closely related to the problems for which the R3 language is intended.

Anyone familiar with programming languages such as Basic, C or others will take a few hours to assimilate the R3 language.

Anyone who is not familiar with the aforementioned languages but already has some experience in PLC programming will take a few days.

Finally, those with no experience whatsoever will be able to learn to program in a few weeks, provided they have a logical sense and are predisposed to mathematical sciences. Programming in R3 language then means knowing computers and being familiar with them.

The operator equipped with the above knowledge will sit down at a desk and begin to describe the application program for the machine of interest.

In this writing he will have at his disposal the so-called text editors, i.e., programs that allow text to be written, stored and corrected. The set of instructions written by the programmer will be called the source listing and will generally be easily understood by anyone. At this point the program will have to be compiled, that is, as already mentioned, translated into numerical codes understandable to the electronic controller.

This file will be called an object file. The electronic controller into which it is to be decanted will have to be connected to the personal computer via the RS232 or ETHERNET serial line with which every personal computer is equipped. The object program thus generated will be stored in the memories of the electronic controller.

The machine is ready to run, and the programmer will be able to verify that the behavior is as he intended. In general this does not succeed the first time: the operator will then have to check his program, find conceptual or formal errors, and correct them.

The R3 language and the RDE development environment returns this task particularly easily. Once the causes of the errors has been clarified, the developer will correct the source programs, recompile the program, and put it back into the unit memories.

Software requirements

Microsoft Windows 7 (x86), Windows 8 and 8.1 (x86), Windows 10 (x86/x64), Windows 11 (x86/x64) operating system.