Method for modularly adapting a programmable controller

Abstract

The invention relates to a method for modularly adapting a programmable controller, comprising: providing a basic runtime system; defining unambiguous references in the basic runtime system in a prescribed order (S1, S2, S3; 330, 332, 334; 402, 404, 406, 408, 410, 412, 414); providing at least one function object (100; F1, F2, F3; 320, 322) having one or more methods (104) to be implemented and having at least one function pointer to one or more of the methods, wherein each function pointer is linked with a defined unambiguous reference; and executing at least one of the provided function objects (100; F1, F2, F3; 320, 322) based on the linked unambiguous references.

Description

Technical Field

[0001] The present invention relates to a method, computer program, and computing unit for modularly adapting a programmable controller. Background Technology

[0002] In controller applications, particularly in automation controllers, the computational sequence is typically anchored fixedly within the controller software architecture. In such an architecture, the controller user has very limited intervention possibilities. While it's partially possible to modify the results afterward at individual bits of the computational sequence or define additional functionality in pre-defined elements, if this simple intervention is insufficient, new firmware must be developed and created. Similarly, parts of the computational sequence that are completely unnecessary for the local application cannot be discarded. Common data access in such systems is also limited by these intervention possibilities. All these characteristics make controller maintenance or modular functional distribution difficult. Summary of the Invention

[0003] According to the present invention, a method for modularly adapting a programmable controller with real-time capability, featuring the characteristics of the invention, is proposed. Advantageous configurations are the subject of the following description.

[0004] In particular, a method is proposed in which a base runtime system is first provided, in which explicit references are defined in a prescribed order. Then, at least one function object is provided, wherein the function object has one or more methods to be implemented and at least one function pointer to one or more of these methods, wherein each function pointer is linked to one of the explicit references defined in the base runtime system. Next, at least one of the provided function objects is executed based on the linked explicit references. In this way, function objects in the form of encapsulated object classes for executing program flow can be used in the controller, where the use of explicit references (hereinafter also referred to as segments) ensures the flow of multiple function objects in a matching order, without the need for all previous function objects to exist or be known. As function objects, any basic functionality for the controller can be used, such as various calculations, transformations, or individual control instructions.

[0005] In one implementation, the method may further include registering at least one new functional object in the base runtime system, wherein the registration includes: a description of the at least one functional pointer and an explicit reference linked thereto; and a description of the data elements used by the functional element. Thus, additional functionalities developed later, or developed by the customer or external vendor, can be added modularly to the original base system and integrated into the existing program flow at runtime (without restarting the control system), without necessarily having originally known included functional objects. By registering in the system, the additional functional objects can be used by commands (especially in programmable units).

[0006] According to an exemplary implementation, executable commands are formed from one or more of these registered functional objects. These commands can be used to form complete process steps from these individual functions of the functional objects, such as a defined motion flow of an actuator. Commands can be pre-given externally via a suitable interface, and the behavior of the controller and thus the behavior of the machine can be defined.

[0007] Furthermore, a data management module can be provided for commands that manage the exchange of data elements between functional objects included in the command, wherein the exchange of data elements includes at least one of the following: providing at least one data element through a functional object; or reading at least one data element through a functional object. This data management module allows data access to be allocated and temporally categorized within the command for any registered functional object and can also perform other tasks related to the data, such as the formatting or validation of the exchanged data.

[0008] When data elements are provided through functional objects, these data elements can be linked to one of the defined, explicit references in the runtime system, preferably to references in which corresponding steps (e.g., computation of the data element) are performed. Therefore, data elements can be assigned different computational states by being linked to explicit references. Preferably, each data element can be provided at most once for each reference to achieve explicit allocation. However, when each write access is assigned to a separate reference, the data element can be written to multiple times. Therefore, it is possible to abbilden the different computational states of the data element.

[0009] Therefore, for example, the target position of the command can be written in multiple sections: initially in the section "CmdData" as exactly the values ​​provided to the command as parameters; then in the section "AbsPosition" where relative values ​​have been converted to absolute values ​​(and thus only absolute values ​​are stored in this section); and finally in the section "Offsets" where these absolute values ​​are additionally modified by the programmed shift.

