Method and development environment for generating control program for automation system

Abstract

The invention relates to a computer-implemented method (100) for generating a control program for an automation system, comprising: in a receiving step (101), receiving input data (207) for a control program (209) for an automation system by a development environment (200); in a first generation step (103), a graphic graph (211) in a graphic programming language is generated on the basis of the input data (207) by means of a graphic editor unit (201) of the development environment (200); in a first display step (105), the graphic graph (211) is displayed in a graphic editor unit (201) of the development environment (200); in a first conversion step (107), the graphic graph (211) of the graphic programming language is converted into a textual intermediate representation (213) of the graphic graph (211) by a conversion module (205) of the development environment (200); in a second display step (109), displaying a textual intermediate representation (213) of the graphic graph (211) in a text editor unit (203) of the development environment (200); and in a second generation step (111), generating the control program (209) on the basis of the text intermediate representation (213) of the graphic graph (211) in the graphic programming language and / or on the basis of the graphic graph (211).

Description

[0001] This patent application claims priority to German patent application 10 2023 126 332.3, the disclosure of which is hereby incorporated by reference herein.

[0002] The present invention relates to a method for generating a control program of an automation system and a development environment.

[0003] Graphical programming languages are known in the prior art for graphical programming of programmable logic controllers (PLC) in automation technology. Three graphical programming languages are defined in the IEC 61131-3 standard: ladder diagram, function block language and sequential function chart. The above-mentioned graphical programming languages allow user-friendly graphical programming, in which a graphical diagram can be generated graphically by adding and / or removing predefined graphical program objects as a graphical representation of a control program to be created for a programmable logic controller.

[0004] Various development environments for such graphical programming are known in the prior art. The development environments known in the prior art each comprise a graphical editor unit, in which a user can generate a graphical diagram by adding and / or removing graphical program objects predefined by the graphical programming language.

[0005] However, the development environments known in the prior art only allow graphical representation and programming of the above-mentioned graphical programming languages. Thus, the user is limited to graphical programming in the graphical editor unit.

[0006] Graphical programming has many advantages over textual programming, such as the relatively easy learning of the programming language. However, at the same time, graphical programming also has some disadvantages compared to textual programming.

[0007] It is therefore an object of the present invention to provide an improved method for generating a control program of an automation system and an improved development environment.

[0008] This object is solved by the method and the development environment of the independent claims. Preferred embodiments are indicated in the dependent claims.

[0009] According to one aspect of the present invention, a computer-implemented method for generating a control program of an automation system is provided, the method comprising: In a receiving step, input data of the control program of the automation system are received by means of the development environment, wherein the input data describe a graphical diagram of a graphical programming language, and wherein the graphical diagram graphically represents at least a part of the control program of the automation system according to the graphical programming language; In a first generating step, the graphical diagram of the graphical programming language is generated based on the input data by means of a graphical editor unit of the development environment; In a first display step, a graphical diagram is displayed in a graphical editor unit of the development environment; In a first conversion step, the graphical diagram in the graphical programming language is converted into a textual intermediate representation of the graphical diagram by means of a conversion module of the development environment, wherein the textual intermediate representation provides a textual description of the graphical diagram; In a second display step, the textual intermediate representation of the graphical diagram is displayed in a textual editor unit of the development environment; and In a second generation step, a control program is generated based on the textual intermediate representation of the graphical diagram in the graphical programming language and / or based on the graphical diagram.

[0010] This can achieve the following technical advantage: An improved computer-implemented method for generating a control program of an automation system. The method according to the present invention is performed by a corresponding implemented development environment having a graphical editor unit, a textual editor unit and a conversion module. The graphical editor unit allows graphical programming according to a graphical programming language. The textual editor unit allows textual programming of a control program according to the graphical programming language.

[0011] The conversion module allows conversion between a graphical diagram in the graphical programming language (created by means of graphical programming) and a textual intermediate representation of the graphical diagram.

[0012] The method provides for generating a graphical diagram valid according to a selected graphical programming language based on input data of the graphical editor unit and displaying it to a user of the development environment in the graphical editor unit. The graphical diagram represents at least a part of a control program to be generated for an automation system according to rules of the selected graphical programming language.

[0013] For this purpose, the graphical diagram comprises graphical program objects corresponding to program objects of the control program.

[0014] The conversion module converts the graphical diagram into a corresponding textual intermediate representation. In this context, the textual intermediate representation represents a textual description of the graphical diagram including the graphical program objects contained therein. According to the present invention, the textual intermediate representation is in a form readable by a user of the development environment.

[0015] The textual intermediate representation generated by the conversion module is then displayed to the user in the textual editor unit. Thus, the user can check the accuracy of the graphical diagram by viewing the textual intermediate representation in the textual editor unit and immediately identify any errors in the graphical diagram. This allows for an improved programming of a control program of an automation system based on a graphical programming language.

[0016] Specifically, when errors are identified in a graphical representation, users can correct or modify the graph accordingly by viewing the intermediate text representation, thereby reducing the computational power and runtime required for things like executing control programs. In addition to simplified programming, this also allows for improved control programs.

[0017] Furthermore, users unfamiliar with text-based programming languages ​​can more easily interpret program code based on graphical representations and more quickly detect and correct errors in the code or on the machine. Therefore, downtime of the automated system to be controlled can be significantly reduced. In return, experienced users familiar with all text and graphical programming languages ​​(such as software developers) will have more opportunities to generate code in a more efficient and purposeful manner if they can use text-based programming languages ​​for generation.

[0018] Finally, the method according to the invention provides a method for generating corresponding programmed control programs based on graphical representations and / or textual intermediate representations based on graphical representations. Therefore, control programs can be directly generated based on the textual intermediate representation of the graphical representation. This means that graphical representations do not require additional textual intermediate representations, whereas textual intermediate representations are specifically used for storing or compiling graphical representation-based control programs.

[0019] Conversely, the intermediate text representation previously displayed to the user for review and written in a user-readable form in the text editor unit is directly used as an intermediate representation to store control programs created from graphical graphs based on the graphical programming language and to compile the control programs.

[0020] This further simplifies the programming of control programs based on graphical programming languages, which use only the text intermediate representation of the graphical diagram to store and compile the control program, and additionally display the corresponding graphical diagram and allow the user to inspect the corresponding graphical diagram.

[0021] The use of text-based intermediate representations also ensures good compatibility of program code created with version control. Specifically, the created program code can be stored in text-based intermediate representations. Program code stored in this way can be easily managed within the version control system.

[0022] In addition, storing program code in text format reduces the amount of storage space required.

[0023] The method according to the invention also allows for seamless switching between text-based and graphical programming and representation. Developers can develop program code using either text or graphical programming, depending on their preferences or specific circumstances.

[0024] Even if the sequential control of an automated system is programmed in text format, it and its current progress can be displayed graphically to the user, for example, on a human-machine interface (HMI). This makes it easier to understand the program code and the processes within the automated system.

[0025] Furthermore, the text-in-the-middle representation allows for the complete copying, deletion, and moving of the entire executable object.

[0026] For example, a user can alter the behavior of machine control by modifying an executable program object, with the change being graphical. The user can then transmit the modified executable program object as coherent text (e.g., via email, fax, letter, dictation, telegram, or stone tablet) to a colleague. The colleague can then replace the active executable program object with the transmitted program object, thereby changing the machine's behavior in a single step.