[0010] When reading data elements, one can then refer to one of the explicit references defined by the underlying runtime system. Therefore, each function object performing the read can choose which of these computed states of the data element it wants to access. Optionally, the target reference among the explicit references defined by the underlying runtime system can be specified when reading data elements, where the data element being read corresponds to the last data element provided before the target reference, thus including any unknown additional modifications prior to the target reference, which the function object need not be precisely aware of.

[0011] In the example above, the function object can now choose whether it wants the target position of the command as the original parameter (reading segment "CmdData"), as the absolute value (reading segment "AbsPosition"), or as the value after shifting (reading segment "Offsets"). If no shift is active (and therefore segment "Offsets" does not contain data elements), the data management module can automatically provide the data from the last segment before the desired segment (i.e., from segment "AbsPosition"). Therefore, the function object performing the read does not need to know whether shifting is actually active.

[0012] In other embodiments, at least one command parameter for a command can be detected, wherein the at least one command parameter can be invoked by a method of a functional object included in the command. The command parameters can be passed to the functional object, for example, from a data management module as data elements, where they can then be used in subsequent execution steps.

[0013] Additionally, it is possible that one or more of these functional objects form a command option. Such a command option can then be activated and cause one or more of the functional objects of the command option to be added to at least one subsequent command.

[0014] Here, for example, command options can be activated for a pre-defined number of subsequent commands, or only for the next command; however, command options can also be selectively activated for all subsequent commands until deactivation of that command option is invoked. Therefore, individual functions within a command can be flexibly enabled and disabled without continuously redeveloping the entire command.

[0015] An example of a command option is the aforementioned shift of the commanded target location. If the option is active, it is added to the next step of the computation chain. If not, it consumes no runtime and no memory. All other computation steps are completely independent of whether the shift is active.

[0016] In one implementation, an extension can be added to the base system, wherein the extension includes at least one of the following: one or more functional objects, one or more commands, and one or more command options. Therefore, the base system can be flexibly extended at any point in time, not only on the manufacturer's side but also specifically customized for determined customer applications. The installation of the extension is preferably possible without restarting the controller and is therefore very simple and quick to implement. Once the extension has been registered with the base system, the additional commands and command options can be used and invoked externally through a suitable interface.

[0017] In other implementations, a graphical user interface can be provided, which enables the display of the provided functional objects. User input, reflecting the selection of a functional object, can then be detected, and executable commands can be generated from the selected functional object. Such a user interface allows the user to implement additional functionality and motion flows of the controller in a simple manner without requiring extensive intervention in the development process. Here, the functional objects used can be part of the original base system and / or added later through extensions.

[0018] Preferably, these functional objects can form sub-functions for controlling, for example, one or more actuators, one or more sensors, or one or more drive devices. It is conceivable to modularly extend the basic principle of the controller through functional objects in virtually every controllable system, and in this way, controllers can be scalably built, particularly for automation systems, general-purpose machines, machining centers, and other systems, such as those with memory-programmable controllers.

[0019] The computing unit according to the invention, such as an automation controller, is particularly configured in terms of programming technology to execute the method according to the invention. Implementations of the method according to the invention in the form of a computer program product or computer program having program code for executing all method steps are also advantageous because this results in particularly low costs, especially when the control device performing the execution is also used for other tasks and therefore always exists. Suitable data carriers for providing the computer program are, in particular, magnetic, optical, and electrical storage devices, such as hard disks, flash memory, EEPROM, DVDs, etc. The program can also be downloaded via a computer network (Internet, intranet, etc.).

[0020] Other advantages and configurations of the invention are apparent from the description and drawings.

[0021] It should be understood that the features mentioned above and to be described below are available not only in the combinations described but also in other combinations or individually, without departing from the scope of the invention.

[0022] The present invention is schematically illustrated in the accompanying drawings according to embodiments and is described in detail below with reference to the accompanying drawings. Attached Figure Description

[0023] Figure 1 An example is shown where a command is formed from the selected functional object;

[0024] Figure 2 This schematically illustrates data access for functional objects in different sections;

[0025] Figure 3 This illustrates, according to one possible implementation, the data exchange between two functional objects of a command within the data management module; and