[0027] In addition, text-based displays provide users with a clear overview, for example, by displaying a class in its entirety in a text editor, including the behavior of all the methods in that class.

[0028] In addition, this method allows for the simple generation of program code containing executable program objects with textual behavior.

[0029] For example, machine manufacturers may release various variants of the machine based on different combinations of parameters specified by the customer. These variants differ in both the physical design of the machine and its control program.

[0030] Based on parameters, variant-specific parts of the control program are generated as text by a code generator. This can also include graphical behaviors, such as variant-specific sequence control in the AS sequence language or variant-specific control algorithms in the FBS function block language. Unlike manual adaptation, code generation is automated and can be integrated into the ordering process.

[0031] Furthermore, this method allows for simple and quick modification of graphical program code by changing the textualized program code (e.g., using text search / replace functionality).

[0032] According to the present invention, the input data of the graphic diagram describes the attributes of the graphic program object of the graphic diagram and is suitable for being read by the graphic editor unit and allowing the graphic editor unit to generate the corresponding graphic diagram.

[0033] In this application, the graphical representation of a graphical programming language is a graphical representation of a control program that can be created by the graphical programming language, according to the rules of the corresponding graphical programming language. The graphical representation includes at least one graphical program object. The graphical program object is a graphical representation of the program object of the corresponding control program.

[0034] Graphical representations can be displayed graphically in the corresponding display unit of the graphical editor, according to the rules of the graphical programming language. The display unit is a software module of the graphical editor unit.

[0035] According to one implementation plan, the receiving steps include: In the first programming step, the graphical editor unit of the development environment receives graphical input commands from the user of the development environment, wherein the input data includes graphical input commands, wherein the graphical input commands include programming commands for adding and / or removing graphical program objects of the graph, and wherein the graphical program objects are partial elements of the graph and represent executable program objects that control the program.

[0036] This achieves the following technical advantages: the method according to the invention allows for graphical programming of the control program. In this case, the input data is provided by graphical programming commands entered by the user in the development environment. Therefore, this embodiment describes a situation where the user creates or modifies a graphical diagram by entering corresponding input commands in the graphical editor unit, for example, by adding or removing corresponding graphical program objects.

[0037] Therefore, depending on the situation, the input data is specifically created through user input commands during the graphical programming process, whereby the user can modify existing graphs or create new graphs from scratch according to the rules of the graphical programming language of the graphical editor unit. Then, as described above, the graph modified or newly created through the graphical programming process is converted into a corresponding intermediate text representation and displayed to the user in the text editor unit.

[0038] Subsequently, the control program to be generated is created based on the graphical representation created during the graphical programming process and / or based on the corresponding textual intermediate representation. In the illustrated implementation, the user can modify or regenerate the corresponding graphical representation by executing graphical input commands in the graphical editor unit according to the rules of the selected graphical programming language.

[0039] Then, the graphical diagrams modified or newly created during the graphical programming process are converted into corresponding intermediate text representations that can be read and displayed by the user in the text editor unit for review.

[0040] According to one implementation plan, the receiving steps include: The reading step reads a program file, which contains input data in text form for the graphical representation, wherein the graphical program objects of the graphical representation are described in text form by the input data; and the first generation step includes: In the second conversion step, the text input data is converted into a graphic using a conversion module.

[0041] This achieves the following technical advantages: In the described implementation, the graphical representation is generated based on a pre-stored program file containing input data. Therefore, the described implementation depicts a situation where a graphical representation, generated in text form and stored in a pre-stored program file during previous graphical programming, is read in the development environment and displayed to the user in graphical form and a text-intermediate representation within the graphical editor unit. This text-intermediate representation is generated through a conversion process and written in a form readable by the user in the corresponding text editor unit.

[0042] Based on this, the user can perform another graphical programming operation according to the above implementation scheme, and modify the intermediate graphical representation accordingly by adding or removing graphical program objects based on the described graphical input commands.

[0043] According to one implementation scheme, the method further includes: In the text programming step, the text input command from the user is received via the text editor unit of the development environment. The text input command adds or removes the text program object as the text representation of the corresponding graphical program object of the graphical graph from the intermediate text representation of the graphical graph. In the third generation step, a modified intermediate text representation is generated based on the text input command and the intermediate text representation of the graphical graph; In the third conversion step, the modified intermediate text representation is converted into a corresponding modified graphical representation of the graphical programming language, and / or, with the aid of the conversion module, the text modification of the intermediate text representation caused by the text input command is converted into a graphical modification of the graphical representation, wherein the text modification includes at least one newly added or deleted text program object, and wherein the graphical modification includes at least one newly added or deleted graphical program object. In the third display step, the modified graphic is displayed in the graphics editor unit instead of the original graphic, and / or the graphic modification in the original graphic is displayed; and In the second generation step, a control program is generated based on a modified intermediate text representation of the modified graphical diagram and / or based on the modified graphical diagram.

[0044] This achieves the following technical advantages: the described method allows users of the development environment to modify existing graphical representations based on text intermediate representations by performing text programming operations, thereby taking into account text editor units. Therefore, users can change the text intermediate representation of a graphical representation displayed in a text editor unit by performing text programming operations and thereby creating a modified text intermediate representation.

[0045] For example, this can bring substantial, practical, and immediate benefits during the programming process, because in the textual representation of program code, program parts can be automatically renamed, replaced, or modified. In graphical representations, such processes are much more time-consuming because there is no automatic search / replace functionality.

[0046] Therefore, users can input corresponding commands into the text editor unit to modify the displayed intermediate text representation. Text input commands include adding or removing text program objects from the intermediate text representation. According to the present invention, a text program object is a textual representation of a graphical program object of a graphical graph. Graphical program objects are predefined by the rules of a selected graphical programming language.

[0047] When the intermediate text representation is changed during text programming, the text editor unit receives the corresponding text input command from the user and modifies the intermediate text representation displayed in the text editor unit accordingly. This generates a modified intermediate text representation.

[0048] The conversion module then converts the modified text intermediate representation and generates a corresponding modified graphic. The graphic is then displayed to the user in the graphics editor unit.

[0049] Therefore, users can modify previously generated graphical representations and corresponding graphical representations by performing text programming processes in the text editor unit, based on input data, i.e., based on graphical input commands executed during graphical programming or graphical representations generated based on program files, and generate modified intermediate text representations and corresponding modified graphical representations based on this.

[0050] The modified graphical representation and the modified text intermediate representation represent the graphical and textual equivalents of the same control program to be generated. This also applies to the graphical representation and the corresponding text intermediate representation described above.

[0051] Therefore, the aforementioned embodiments of the method according to the invention provide users with the option to generate control programs in a selected graphical programming language during both graphical and text-based programming processes. Users can switch between graphical and text-based programming as needed, because changes made in the graphical editor unit are immediately reflected in the corresponding intermediate text representation, and conversely, changes made by the user in the intermediate text representation are immediately reflected in the corresponding graphical representation.

[0052] Therefore, regardless of which editor unit the user makes changes to, the graphical and textual representations always maintain a clear correspondence with each other.

[0053] This further simplifies the programming process significantly. Some processes involved in generating control programs are easier to execute in the graphical editor unit, while others are easier to accomplish via text. For example, using copy and paste to multiply program objects in a text-based intermediate representation is much easier than in a graphical graph, where each graphical program object must be multiplied individually and linked to existing graphical program objects.

[0054] Furthermore, this simplifies the resulting control program, as text programming in the text editor unit can be used to generate simplified graphical diagrams, resulting in a simplified control program with reduced runtime and computational power.

[0055] According to one implementation scheme, the method further includes: In the fourth display step, the modified text intermediate representation of the modified graphic is displayed in the text editor unit.

[0056] This enables the following technical advantages: displaying the intermediate text representation modified during text programming within a text editor unit allows users to identify errors or defects in the modified graphical representation generated by text programming and corresponding to the modified intermediate text representation based on the displayed modified intermediate text representation.

[0057] According to one implementation plan, the first conversion step also includes: In the behavior determination step, the graphical program objects and graphical behaviors of the graphical diagram are determined, wherein the graphical behaviors describe the graphical representation of the program sequence of the control program; and In the behavior conversion step, the graphical behavior of the graphical program object and the graphical graph is converted into the text behavior of the text program object and the text intermediate representation, where the text behavior represents the text intermediate representation of the sequence of control programs.

[0058] This allows for the following technical advantages: enabling precise conversion between graphical representations and their corresponding textual intermediate representations. For this purpose, the graphical program objects in the graphical representation are first identified, and then individually converted into their corresponding textual program objects during the conversion process.

[0059] As described above, the graphical program object is predefined by the rules of the appropriately chosen graphical programming language and corresponds to the program object of the control program to be generated. The corresponding text program object is the textual representation of the corresponding graphical program object of the graphical graph, and therefore represents the corresponding executable program object of the control program in text form.

[0060] Therefore, a text program object is not an independent program object, but a text equivalent of a graphical program object, which, as already mentioned, is predefined by the rules of a graphical programming language.

[0061] Furthermore, graphical behavior is defined within the graphical graph. Graphical behavior describes the program sequence of the graphical graph and defines the links between various graphical program objects within the graph. Therefore, graphical behavior defines the time-related execution of each graphical program object and the interactions between these objects within the graphical graph.

[0062] Based on graphical behaviors, corresponding text behaviors are generated. These text behaviors describe program sequences in a corresponding manner within an intermediate text representation and are the textual equivalents of the graphical behaviors. Within the text behaviors, the program-related timing of each text program object and the links between text program objects in the intermediate text representation are defined according to the graphical behaviors.

[0063] In determining graphical behavior, the graphical object positions of graphical program objects can also be determined. Graphical object positions describe the location of each graphical object within a graphical graph or graphical behavior. Therefore, the graphical object positions of each graphical program object are assigned to each graphical program object in the graphical graph sequence, and these graphical program objects allow for the definition of the arrangement of each graphical program object relative to each other.

[0064] Therefore, the graphical object positions of graphical program objects can be used to define the execution order of graphical program objects in a graphical graph or graphical behavior. Thus, graphical program objects can be assigned to each other via graphical object positions, and program sequences can be defined where graphical program objects execute according to the graphical object positions assigned to them.

[0065] During the conversion process, the position of a graphical object in a graphical program can be transformed into the position of the corresponding text object in a text program.

[0066] The position of each text program object defines the arrangement order of text program objects in the text behavior and the corresponding program sequence of the control program.

[0067] Within the framework of an application, behavior describes how program functions work or operate. Behaviors include, for example, procedures for calculating function results based on function parameters.

[0068] According to one implementation plan, the first conversion step includes: In the line conversion step, a line-by-line conversion is performed, wherein in the line-by-line conversion, at least one text program object in the form of at least one text line representing a text intermediate is assigned to each graphics program object, and wherein the text line provides a unique description of the corresponding graphics program object.

[0069] This achieves the following technical advantages: due to line-by-line transformation, each text program object corresponding to a graphical program object in the graphic diagram is represented by at least one line of text. The line-by-line representation of text program objects in the intermediate text representation ensures that the intermediate text representation is easy for the user to read. Therefore, preferably, the text program object is represented in exactly one line of text within the intermediate text representation.

[0070] This improves the readability of the intermediate text representation because it clearly separates the individual text program objects from one another, and makes them easier to understand due to line-by-line division. Besides improving readability, this also facilitates programming, especially within text-based programming. Line-by-line transformation also allows for the management of the intermediate text representation of program code within a version control system.

[0071] According to one implementation plan, the first conversion step includes: In the placement step, the text behavior is placed in the middle of the text at the behavior position that represents the pinch, where the behavior position defines the location where the behavior of the control program predefined by the IEC 61131-3 standard in the program code is to be located.

[0072] This achieves the following technical advantages: by placing text behaviors at specified locations within the text intermediate representation, the text intermediate representation conforms to the requirements of IEC 61131-3. Furthermore, because the behaviors are placed at specified locations, the coherent code of the text intermediate representation is easier for users to read.

[0073] Within the framework of an application, a behavior location defines where that behavior must be positioned within the program code. Behavior locations can be specified by the specifications of the corresponding programming language. In the field of automation and the programming languages ​​used, behavior locations can be defined in the IEC 61131-3 standard.

[0074] According to one implementation plan, the first generation step includes: In the identifier determination step, an identifier for a graphical program object in the drawing is determined, wherein the identifier of the graphical program object allows for unique identification of the corresponding graphical program object; and wherein the row conversion step includes: In the integration step, the identifiers of the graphics program objects are integrated into the corresponding lines of the text intermediate representation assigned to the graphics program objects.

[0075] This achieves the following technical advantages: by identifying the identifiers of graphical program objects and integrating the corresponding identifiers into the corresponding text program objects, a clear correspondence is ensured between the graphical program objects in the graph and the text program objects represented in the text. Furthermore, integrating the identifiers of graphical program objects into the corresponding text program objects ensures that the links between the graphical program objects in the graph are correctly considered within the text program objects represented in the text.

[0076] By explicitly specifying identifiers in text program objects (which can not only identify the corresponding text program object but also display links to other text program objects), users can easily determine the correctness of the text intermediate representation relative to the graphic diagram by viewing the text intermediate representation displayed in the text editor unit.

[0077] This, in turn, helps verify the correctness of the intermediate representation of the text, which in turn aids the programming process and can lead to improved control procedures.

[0078] According to one implementation scheme, the method further includes: In the summarization step, the text intermediate representation of a graphic is summed with at least one other intermediate representation of at least one other graphic to form a total text intermediate representation, wherein in the total intermediate representation, multiple different text intermediate representations of multiple different graphics are summed to form a coherent code in text form.

[0079] This achieves the following technical advantages: the entire control program's coherent code can be provided in the form of a general text intermediate representation. The individual executable objects of the control program can be represented or programmed using different graphical representations, or (depending on the situation) different graphical programming languages. The corresponding text intermediate representations can be combined into a general text intermediate representation. This means that only one coherent code, presented as a general text intermediate representation, is needed to represent the entire control program.

[0080] Users can also read the overall text intermediate representation as coherent text. Therefore, the entire control program is stored in a common file and is accessible to users in a readable form. The behavior of the corresponding graphical representations is arranged within the overall text intermediate representation according to the behavioral positions specified by the IEC 61131-3 standard. Thus, the overall text intermediate representation provides a textual form of an executable control program that meets the requirements of the IEC 61131-3 standard.