[0026] Figure 4 An illustrative view of the data flow is shown when commands are executed in different segments. Detailed Implementation

[0027] exist Figure 1 The diagram schematically illustrates an exemplary modular system for adapting a programmed controller according to an embodiment of the present invention.

[0028] This foundation primarily serves as the base system for the controller of an embedded runtime system, in which various standard functions can be implemented. Here, it could be, for example, the basic control functions for all types of automation systems. This runtime system can be provided as a unit.

[0029] To adapt and extend the system, function objects 100 can now be set up, which can essentially be compiled object classes. Function objects should satisfy defined interfaces for use in the runtime system. Here, a function object can either already be part of the base system and then linked to the runtime system, or it can be included in an extension of the runtime system.

[0030] Here, extensions can exist as commonly used libraries with predefined interfaces. When an extension is loaded, it can be registered with the runtime system, and the additional functionality included in the extension can be registered as well. Therefore, extensions can be installed retroactively and can be incorporated not only by the manufacturer but also by the end user of the controller and / or modularly. Accordingly, multiple extensions can be added to the existing system, for example, from different sources or at different times, or optionally removed or changed again.

[0031] Functional objects can similarly be registered in the runtime system at load time and are preferably available throughout the system from the date of registration, for example, also for additional extensions. Here, each functional object is assigned a specific name for identification.

[0032] Any suitable individual function of the controller can be implemented through a function object. These individual functions may, for example, involve indications of motion for actuators or machine axes, or specific calculation steps. Here, not only the function itself but also the registration of the system is performed within the function object. For each function object 100, internal data 104 and methods 106 are available, which are only available within the function object. Here, these components can be transferred to... Figure 1 Each of the functional objects 100a, 100b, ..., 100h shown herein should be understood to have different data and / or methods. These internal methods and data can be read, written, and / or invoked by all sub-functions within the corresponding functional object. Conversely, these internal methods and data are not accessible from the outside; that is, these functional objects are fully encapsulated. To exchange data with the outside, such as with other functional objects, a data management module and functional object access via a defined interface can be used, as described in more detail below.

[0033] Taking the controller mentioned earlier for automated systems or processing machines as an example, it can be configured as a predefined or subsequently introduced functional object, for example, with the following settings:

[0034] - Geometric motion functions, such as linear motion; circular motion; motion along cubic splines or B-splines;

[0035] - One-dimensional interpolation, such as interpolation for generating jerk-constrained velocity profiles with trapezoidal velocity orientations, or it could be based on sin 2 Function interpolation;

[0036] - Normalization and conversion functions, such as meter (metrisch) measurement, English (angloamerikanisch) measurement, and conversion between coordinate systems, such as polar coordinate system, Cartesian coordinate system, and other coordinate systems;

[0037] - Shifting, such as zero-point shifting, tool shifting, Helmert transform;

[0038] - Velocity interpolation with jerk limiting;

[0039] - Collision recognition, such as collision recognition in one-dimensional or three-dimensional form with appropriate tolerance;

[0040] - Location switching point;

[0041] - Switching drive modes, such as switching drive modes based on position or speed;

[0042] - Events, such as generating or waiting;

[0043] - Messtaster measuring head;

[0044] -Axis transformation;

[0045] - Additional transformations, such as cylinder liner transformations and end-side transformations;

[0046] - Rounding, chamfering, and beveling;

[0047] - Tool calibration;

[0048] - Axial coupling, such as gantry cranes, coupling via electronic drives, and flexible profiles;

[0049] - Compensation and correction.

[0050] It should be understood that, depending on the system being controlled and the desired scope of functionality, any other and / or additional functional objects can be used, which can form corresponding modular modules (Baustein) for the control program flow.

[0051] Preferably, functional objects 100 in command 120 are used. Here, a command can represent a logical unit that represents a step in the application's flow. Each command 120 can contain a predefined group of functional objects 100f, 100g, 100h that implement their functions. The functional objects used are specified when the command is developed. It is possible that these commands have already been defined on the manufacturer's side and pre-defined using the system. However, alternatively or additionally, commands can also be defined modularly based on functional objects, for example, by the machine manufacturer or even by the end user. It is also possible to add predefined commands afterward, for example, within the scope of functional extensions.