[0081] According to one implementation plan, the second generation step includes: In the debugging process, the text in the graphical representation indicates the execution of the debugging process.

[0082] This achieves the following technical advantages: it allows debugging of the generated control program directly based on the text intermediate representation of the graphical diagram. Therefore, the text intermediate representation is not merely a textual representation of the graphical diagram that can be displayed to the user in a text editor unit for correction purposes. The text intermediate representation can also be directly used as the basis for further compilation processes of the control program.

[0083] On the other hand, the graphical representation is merely a graphical representation of the text intermediate representation. This graphical representation can be displayed to the user in a graphical editor unit, and the user can modify the graphical representation using the graphical programming process of a graphical programming language known in the prior art. Furthermore, the text intermediate representation is the decisive representation used to generate the control program during the compilation process.

[0084] According to one implementation plan, the second generation step includes: In the binary code generation step, a binary representation of the control program is generated.

[0085] This achieves the following technical advantage: the binary representation of the control program can be used to provide an executable representation of the control program.

[0086] According to one implementation scheme, the method further includes: In the storage step, the text representation is stored in the representation file.

[0087] This achieves the following technical advantages: control programs can be stored by storing intermediate text representations in representation files. As described above, by reading the representation file into the development environment as a program file, the corresponding intermediate text representation can be transformed into a corresponding graphical representation and displayed to the user for further processing in the graphical editor unit.

[0088] According to one implementation scheme, the graphical programming language is any of the following: touch point planning, function block language, or sequential language.

[0089] This achieves the following technical advantages: the method according to the invention can be applied to graphical programming languages ​​commonly used in automation technology and defined in the IEC 61131-3 standard.

[0090] According to one implementation, the syntax of the text intermediate representation and the modified text intermediate representation does not conflict with the syntax of the graphics programming language.

[0091] This achieves the following technical advantages: the syntax of the text intermediate representation does not conflict with the syntax of the graphics programming language, allowing for the provision of a clear text intermediate representation that can be reliably used to program control programs based on the graphics programming language.

[0092] According to one aspect, the development environment includes a graphical editor unit, a text editor unit, and a conversion module, wherein the development environment is configured to execute a method for generating a control program for an automated system according to one of the foregoing implementation schemes.

[0093] This achieves the following technical advantages: providing an improved development environment configured to execute the method according to the invention for generating control programs for automated systems with the aforementioned technical advantages.

[0094] The invention is described in more detail with reference to the accompanying drawings, in which: Figure 1 It is a schematic representation of a system for generating control programs for an automated system according to an implementation plan; Figure 2 This is yet another schematic representation of a system for generating control programs for an automated system, according to yet another implementation scheme; Figure 3 A flowchart is shown for a method for generating a control program for an automated system according to one embodiment; Figure 4 A further flowchart of a method for generating control programs for an automated system, according to yet another embodiment, is shown; Figure 5 A further flowchart of a method for generating control programs for an automated system, according to yet another embodiment, is shown; and Figure 6 Another flowchart of a method for generating control programs for an automated system, according to yet another embodiment, is shown.

[0095] Figure 1 A schematic representation of a system for generating a control program 209 for an automated system, according to one embodiment, is shown.

[0096] According to the present invention, a development environment 200 suitable for executing the method for generating control programs for automated systems according to the present invention includes a graphical editor unit 201, a text editor unit 203, and a conversion module 205.

[0097] The graphics editor unit 201 is implemented to perform a graphics programming process according to a graphics programming language known in the prior art. The graphics editor unit 201 may have all the input devices and display devices known in the prior art for performing a graphics programming process.

[0098] The text editor unit 203 is implemented for a text programming process. For this purpose, the text editor unit 203 may include all display devices and input devices known in the prior art for performing a text programming process.

[0099] According to the present invention, the conversion module 205 is implemented to convert the conversion process between the graphic representations 211 of the predefined graphical programming language displayed or generated in the graphical editor unit 201 into the corresponding text intermediate representation 213. Additionally, the conversion module 205 is configured to perform a reverse conversion, wherein the text intermediate representation 213 displayed or generated in the text editor unit 203 is converted into the corresponding graphic representation 211 of the previously selected graphical programming language.

[0100] According to one embodiment, the graphical programming languages ​​considered in the method according to the invention or in the development environment 200 according to the invention include language contact schemes, function block languages ​​and sequential languages, each of which is predefined in the IEC 61131-3 standard for automation technology.

[0101] Therefore, the conversion module 205 can convert the above programming language into a text intermediate representation 213.

[0102] According to the present invention, the intermediate text representation 213 is written in a user-readable form. The intermediate text representation 213 is written in a known and readable form based on natural language, such as English, German, Spanish, Mandarin, or similar universal languages.

[0103] The letters, terms, or characters / special characters used are all derived from the aforementioned natural language. Additionally, the text in the middle is displayed in line format and can be read from top left to bottom right within the display field of the text editor unit 203, or following another generally accepted readability convention.

[0104] In addition to the components shown in the figure, the development environment 200 may also include other components required to control the compilation or programming process of the program, but for clarity, these components are not shown in this representation. These components may include input or output interfaces, compilers, debugging modules, and other programming components known in the art.

[0105] In order to execute the method for generating control programs for an automated system, development environment 200 first receives input data 207 for control program 209. Input data 207 includes a description of a graphical diagram 211 of a previously selected graphical programming language.

[0106] Based on the input data 207, the graphics editor unit 201 then generates a graphic diagram 211 corresponding to the input data 207, and displays the graphic diagram in the graphics editor unit 201. For this purpose, the graphics editor unit 201 includes a corresponding display device.

[0107] If the input data 207 is in text form, the input data 207 is first converted into a graphic 211 by the conversion module 205, and then displayed in the graphic editor unit 201.

[0108] exist Figure 1 In the example shown, graph 211 includes five graphics program objects 217. The five graphics program objects 217 include three node objects 249, each of which is interconnected via two edge objects 251.

[0109] Graphical program object 217 represents the graphical representation of program object 219 of control program 209.

[0110] The graphic 211 shown in this article is only one example of a possible graphic 211 for programming language touchpoint plans, function block languages, and sequential languages.

[0111] In the subsequent conversion step, the graphic 211 displayed in the graphic editor unit 201 is converted by the conversion module 205 into a corresponding intermediate text representation 213. The intermediate text representation 213 is then displayed in the text editor unit 203. For this purpose, the text editor unit 203 may include a corresponding display device.

[0112] In the text intermediate representation 213, five text program objects 225 are defined for the five graphics program objects 217 of the graphic graph 211. The text program objects 225 represent the text representation or text description of the graphics program objects 217 of the graphic graph.

[0113] Users of development environment 200 can view the intermediate text representation 213 in text editor unit 203. This allows for the detection of errors in graphic representation 211 and, if necessary, correction.

[0114] Then, control program 209 can be generated based on graphical representation 211 and / or text intermediate representation 213.

[0115] According to one embodiment, input data 207 includes program file 221. Graphical diagram 211 is stored in program file 221 in text form.

[0116] By reading information from program file 221 via development environment 200, graphics editor unit 201 can generate a graphic diagram 211 corresponding to the input data of program file 221 and display it to the user in graphics editor unit 201. For this purpose, conversion module 205 can first convert the information stored in text form in program file 221 into the corresponding graphic diagram 211.

[0117] The above implementation describes a scenario where an existing graphic 211 stored in program file 221 is loaded by development environment 200 and displayed to the user in graphic editor unit 201 for further processing.

[0118] According to another embodiment, input data 207 includes graphical input commands 215. Graphical input commands 215 are programming commands transmitted from the user of the development environment 200 to the graphical editor unit 201 during graphical programming. For example, graphical input commands 215 may include adding or removing graphical program objects 217 from the graphical representation 211. The above embodiments describe a situation where, during a graphical programming process performed by the user of the development environment 200 within the graphical editor unit 201, the graphical representation 211 is modified or completely regenerated.

[0119] The present invention also includes a combination of two embodiments, for example, an existing graphic diagram 211 stored in program file 221 in text form is first uploaded to the graphics editor unit 201 by reading information from program file 221, and displayed to the user in the graphics editor unit for further processing.

[0120] By performing a graphical programming process, in which the user transmits graphical input commands 215 to the graphical editor unit 201 in the form of adding or removing graphical program objects 217 from the graphical graph 211, the user can modify or further develop the graphical graph 211 previously loaded into the graphical editor unit 201 based on information from the program file 221.

[0121] According to one implementation, the graphical program objects 217 and graphical behaviors 233 of graphical diagram 211 are first determined in order to convert graphical diagram 211 into a text intermediate representation 213. Graphical behaviors are given by the sum of all graphical program objects 217. Graphical behaviors 233 describe the program flow of graphical diagram 211. Graphical diagram 211 is a graphical description of the behavior of program code.

[0122] Graphical behavior 233 describes the program flow of graphical diagram 211. Graphical diagram 211 is a graphical description of the behavior of program code.

[0123] When converting graphic representation 211 into text intermediate representation 213, at least one graphic program object 217 is converted into at least one corresponding text program object 225. At least one text program object 225 represents the text representation of at least one graphic program object 217, and describes the program object 219 of control program 209 that is the same as the corresponding graphic program object 217 of graphic representation 211.

[0124] Graphical behavior can be determined by considering the volatile representation of graphical graph 211. As is known in the prior art, graphical graph 211 written in a graphical programming language is represented in a volatile representation. The volatile representation is not permanently stored in memory, but exists only in the working memory of the computer executing development environment 200 when the graphical graph is created or displayed in graphical editor unit 201.

[0125] During the processing of the graphic 211 in the development environment 200, the volatile representation is stored as a bit sequence in the RAM of the computer executing the development environment 200, and represents the various components, including the graphical program object 217 representing the graphical behavior of the graphic 211.

[0126] By reading the volatile representation, development environment 200 can identify graphical program objects 217 and graphical behaviors. Reading this information also allows determination of the position and size information of the graphical diagram 211 and the graphical program objects 217 contained within it. The position and size information describes the position and size of each component (i.e., the graphical program objects 217) displayed in the graphical editor unit 201.

[0127] Considering the variability of the graphical representation 211, the corresponding intermediate text representation 213 (including text program object 225 and text behavior 237) can be derived from the graphical representation 211.

[0128] According to one implementation, the conversion of graphic representation 211 into text intermediate representation 213 is performed line by line. In this case, a corresponding text program object 225 is assigned to at least one graphic program object 217. The text program object 225 is represented by at least one text line 241 of the text intermediate representation 213. Preferably, the text program object 225 is represented by exactly one text line 241 within the text intermediate representation 213.

[0129] The text program object 225, represented in the form of text lines 241, can be arranged in the middle text representation 213 according to the corresponding identifier 243 of the graphic program object 217 integrated into the text program object 225.

[0130] According to one implementation, an identifier 243 is determined for the graphics program object 217 to be used in converting the graphic representation 211 into a text intermediate representation 213. The identifier 243 allows for the unique identification of each graphics program object 217. During the conversion of the graphic representation 211 line by line into the text intermediate representation 213, the identifier 243 of the graphics program object 217 is integrated into the corresponding text program object 225.

[0131] For example, identifier 243 can be represented as a sequence of numbers or letters, thereby allowing for the unique identification of graphical program object 217 or text program object 225.

[0132] Furthermore, during the conversion, the graphic object positions 235 of the graphic program objects 217 can be determined within graphic diagram 211. Graphic object positions 235 assign positions within the graphic behavior to the corresponding graphic program objects 217 and assign graphic program objects 217 to each other. Using graphic object positions 235, the execution order of the graphic program objects 217 within the program sequence of graphic diagram 211 can be defined.

[0133] During the conversion process, the graphic object position 235 assigned to the graphic program object 217 can be transformed into a corresponding text object position 253 and assigned to the corresponding text program object 225. The text program objects 225 can be assigned to each other via the text object positions 253, and the corresponding execution order of the text program objects 225 can be defined. This can be used to define the corresponding program sequence of text behaviors.

[0134] Therefore, text program object 225 provides a unique text description of the corresponding graphics program object 217. The text description may include information about the type of the corresponding graphics program object 217, information about the links between the corresponding graphics program object 217 and other graphics program objects 217, identifier 243, and other relevant information.

[0135] For example, the position information of the graphics program object 217 can be integrated into the text program object 225. The position information describes the position information related to the location of the corresponding graphics program object 217 of the graphics diagram 211 within the display device of the graphics editor unit 201. The position information may include, for example, x-coordinates and y-coordinates.

[0136] In addition to location information, size information may also be included, which defines the size of the corresponding graphics program object 217 within the display device of the graphics editor unit 201 via x and y coordinates.

[0137] In addition to the type of the corresponding graphical program object 217, the corresponding text program object 225 may also include the functionality or functional limitations of the corresponding graphical program object 217. The type or functionality of the graphical program object 217 is defined by the aforementioned standard IEC 61131-3.

[0138] For example, position or size information specifically related to the graphical representation of the graphical program object 217 in the graphical editor unit 201 can be defined separately by the manufacturer.

[0139] In addition to the text program object 225 of text behavior 237, the text intermediate representation 213 also includes text supplementary information 255. The text supplementary information 255 may include, for example, data type, variable type, interface, or other information.

[0140] Additional textual information can be written using a basic language predefined by the IEC 61131-3 standard. This basic language describes the additional information and stipulates that it must be written in accordance with the standard's specifications.

[0141] In the illustrated implementation, text behavior 237 is embedded in the text of text supplementary information 255 at a predefined behavior position 239. Behavior position 239 defines the location where text behavior 237 will be placed in the text intermediate representation 213.

[0142] The basic language of the text supplement information 255 can be based on known natural language and written in a user-readable form.

[0143] According to one implementation, the corresponding generated intermediate text representation 213 can be stored in the display file 245.

[0144] According to the present invention, after the intermediate text representation 213 has been generated and displayed in the text editor unit 203, the control program 209 represented by the graphic figure 211 and / or the intermediate text representation 213 generates the control program 209 represented by the graphic figure 211 and / or the intermediate text representation 213 or the intermediate text representation 213.

[0145] Furthermore, according to one implementation, the debugging process can be performed first based on the intermediate text representation 213. For this purpose, the development environment 200 may include components configured to perform the debugging process, such as in the form of a debugger.