[0052] Examples of commands include: the motion flow of an actuator, such as the movement of a robot's actuator along a straight line to a point in space; switching on power for a drive unit in any device; eliminating a fault in an axis; and other processes. Here, simpler or more complex functionality can be implemented through commands by specifying the functional objects required for this purpose. Generally, these commands preferably form components of the sequential operation of the control application, which are executed sequentially by the runtime system.

[0053] To implement such functionality, commands can also include parameters such as the target position of the movement. Command parameters can be introduced as values ​​of data elements into one or more functional objects of the command and used accordingly, or they can be used as parameter settings for specific functions.

[0054] Commands can be pre-given from the outside via various common interfaces, such as: REST-API (Representational State Transfer Application Programming Interface); OPC Unified Architecture; SPS (Synchronous Programmable Controller, e.g., via functional modules); scripts (e.g., via Python-based extension libraries); low-level C interfaces, etc.

[0055] To facilitate the sharing of data within commands, each command can be assigned its own data management module. This module is used for data exchange between different functional objects within a command. Because the functional objects within a command are not known at development time, they cannot communicate directly with each other. The data management module can handle all functionalities, such as type checking and all types of data access, i.e., read access, write access, and / or call access. Additionally, the validity of these data elements (write first, then read) can be ensured via this module.

[0056] To consistently control flow and access within such a system, multiple sections can be defined, which are explicit references within the runtime system. Each section can be identified by an explicit name or qualifier. These sections have a defined order. Similarly, additional sections can be defined and added to the existing order, for example, through registered extensions. When new sections are introduced, these sections are made globally known and ordered within the underlying system.

[0057] Examples of sections in an exemplary controller for a machining machine include: input of command parameters; end of geometric processing; and availability of the calculated nominal position. Of course, any other sections and additional sections can be defined, which can serve as suitable reference points for the functional objects being performed.

[0058] Furthermore, these function objects have defined interfaces. Here, a jump is a function pointer (Funktionszeiger) that is a defined interface to a method in the function object. Each function object can include any number of jumps. When a command is accepted into the system, all function objects to which it belongs are created (anlegened). Then, each function object calls the interface function, which implements registering multiple jumps in the runtime system.

[0059] For each jump of a function object, the following section should be defined here, in which the jump should be invoked. By assigning jumps to sections with a defined order, the execution order of these jumps is specified across all function objects without needing to already know the function objects themselves.

[0060] Furthermore, segments can be used to represent different processing states of data. For this purpose, data is linked to segments upon provisioning or writing, and these data exist from that segment onwards. Typically, this involves segments where a jump or method is run, which computes the data. Here, the functional object can further provide existing data elements in subsequent segments, where the original, initially provided data elements preferably remain available, i.e., are not replaced. The combination of data elements and segments represents the computational state of that data element (addressed by a data identifier).

[0061] This applies not only to data provided via an interface through the data management module, but also to the registration of read accesses, thus preferably requiring a description of the segment to which it belongs. Therefore, the data stream can be verified. The order of these segments can be determined, for example, automatically based on the data stream or defined in detail through configuration.

[0062] During reading, data can then be either directly linked to a segment or defined using a target segment. When permanently linked to a defined segment, other functional objects of the data element must be accurately written within that segment; that is, the exact data element must be requested within the specified segment. Conversely, if a target segment is defined, it specifies that the data element must be written up to that segment.

[0063] Depending on the implementation, one of the variations of the link between data and segments may be predefined, or a suitable syntax may be used, for example, to distinguish between hard-linked data and data with target segments during access.

[0064] The application of the target segment according to the second variant allows for flexible responses to additional functional objects. If a functional object requests data elements with a pre-given target segment, then any number of other functional objects may have modified the data elements in the previous segment.

[0065] exist Figure 2 The image shows an example of such an application where data is linked to a target segment.

[0066] Here, for example, the following segments S1, S2, and S3 are defined, and these segments are pre-given as references in the runtime system in the order described above.

[0067] Furthermore, consider two functional objects F1 and F2. Functional object F1 has a jump out in segment S1 and writes data element D there. Functional object F2 has a jump out in segment S2 and similarly writes the same data element D there. Thus, the system provides two processing states for data element D in segments S1 and S2. A third functional object F3 operates in a jump out in segment S3, and this third functional object can now, for example, perform read access to the data. This functional object can specify whether it wants to read data element D, D(S1), from segment S1 and therefore wants to read the result of functional object F1, or whether it wants to read data element D from segment S2 and therefore wants to read the result of functional object F2. In other variations, replacing the fixed link in functional object F3 can also specify that the last provided result of D before the target segment S3 should be read. This variation achieves that the last written processing state (Bearbeitungsstand) of the data element is always read. In the current situation, if function object F2 has been executed or exists in the relevant command, then function object F3 obtains the result of function object F2 and thus obtains the processing state D(S2); otherwise, it obtains the result of function object F1, namely D(S1).

[0068] If data remains unmodified in a segment, in one implementation, the data is further inherited into subsequent segments, so that, in the example above, the last written data element D from segment S2 can be inherited into segment S3 and subsequent segments and can be read out upon access. Therefore, the read function can be controlled via the desired segment: which computational state the read function wants to access. Thus, for example, an unmodified target position can be accessed when reading the target position in the first segment, while the target position can be modified with an active zero-point shift when reading the same data element from a defined second segment. If no zero-point shift is activated, the inherited data element from the first segment can also be read from the second segment. Therefore, if the shift is active, the function obtains a modified value when accessing the target position in the second segment, and if the shift is inactive, the function obtains an unmodified value when accessing the target position in the second segment. Developers of the corresponding functionalities do not need to consider zero-point shifting here, because the two functionalities are decoupled in this way (entkoppeln). The possibility of selectively activating individual functional objects is further described below.

[0069] Data exchange between methods within or outside a function object does not need to be accessed through the data management module, but can be done through the function object's private members.

[0070] Depending on the implementation method, other mechanisms may be used to ensure data communication. For example, it may be preferable to stipulate that each segment and data element is allowed to be provided (published) only once, thereby allowing for explicit allocation via the description of that segment.

[0071] Similarly, it can be stipulated that in each segment, write access must be performed before read access, thereby ensuring that the functional object accessing the specific processing state of the data element also obtains the final result, which may only be provided in that segment.

[0072] Alternatively, it can be specified that read access is protected and write access is no longer possible.

[0073] According to one implementation, strict type checking can be used in addition, especially for data exchanged between functional objects. This means that, in addition to the basic data types of the language used (e.g., double, float, int), other data types can be defined such that, for example, the target position is always assigned to only one variable for the target position and not to the variable for velocity, even though both can be based on the same basic data type. Therefore, it is preferable to define additional, more specific data types in the system and then assign them to each data element. Thus, not only the basic data types but also the specific data types are checked to ensure data consistency. The degree of difference can be arbitrarily chosen. The definition of specific data types simplifies system maintenance and the possibility of expansion for users.

[0074] According to one implementation, a series of data types are predefined in the base system. Added extensions can then globally register new data types within the system, making those new data types available to all functional objects from that point onward.

[0075] exist Figure 3The diagram illustrates a command utilizing shared data management. Here, two functional objects 320 and 322 are used, one of which already exists in the base system 310, while the other can be added to the system via a subsequently installed extension 312. In the present case, for example, functional objects for circular path 322 and motion interpolation 312 may be involved, which together form a command for the circular motion of the actuator. These two functional objects can be registered in the base system, for example, at object module 314, as indicated by the arrows emanating from the functional objects. A command 300 can then be formed, which includes the two registered functional objects 320 and 322. To manage the shared data, the data management module 302 to which the command 300 belongs is set.