[0146] According to one implementation, when control program 209 is generated, control program 209 is generated in binary representation. The binary representation can then be stored in representation file 245.

[0147] Figure 2 Another schematic representation of a system for generating control program 209 for an automated system, according to yet another embodiment, is shown.

[0148] Figure 2 The implementation plan in the document is based on Figure 1 The implementation scheme described herein, including all features described herein. If these are in Figure 2 If the implementation scheme remains unchanged, then a detailed description will be omitted.

[0149] In the illustrated implementation, development environment 200 provides users with the option of a text programming process. The text programming process is performed on a text intermediate representation 213. Therefore, the text programming process allows users to modify... Figure 1 The text intermediate representation 213 in the middle can be modified, for example by adding or removing text program objects 225 from the text intermediate representation 213, and generating a modified text intermediate representation 227.

[0150] For this purpose, the text editor unit 203 receives the corresponding text input command 223. The text input command 223 describes the programming commands entered by the user during the text programming process, which can be used to add, remove, or modify text program objects 225.

[0151] Modifying text program object 225 may include removing the text program object to be modified and adding the corresponding modified text program object. Text input command 223 may depend individually on the language used to represent the text intermediate representations 213, 227 or text program object 225, and the respective text descriptions of the graphical program object 217 in text program object 225.

[0152] The syntax for the text representations 213 and 227 corresponds at least partially to the syntax of the predefined graphical programming language in the aforementioned standard IEC 61131-3.

[0153] In the illustrated implementation, based on the user's text input command 223... Figure 1 The modifications made to the text intermediate representation 213 include the addition of two additional text program objects 247. The two additional text program objects 247 are represented in text form by the text line 241 according to the aforementioned attributes, based on the original text program object 225.

[0154] By performing a conversion process using conversion module 205, a corresponding modified graphic diagram 231 is generated from the modified text intermediate representation 227. In the modified graphic diagram 231, two other graphics program objects 229 are integrated according to the modified text intermediate representation 227. In the illustrated embodiment, the two other graphics program objects 229 are connected to graphics program object 217 to form a coherent graphic diagram.

[0155] In the illustrated implementation, the user can thus modify the previously generated graphical representation 211 by performing corresponding text-based programming operations. Therefore, the user can generate a control program 209 based on a previously selected graphical programming language, which can be accessed by executing operations such as... Figure 1 The aforementioned graphical programming operations can also be performed by executing, for example... Figure 2 The aforementioned text-based programming operations.

[0156] Therefore, users can freely choose the most convenient programming method and switch between various text and graphical programming operations during programming. Changes made during programming operations are immediately displayed in another representation via conversion. Changes made in graphical representation 211 are immediately displayed in text intermediate representations 213 and 227 via conversion. Similarly, changes made in text intermediate representations 213 and 227 are immediately displayed in graphical representations 211 and 231 after conversion.

[0157] Newly added or deleted graphical program objects 217 in graphical figure 211 are correspondingly displayed as newly added or deleted text program objects 225 in the text intermediate representation 213, or are integrated into or removed from it.

[0158] Figure 3 A flowchart of a method 100 for generating a control program 209 for an automated system, according to one embodiment, is shown.

[0159] To generate the control program for the automation system, in receiving step 101, the development environment 200 first receives input data 207 for the control program 209 of the automation system. The input data 207 describes a graphical representation 211 of a graphical programming language. This graphical representation then graphically represents at least a portion of the control program 209 to be programmed according to the graphical programming language.

[0160] According to one embodiment, the graphical programming language may be one of the programming languages ​​defined in the IEC 61131-3 standard, namely ladder logic, function block language, or sequential language.

[0161] Then, in the first generation step 103, the graphics editor unit 201 of the development environment 200 generates the corresponding graphic 211 based on the input data 207.

[0162] In the first display step 105, graphic 211 is displayed in the graphics editor unit 201.

[0163] Then, in the first conversion step 107, the conversion module 205 of the development environment 200 converts the graphical diagram 211 of the graphical programming language into a text intermediate representation 213 of the graphical diagram 211. The text intermediate representation 213 also provides a text description of the graphical diagram 211.

[0164] The text description of the intermediate text representation 213 is presented in such a way that it is readable for users of the development environment 200. Therefore, the intermediate text representation 213 includes all the information of the graphic figure 211 in a user-readable text format.

[0165] Subsequently, in the second display step 109, the intermediate text representation 213 generated by transforming the graphic diagram 211 is displayed in the text editor unit 203 of the development environment 200. Therefore, the user can check the functionality or correctness of the corresponding graphic diagram 211 by examining the intermediate text representation 213 displayed to them.

[0166] Finally, in the second generation step 111, the control program 209 can be generated based on the text intermediate representation 213 and / or based on the graphic diagram 211.

[0167] Figure 4 Another flowchart of a method 100 for generating a control program 209 for an automated system, according to yet another embodiment, is shown.

[0168] Figure 4 The implementation plan in the document is based on Figure 3 The implementation scheme is described herein, including all method steps described therein. Detailed descriptions are omitted if these remain unchanged.

[0169] The illustrated implementation describes two scenarios for providing input data 207 to generate graphic figure 211.

[0170] In one scenario, during the reading step 115, the development environment 200 reads the program file 221. The description of the graphic 211 is stored in text form in the program file 221. The input data 207 corresponds to the text information in the program file 221.

[0171] In the second conversion step 117, the text information in the program file 221 is converted into the graphic 211 by means of the conversion module 205.

[0172] This describes a scenario where, in order to generate a graphical representation 211 based on input data 207, the graphical representation 211, which has already been generated and temporarily stored in program file 221 in text form, is generated by reading information from program file 221 using development environment 200. When program file 221 is read, the information stored in program file 221 in text form is first detextified and correspondingly transformed into graphical representation 211, which can be displayed in graphical editor unit 201.

[0173] This covers a scenario where a graphic 211 created at an earlier point in time is loaded into the development environment 200 for further processing or modification by performing corresponding programming operations.

[0174] In the second scenario, in graphical programming step 113, the graphical editor unit 201 first receives a graphical input command 215 from the user of the development environment 200. Input data 207 includes the graphical input command 215. The graphical input command 215 further includes programming commands for adding and / or removing and / or modifying graphical program objects 217. Graphical program objects 217 are partial elements of the graphical diagram 211 and represent program objects 219 of the control program 209 to be generated.

[0175] This describes the situation of graphical programming operations. Graphical input command 215 corresponds to the programming actions entered by the user during programming according to the graphical programming language.

[0176] The graphical programming process allows modification of an existing graphical representation 211 displayed in the graphical editor unit 201 by adding or removing graphical program objects 217. Alternatively, a completely new graphical representation 211 can be generated by executing the graphical programming process.

[0177] Figure 5 Another flowchart of a method 100 for generating a control program 209 for an automated system, according to yet another embodiment, is shown.

[0178] Figure 5 The implementation scheme shown is based on Figure 4 The implementation scheme is described herein, including all method steps described therein. If these remain unchanged in the illustrated implementation scheme, no further detailed description is required.