[0076] The flow of a functional object is predefined through multiple segments in a fixed order, in such a way that exits of these functional objects are assigned to these segments. In the current case, segments 330a, 330b, and 330c are, for example, assigned to the following flow steps: parameter validation, data preparation, and execution. The data used in the respective functional objects is exchanged here via the data management module 302. Here, as an example of circular motion, conceivable data is shown: dynamic limit values, target position, auxiliary position, path length, and other data that can be used as input parameters. These can be, for example, predefined in a fixed manner or introduced into the data used as command parameters 350. It is thus evident that the two functional objects respectively pass through fixed segments and read or provide data in each segment, which is then further used by the functional objects in other exits. For example, in the first segment 330a, data for position and orientation in the circular path functional object 322 is first validated, while in the next segment 330b, said data and other data are prepared. Within each segment, the corresponding methods in these functional objects are executed. It is also possible to provide data 344 written by functional object 322 (e.g., the path length calculated by that functional object) within a segment and then invoke it again by other functional objects within the same segment. This is achieved by preferably pre-setting all write accesses before read accesses.

[0077] The following section in functional object 320 shows the internal data transfer between segments 332 and 334, where the data management module is not included. Conversely, at this point in time, no internal data is transferred between these segments in functional object 322. Instead, functional object 322 retrieves a one-dimensional length 345 in the following segment 334 for execution, where the one-dimensional length was previously provided by executing the first functional object 320 in the same segment 334. Both functional objects also provide other generated data 346, 347, 348, and 349, which then collectively send the motion sequence to the actuator. This may involve, for example, velocity 346, acceleration 347, jerk (i.e., the derivative of acceleration) 348, or position adjustment 349.

[0078] Of course, commands can also include more explicit functional objects and more complex interactions performed through the data management module. However, commands can essentially also include a single functional object.

[0079] In other implementations, command options can be implemented. Here, this refers to a logical unit that modifies the command. Preferably, the command option also internally includes one or more predefined functional objects that implement their own functions. Alternatively, the command option can be implemented using exactly one functional object. Command options are generally pre-defined through the same interface, such as commands (REST, OPC-UA, SPS, Skript, Low-Level C).

[0080] Optionally, command options can also include parameters such as a set shift value as a parameter value for tool shifting. If a currently active command option is predefined, a new option with the described parameters can overwrite an existing option, thereby adapting the parameters of the command option in such a way as possible.

[0081] In the example scenario of a machine controller, possible examples of command options include axis transformation, tool shift, or transition between two motion commands. The functionality. Generally, each function object or each group of function objects can be used as command options.

[0082] Command options can be persistently activated, meaning they remain active until explicitly deactivated, for example, by a corresponding command. Similarly, command options can be effective only for the next command or for a pre-defined number of consecutive commands.

[0083] As long as a command option is active, it can generate an instance of its own function object in all subsequent commands. In this way, commands can be flexibly modified, and their functionality can be temporarily enabled and disabled. If a command enters the system, all function objects belonging to that command, as well as the function objects of all currently active command options, are thus annuled and added to that command.

[0084] The modular construction described here can be used in one implementation to allow end users or customers to independently construct additional commands and / or command options. Here, for additional commands, the functional objects set up in the base system on the manufacturer's side can be simply utilized; however, other functional objects can be developed specifically through extensions or embedded into the system as extensions provided for specific application purposes. After registering new functional objects in the runtime system, the new functional objects can be used to form new commands and / or command options. Here, it is not necessary to restart the entire controller; a system reset is sufficient and provides a significantly faster possibility for adapting the controller.

[0085] In an embodiment, specific functional objects, such as 1D velocity interpolation, can be provided on the manufacturer's side for accelerometer-limited speed control. This functional object can then be used in the command "The robot's actuator moves in a straight line to a point in space," which already exists in the base system. Additional functions or modifications can then be expected on the user's side, such as driving to a target position on a specific spline-bahn. For this purpose, other functional objects can be developed that perform trajectory interpolation via splines. Next, new commands can be created, including not only the original functional objects but also new functional objects for the spline-bahn, wherein the original functional objects have 1D velocity interpolation. The additional functional objects, the newly created commands, and some registered functions can then be aggregated into an installable library or extension. Once the extension is installed on the controller, new commands are preferably available and executable after a system reset.

[0086] As another embodiment, the combination of manufacturer-side functionality with functionality subsequently extended via command options is now described. Here, specific compensation functions, which are not available in the existing base system, should be provided according to the user's expectations. For this purpose, a corresponding function object, "compensation," can be implemented first, which may be specifically developed by the user or provided by the supplier. This function object is then used to form command options. The command options with their respective function objects are then introduced into an extension that can be installed or registered in the base system. After successful registration and, preferably, a system reset, the new command options can be invoked.