[0179] In the illustrated implementation, the text editor unit 203 of the development environment 200 first receives a text input command 223 from the user in text programming step 119. The text input command 223 adds a text program object 225 to the text intermediate representation 213 as a text representation of the corresponding graphical program object 217 of the graphic figure 211, or removes it from it. The text program object 225 is the text representation of the graphical program object 217 of the graphic figure 211.

[0180] In the third generation step 121, a modified text intermediate representation 227 is generated based on the text input command 223 and the text intermediate representation 213.

[0181] Then, in the third conversion step 123, the modified text intermediate representation 227 is converted into the corresponding modified graphic representation 231. Alternatively, or additionally, the text modification of the text intermediate representation 213 caused by the text input command can be converted into a graphic modification of the graphic representation 211.

[0182] Text modification includes at least one text program object 225, which is either newly added to or deleted from the text intermediate representation 213. Therefore, graphical modification converted from text modification includes at least one graphical program object 217, which is either newly added to or deleted from the graphical representation 211.

[0183] In the fourth display step 127, the modified text intermediate representation 227 of the modified graphic 231 is displayed in the text editor unit 203.

[0184] In the third display step 125, the modified graphic 231 is displayed in the graphic editor unit 201 instead of the graphic 211.

[0185] As an alternative or additional method, the graphical modifications are displayed in graphical diagram 211. For this purpose, graphical diagram 211 in the graphical editor unit 210 is modified according to the modifications by inserting at least one newly added graphical program object 217 of the graphical modifications into the existing graphical diagram 211.

[0186] Therefore, the newly added graphics program object 217 can be marked as a new graphics program object 217, for example by color.

[0187] Therefore, the graphic program object 217 deleted from figure 211 according to the graphic modification can also be marked by color as appropriate. Alternatively, the deleted graphic program object 217 may no longer be displayed in figure 211.

[0188] Furthermore, in the summarization step 141, the text intermediate representation 213 of graphic figure 211 and at least one other intermediate representation of at least one other graphic figure are combined to form a total text intermediate representation. Thus, in the total intermediate representation, multiple different text intermediate representations 213 of multiple different graphic figures 211 are combined into coherent code in text form.

[0189] The text behaviors of multiple text intermediate representations 213 are arranged at the corresponding behavior positions in the overall text intermediate representation.

[0190] Additional text information 255 is placed between the text behaviors 237 of various graphical figures in the overall intermediate text representation. As mentioned above, the additional text information 255 may include, for example, data types, variable types, interfaces, or other information. The additional text information placed between the behaviors of various graphical figures in the overall intermediate representation can be written using a basic language predefined by the IEC 61131-3 standard.

[0191] The basic language describes that any additional information must be written in accordance with standard specifications.

[0192] On the other hand, the behavior of various graphs is written in a text sub-language whose syntax corresponds to the graph structure of programming languages ​​defined by the IEC 61131-3 standard: ladder logic, function block language, or sequential language.

[0193] This sub-language represents the aforementioned graphical programming language in text form and is presented in a user-readable manner.

[0194] In the overall text intermediate representation, the basic language represents the framework of coherent code, while the sub-language is the textual representation of the graph and, more specifically, the behavior of the graph 211.

[0195] According to one implementation, the intermediate text representation 213 representing only the graphic 211 may further include segments written in a predefined basic text language as defined by the IEC 61131-3 standard, wherein additional information possesses basic conditions such as the data type and / or variable type of the text behavior 237 representing the graphic behavior 233. As mentioned above, the corresponding text behavior 237 is written in a sub-language of one of the programming languages ​​ladder logic, function block language, or sequential language.

[0196] In the illustrated embodiment, in the second generation step 111, the control program 209 is generated based on the modified text intermediate representation 227 or based on the overall text intermediate representation and / or based on the modified graphic diagram 231 or multiple modified graphic diagrams 231.

[0197] In the illustrated implementation, the following scenario is described: the intermediate text representation 213 is modified by the user through text programming operations, and the graphic representation 211 is modified accordingly.

[0198] For this purpose, the user removes a text program object 225 from the text intermediate representation 213 or adds other text program objects 247 to the text intermediate representation 213 in the form of a text input command 223. By modifying the text intermediate representation 213 through text programming operations performed by the user, a corresponding modified graphical representation 231 can be generated after transforming the modified text intermediate representation 227 generated by performing the modifications.

[0199] Therefore, users can advance the programming of the control program 209 based on the graphical programming language by performing graphical programming operations and by performing text programming operations.

[0200] Figure 6 Another flowchart of a method 100 for generating a control program 209 for an automated system, according to yet another embodiment, is shown.

[0201] Figure 6 The implementation plan in the document is based on Figure 5 The implementation scheme is described herein, including all method steps described therein. If these remain unchanged in the illustrated implementation scheme, no further detailed description is required.

[0202] In the illustrated embodiment, the first generation step 103 includes an identifier determination step 137. In the identifier determination step 137, an identifier 243 is determined for the graphics program object 217 of the graphic figure 211. The identifier 243 allows for the unique identification of the corresponding graphics program object 217.

[0203] Furthermore, the first conversion step 107 includes a behavior determination step 129. In the behavior determination step 129, the graphics program object 217 and graphics behavior 233 of the graphics diagram 211 are determined.

[0204] According to the present invention, graphical behavior 233 is a graphical representation of the program sequence of control program 209.

[0205] Then, in behavior conversion step 131, the graphical program object 217 and graphical behavior 233 are converted into a text program object 225 and a text behavior 237 of the text intermediate representation 213. The text behavior 237 represents a textual representation of the program sequence of the control program 209.

[0206] Then, in line conversion step 133, the graphic representation 211 is converted line by line into an intermediate representation 213. In the line-by-line conversion, each graphic program object 217 is assigned at least one text program object 225 in the form of a text line 241 of the text intermediate representation 213. The text line 241 represents a unique description of the corresponding graphic program object 217.

[0207] In integration step 139, the previously determined identifier 243 of the graphical program object 217 is integrated into the corresponding text program object 225 represented by the text line 241.

[0208] Then, in placement step 135, text behavior 237 is placed at behavior position 239 within the text middle representation 213. Behavior position 239 defines the placement of text behavior 237 within the text middle representation 213.

[0209] The individual text program objects 225, represented as text lines 241, can be arranged according to the integrated identifier 243.

[0210] Furthermore, in the illustrated implementation, in debugging step 143, the debugging process of control program 209 is executed based on text intermediate representation 213 or modified text intermediate representation 227.

[0211] Furthermore, the second generation step 111 includes a binary code generation step 145. In the binary code generation step 145, a binary representation of the control program 209 is generated in order to generate the control program 209.

[0212] Finally, in storage step 147, the text intermediate representation 213 or the modified text intermediate representation 227 on which the generated control program 209 is based is stored in representation file 245.