[0087] In the next steps, the command option "compensation" can now be permanently activated, remaining active until it is effectively deactivated. Next, the first motion command is invoked for linear motion. All functional objects belonging to the first motion command are now instantiated within the first command. Since the command option is active, its functional object is also additionally instantiated within the first command. Next, all functional objects of the first command are executed according to their segments, and a rated position is calculated in each cycle (Takt), which is modified by the "compensation" functional object and then output.

[0088] Next, a second motion command is issued for the circular motion. If the command option is always active, the same steps as in the first command are performed for the second command, namely, instantiation of all functional objects of the second motion command and instantiation of the functional objects of the command option, and output of the corresponding modified positions.

[0089] However, if the command option has been deactivated before the second movement command, the second command is instantiated without the function object of the command option and outputs the unmodified nominal position again. Therefore, additional functions, which are included in the command option, can be arbitrarily turned on and off in other commands. If the command option is not permanently activated, but only activated for, for example, a single subsequent command, then deactivation is not required and all other commands are executed again in the unmodified manner.

[0090] According to one implementation, different portions of the previously mentioned implementations may be visualized or otherwise shown in the user interface for the developer or end user of such a controller. For example, a graphical representation may be used to generate commands / command options from a functional object, as shown in... Figure 1Similar to how functions are displayed as block elements on the screen, the modular construction of commands is shown, for example, by shifting the desired function into the command. Here, one's own, for example, by extending the added function, can also be arbitrarily integrated. However, other representations suitable for a user interface can certainly be envisioned, such as text-based or pre-defined options based on a tree structure for combining suitable commands and options.

[0091] Similarly, users can visualize data flow, such as through a suitable user interface. Figure 4 The examples shown visualize data flows as directional graphs or otherwise, where the data flows operate, for example, based on executed commands. Therefore, it is possible to understand computational sequences with different functional objects, which in particular simplifies the development and adaptation of system components.

[0092] Here, Figure 4 A visualization of the data flow, which may occur in the embodiment, is shown below. On the left, segments 402, 404, 406, 408, 410, 412, and 414 are listed from top to bottom in chronological order. Here, in the instantiated command of this example, there are four functional objects, parts of which may also come from one or more command options. The access steps on the right side of the figure illustrate the functional object and the jumps used by that functional object in the upper half, while the linked segments are shown in the lower half. The arrows between the steps also indicate the passing of data elements or parameter values.

[0093] In the first stage, data and parameters are prepared.

[0094] 1. In the first section TST_input, 402, the command parameter 420 with the content {54; 23}, namely TST_TargetPos, is provided by the system in step 430, that is, by the command data management module.

[0095] 2. The job 1 exiting the first functional object DummySender uses the data element 420 (TST_TargetPos) from segment 402 in step 432. Here, both steps 430 and 432 are executed in the same segment 402.

[0096] 3. In the next section 404 (TST_PrepOffset), the second function object DummyOffset jumps out in step 434, reads data element 420 (TST_TargetPos), modifies the data element, and writes the data element again with its new value {64; 43} as the modified element 422.

[0097] 4. In segment 406, i.e., TST_PrepGeometry, the exit job1 of the third functional object DummyPath now uses this modified target position 422 in step 436 to calculate the trajectory length (17.3) and provides this trajectory length as TST_PathLength 424. Here, segment 406, i.e., TST_PrepGeometry, has been described as the target segment. The functional object may store additional data in its internal variables, but this additional data is not universally provided.

[0098] 5. To conclude the preparation, segment 408 also calls the exit job1 of the fourth function object Dummylpo, i.e., access step 438. This access step uses the previously calculated trajectory length TST_PathLength 424. This exit pre-calculates the velocity distribution and internally stores the associated data, but it is not universally available.

[0099] In the next stage, further calculations and data manipulations are performed on the final output of the command.

[0100] 6. In section 410, namely TST_Ecexlpo, the runtime system provides a current timestamp 426TST_CurrentTime with a value of (0.45).

[0101] 7. This timestamp 426 is also used in segment 410 by the exit 442 of the fourth functional object Dummylpo, i.e., job2. Based on the data calculated in exit 438, i.e. job1, and the current time 426, the interpolated length 428TST_InterpolatedLength (0.123456) is determined and published.

[0102] 8. The exit job2 of the function object DummyPath is finally called in section 412, namely TST_ExecGeometry, using the interpolated length 428, TST_InterpolatedLength and thus calculated in step 444, and the interpolated position 429TST_InterpolatedPos{24.21;-273.15} is calculated with its own internal data and provided to the system.

[0103] 9. Since no other exits are registered, the system can finally read the calculated rated position in step 446TST_Output in section 414 and send it to the drive unit.

[0104] It should be understood that the exemplary embodiments described above are merely used to illustrate different fundamental principles of the invention separately, and can be arbitrarily extended, modified, and combined with each other. In particular, command options can be used as described, for example, in all examples involving applications involving commands; arbitrary new functional objects and other sections can be registered; the data elements and processes described herein can be replaced by other data elements and processes to adapt them to the corresponding technical applications; and functional objects, commands, data elements, etc., as used herein, can be used to varying degrees in all examples.

Claims

1. A method for modularly adapting a programmable controller with real-time capability, the programmable controller being configured to operate a machine, the method comprising: Provide the basic runtime system for the programmable controller; In the underlying runtime system, define explicit references in a prescribed order (S1, S2, S3; 330, 332, 334; 402, 404, 406, 408, 410, 412, 414). Provide at least two functional objects (100; F1, F2, F3; 320, 322), wherein each of the at least two functional objects has one or more methods (104) to be implemented and has at least one functional pointer to one or more of the methods (104), wherein each functional pointer is linked to a defined explicit reference; A data management module (302) is provided for the executable command (300) formed by the at least two functional objects (100g, 100f, 100h; 320, 322), wherein the data management module (302) is configured to manage the exchange of data elements (340, 341, 342, 343, 344, 345, 346, 347, 348, 349) between the at least two functional objects (320, 322) contained in the executable command by using explicit references to the underlying runtime system. The exchange of the data elements mentioned above includes: At least one data element is provided through one of the at least two functional objects; and At least one data element is read through one of the at least two functional objects. The provision of the data element includes linking the data element to at least one of the defined, explicit references of the underlying runtime system. The reading of data elements includes: invoking a data element using a target reference in an explicitly defined reference of the underlying runtime system, wherein the data element read corresponds to the last data element provided before the target reference, and The executable commands are executed to operate the machine, wherein the at least two functional objects (100; F1, F2, F3; 320, 322) are executed based on the linked explicit references.

2. The method according to claim 1, further comprising: Register at least one new function object (322) in the underlying runtime system, wherein the registration includes: a description of the at least one function pointer and an explicit reference linked thereto; and a description of the data elements used by the function object.

3. The method according to claim 1, wherein reading the data element comprises: The data element is invoked with reference to a defined, explicit reference in the underlying runtime system.

4. The method according to claim 1, wherein the method further comprises: Detect at least one command parameter (350) for a command (300), wherein the at least one command parameter can be invoked by a method of the at least two functional objects (320, 322) included in the command.

5. The method according to claim 1, wherein the method further comprises: Command options are formed by the at least two functional objects; Activate command options; And add the at least two function objects of the command options to the next command.

6. The method of claim 5, wherein the command option is activated for a predetermined number of subsequent commands, or wherein the command option is activated for all subsequent commands until deactivation of the command option is invoked.

7. The method according to claim 1, further comprising: An extension (312) is added to the underlying runtime system, wherein the extension includes at least one of the following: one or more function objects (322), one or more commands, and one or more command options.

8. The method according to claim 1, further comprising: Provides a graphical user interface; Display the at least two functional objects; The input is detected, and the input reproduces the selection of the at least two functional objects; and The executable commands are generated based on the detected input.

9. A computing unit configured to perform the method according to any one of the preceding claims.

10. A computer program product comprising machine-readable instructions that, when executed on a computing unit, cause the computing unit to perform the method according to any one of claims 1 to 8.

11. A machine-readable storage medium having a computer program according to claim 10 stored thereon.

Images