[0213] List of icon numbers 100 methods 101 Receiving Steps 103 First generation step 105 First Display Step 107 First Conversion Step 109 Second display step 111 Second generation step 113 Graphical Programming Steps 115 Reading Steps 117 Second Conversion Step 119 Text Programming Steps 121 Third generation step 123 Second conversion step 125 Third display step 127 Fourth Display Step 129. Steps for Determining Behavior 131 Behavior Transformation Steps 133 conversion steps 135 Arrangement Steps 137 Identification Steps 139 Integration Steps 141 Summary Steps 143 Debugging Steps 145 Binary Code Generation Steps 147 Storage Steps 200 Development Environment 201 Graphics Editor Unit 203 Text Editor Unit 205 Conversion Module 207 Input Data 209 Control Procedure 211 Graphic Diagram 213 Text Intermediate Representation 215 Graphical Input Commands 217 Graphical Program Objects 219 Executable object 221 Program File 223 Text Input Command 225 Text Program Object 227 Modified intermediate text representation 229 Another graphical program object 231 Modified graphic diagram 233 Graphical Behavior 235 Position of graphic objects 237 Text Behavior 239 Behavioral Location 241 lines of text 243 Mark 245 Display File 247 Another text program object 249 Node objects 251 Edge Objects 253. Text object position 255 words of additional information

Claims

1. A computer-implemented method (100) for generating a control program for an automated system, comprising: In the receiving step (101), input data (207) for a control program (209) for an automation system is received from the development environment (200), wherein the input data (207) describes a graphical diagram (211) of a graphical programming language, and wherein the graphical diagram (211) graphically represents at least a portion of the control program (209) for the automation system according to the graphical programming language. In the first generation step (103), the graphical editor unit (201) of the development environment (200) generates the graphical diagram (211) of the graphical programming language based on the input data (207); In the first display step (105), the graphic diagram (211) is displayed in the graphic editor unit (201) of the development environment (200); In the first conversion step (107), the conversion module (205) of the development environment (200) converts the graphical diagram (211) of the graphical programming language into a text intermediate representation (213) of the graphical diagram (211); wherein the text intermediate representation (213) provides a text description of the graphical diagram (211); In the second display step (109), the intermediate text representation (213) of the graphic (211) is displayed in the text editor unit (203) of the development environment (200), wherein the intermediate text representation (213) is displayed in the text editor unit (203) in a user-readable form of the development environment (200); and In the second generation step (111), the control program (209) is generated based on the text intermediate representation (213) of the graphical graph (211) of the graphical programming language and / or based on the graphical graph (211).

2. The method (100) according to claim 1, wherein the receiving step (101) comprises: In the graphical programming step (113), the graphical editor unit (201) of the development environment (200) receives a graphical input command (215) from the user of the development environment (200), wherein the input data (207) includes the graphical input command (215), wherein the graphical input command (215) includes a programming command for adding and / or removing graphical program objects (217) of the graphical graph (211), and wherein the graphical program objects (217) are partial elements of the graphical graph (211) and represent program objects (219) of the control program (209).

3. The method (100) according to claim 1 or 2, wherein the receiving step (101) comprises: In the reading step (115), the program file (221) is read, wherein the program file (221) contains the input data (207) of the graphic diagram (211) in text form, wherein the graphic program object (217) of the graphic diagram (211) is described in text form by the input data (207); In the second conversion step (117), the conversion module (205) converts the text input data (207) into the graphic image (211).

4. The method (100) according to any one of the preceding claims, further comprising: In the text programming step (119), a text input command (223) from the user is received via the text editor unit (203) of the development environment (200), wherein the text input command (223) is used to add or remove a text program object (225) as a text representation of the corresponding graphic program object (217) of the graphic graph (211) from the intermediate text representation (213) of the graphic graph (211); In the third generation step (121), a modified text intermediate representation (227) is generated based on the text input command (223) and the text intermediate representation (213) of the graphic graph (211); In the third conversion step (123), the modified text intermediate representation (227) is converted into a corresponding modified graphical representation (231) of the graphical programming language, and / or, with the aid of the conversion module (205), the text modification of the text intermediate representation (213) caused by the text input command is converted into a graphical modification of the graphical representation (211), wherein the text modification includes at least one newly added or deleted text program object (225), and wherein the graphical modification includes at least one newly added or deleted graphical program object (217); In the third display step (125), the modified graphic diagram (231) is displayed in the graphic editor unit (201) instead of the graphic diagram (211) and / or the graphic modification in the graphic diagram (211) is displayed; as well as In the second generation step (111), the control program (209) is generated based on the modified text intermediate representation (227) of the modified graphic diagram (231) and / or based on the modified graphic diagram (231).

5. The method (100) according to claim 4, further comprising: In the fourth display step (127), the modified intermediate text representation (227) of the modified graphic (231) is displayed in the text editor unit (203).

6. The method (100) according to any one of the preceding claims, wherein the first conversion step (107) further comprises: In the behavior determination step (129), the graphical program object (217) and graphical behavior (233) of the graphical graph (211) are determined, wherein the graphical behavior (233) describes a graphical representation of the program flow of the control program (209); as well as In the behavior conversion step (131), the graphical program object (217) and the graphical behavior (233) of the graphical graph (211) are converted into the text program object (225) and text behavior (237) of the text intermediate representation (213), wherein the text behavior (237) represents the text intermediate representation (213) of the execution of the control program (209).

7. The method (100) according to any one of the preceding claims, wherein the first conversion step (107) comprises: In the line conversion step (133), a line-by-line conversion is performed, wherein each graphical program object (217) is assigned at least one text program object (225) in the form of at least one text line (241) of the text intermediate representation (213), and wherein the text line (241) contains a unique description of the corresponding graphical program object (217).

8. The method (100) according to claim 7, wherein the first conversion step (107) comprises: In the placement step (135), the text behavior is placed at the behavior position (239) within the text intermediate representation (213), wherein the behavior position (239) defines the location in the program code where the behavior of the control program will be positioned, as predefined by the IEC 61131-3 standard.

9. The method (100) according to claim 7, wherein the first generation step (103) comprises: In the identifier determination step (137), an identifier (243) of the graphics program object (217) of the graphics diagram (211) is determined, wherein the identifier (243) of the graphics program object (217) allows for unique identification of the corresponding graphics program object (217); and wherein the row conversion step (133) includes: In the integration step (139), the identifier (243) of the graphical program object (217) is integrated into the corresponding program object (225) of the text intermediate representation (213) assigned to the graphical program object (217) and written in text lines (241).

10. The method (100) according to any one of the preceding claims, further comprising: In the summarization step (141), the text intermediate representation (213) of the graphic graph (211) is summarized with at least one other intermediate representation of at least one other graphic graph to form a total text intermediate representation, wherein the total intermediate representation summarizes multiple different text intermediate representations (213) of multiple different graphic graphs (211) into coherent code in text form.

11. The method (100) according to any one of the preceding claims, wherein the second generation step (111) comprises: In the debugging step (143), the debugging process is performed based on the intermediate text representation (213) of the graphical diagram (211).

12. The method (100) according to any one of the preceding claims, wherein the second generation step (111) comprises: In the binary code generation step (145), a binary representation of the control program (209) is generated.

13. The method (100) according to any one of the preceding claims, further comprising: In the storage step (147), the text representation is stored in the representation file (245).

14. The method (100) according to any one of the preceding claims, wherein the graphical programming language is any one of: touch diagram, function block language, flowchart language.

15. The method (100) according to any one of claims 4 to 5, wherein the syntax of the text intermediate representation (227) and the modified text intermediate representation (213) does not conflict with the syntax of the graphics programming language.

16. A development environment (200) having a graphical editor unit (201), a text editor unit (203) and a conversion module (205), wherein the development environment (200) is configured to perform the method (100) according to any one of claims 1 to 15.

Images