Conversion method between table file and graphics program, storage medium, and electronic device

Abstract

To provide a method for converting a graphics program into a table file in a technical field of vehicle software development.SOLUTION: Creating as many empty table pages as the sum of the number of main programs and nested subprograms in the graphics program, sequentially constructing corresponding table pages according to the categories of the programs in the graphics program, where one page corresponds to the main program, and all the remaining pages correspond to the corresponding nested subprograms, and saving the table file after the construction is completed.SELECTED DRAWING: Figure 1B

Description

[Technical Field]

[0001] The present invention relates to the technical field of vehicle software development, and more particularly to a method for converting between a table file and a graphics program, as well as a computer-readable storage medium and an electronic device. [Background technology]

[0002] In automotive software development and testing, table files are often used to define test use cases and describe test steps in the automotive testing process, while graphics programs are often used to model and develop automotive software and execute test programs. Therefore, there is a common need to convert test use cases described in table files into executable graphics programs.

[0003] Automating this conversion process is often difficult because the formats of each vehicle manufacturer's proprietary table files are not standardized. Manually converting table files to graphics programs incurs costs associated with repeated manual conversions whenever the use case for the table files changes. Even if a converter is specifically created to convert table files to graphics programs, a new problem still arises: when a user makes changes to the graphics program and wants to synchronize those changes with the table files, automation is equally difficult, resulting in increased conversion costs. Summary of the Invention

[0004] The present invention relates to a method for converting between a table file and a graphics program, including a method for converting a table file into a graphics program and / or a method for converting a graphics program into a table file. The method for converting a table file into a graphics program includes the steps of reading the table file, reading the text content and coordinate information of all cells in at least one page of the table file into corresponding two-dimensional object arrays, and setting the name of each two-dimensional object array to the name of the corresponding page, sequentially analyzing each two-dimensional object array into a flowchart region and an attribute region for each page, and constructing a graphics program based on the analysis result.

[0005] A method for converting a graphics program into a table file includes the steps of: creating empty table pages in the same number as the total number of main programs and nested subprograms in the graphics program; constructing corresponding table pages in order according to the categories of programs in the graphics program, with one page corresponding to the main program and all the remaining pages corresponding to the corresponding nested subprograms; and saving the table file after construction is complete.

[0006] Additional features and advantages of the invention will be set forth in the description which follows, and in part will be obvious from the description, or may be learned by the practice of the invention. The objectives and other advantages of the invention will be realized and obtained by the structure particularly pointed out in the description and drawings.

[0007] In order to make the above objects, features and advantages of the present invention more comprehensible, the following preferred embodiments will be described in detail in conjunction with the accompanying drawings. [Brief explanation of the drawings]

[0008] In order to more clearly describe the specific embodiments of the present invention or the technical solutions of the prior art, the following will briefly describe the drawings that need to be used to describe the specific embodiments or the prior art. The drawings described in the following description are some embodiments of the present invention, and it is obvious that those skilled in the art can obtain other drawings from these drawings without any creative efforts.

[0009] [Figure 1A] 1 is a flowchart illustrating a method for converting a table file into a graphics program according to some embodiments of the present invention; [Figure 1B] 1 is a flowchart illustrating a method for converting a graphics program into a table file according to some embodiments of the present invention. [Figure 2] FIG. 10 is a schematic diagram of a graphics program constructed in Case 4 according to some embodiments. [Figure 3] FIG. 10 is a schematic diagram of the effect after adding a variable to a graphics program in Case 4 according to some embodiments. [Figure 4] FIG. 10 is a schematic diagram of a main program within a graphics program generated in Case 4 according to some embodiments. [Figure 5] FIG. 10 is a schematic diagram of nested subprograms within a graphics program generated in Case 4 according to some embodiments. [Figure 6] FIG. 10 is a schematic diagram illustrating the results of analysis in the attribute domain by the execution unit “check” of the graphics program generated in Case 4 according to some embodiments. [Figure 7] FIG. 10 is a schematic diagram of a 2D object array file for Case 5 according to some embodiments. [Figure 8] FIG. 10 is a schematic diagram of a fourth page of a 2D object array file for Case 5 in accordance with some embodiments. [Figure 9] FIG. 10 is a schematic diagram of a graphics program for Case 6 according to some embodiments. [Figure 10] FIG. 10 is a schematic diagram of table content generated in Case 6 according to some embodiments. [Figure 11] FIG. 10 is a schematic diagram of nested subprograms within a graphics program for Case 7 according to some embodiments. [Figure 12] FIG. 10 is a schematic diagram of table contents generated in Case 7 according to some embodiments. [Figure 13] FIG. 10 is a schematic diagram of the name of a page containing table content generated in Case 7 according to some embodiments. [Figure 14] FIG. 10 is a schematic diagram of table contents generated in Case 8 according to some embodiments. [Figure 15] FIG. 10 is a schematic diagram of attributes of the execution unit “check” of the graphics program of Case 9 according to some embodiments. [Figure 16] FIG. 10 is a schematic diagram of a table on the first page of a table file for Case 10 according to some embodiments. [Figure 17] FIG. 10 is a schematic diagram of Table 2 on the second page of the table file for Case 10 according to some embodiments. [Figure 18] FIG. 10 is a schematic diagram of Table 3 on the third page of the table file for Case 10 according to some embodiments. [Figure 19] FIG. 10 is a schematic diagram of a table on page 4 of a table file for case 10 according to some embodiments. [Figure 20] FIG. 10 is a schematic diagram of a table on page 5 of a table file for case 10 according to some embodiments. [Figure 21] FIG. 1 is a schematic diagram of a main program within a graphics program generated in case 10 according to some embodiments. [Figure 22] FIG. 11 is a schematic diagram of a main program in a graphics program waiting to be converted in case 11 according to some embodiments. [Figure 23]FIG. 11 is a schematic diagram of a first level of nested subprograms within a graphics program awaiting conversion in case 11 according to some embodiments. [Figure 24] FIG. 11 is a schematic diagram of a second level of nested subprograms within a graphics program awaiting conversion in case 11 according to some embodiments. [Figure 25] FIG. 11 is a schematic diagram of a third level of nested subprograms within a graphics program awaiting conversion in case 11 according to some embodiments. [Figure 26] FIG. 11 is a schematic diagram of an empty program in a graphics program waiting to be converted in case 11 according to some embodiments. [Figure 27] FIG. 10 is a schematic diagram of a table file after conversion in Case 11 according to some embodiments. [Figure 28] FIG. 1 is a schematic block diagram of a system for converting between table files and graphics programs according to some embodiments. [Figure 29] FIG. 1 is a schematic block diagram of an electronic device according to some embodiments. [Figure 30] FIG. 1 is a schematic block diagram of an electronic device according to some embodiments. [Figure 31] FIG. 1 is a schematic block diagram of a system according to some embodiments. DETAILED DESCRIPTION OF THE INVENTION

[0010] In order to clarify the objectives, technical aspects and advantages of the embodiments of the present invention, the technical aspects of the present invention will be clearly and completely described below in conjunction with the accompanying drawings. However, it is clear that the described embodiments are only some of the embodiments of the present invention and do not represent all of the embodiments. All other embodiments obtained by those skilled in the art based on the embodiments of the invention without performing creative work fall within the scope of protection of the invention.

[0011] In automotive software development and testing, table files are often used to define test use cases and describe test steps in the automotive testing process, while graphics programs are often used to model and develop automotive software and execute test programs. Therefore, there is a common need to convert test use cases described in table files into executable graphics programs.

[0012] However, because the formats of table files unique to each automobile manufacturer are not standardized, automating this conversion process is often difficult. Manually converting table files to graphics programs incurs costs associated with repeated manual conversions whenever the use case for the table files changes. While related technologies offer converters for converting table files to graphics programs, they still face a new problem: when a user makes changes to a program in a graphics program and wants to synchronize those changes with the table files, automation is similarly difficult, resulting in increased conversion costs.

[0013] Accordingly, at least one embodiment provides a method for converting between table files and graphics programs.

[0014] A method for converting a graphics program into a table file includes the steps of reading the table file, reading the text content and coordinate information of all cells in at least one page of the table file into corresponding two-dimensional object arrays, and setting the name of each two-dimensional object array to the name of the corresponding page; sequentially analyzing each two-dimensional object array as a flowchart region and an attribute region for each page; and constructing a graphics program based on the analysis results.

[0015] A method for converting a graphics program into a table file includes the steps of: creating empty table pages in the same number as the total number of main programs and nested subprograms in the graphics program; constructing corresponding table pages in order according to the categories of programs in the graphics program, with one page corresponding to the main program and all the remaining pages corresponding to the corresponding nested subprograms; and saving the table file after construction is complete.

[0016] The conversion method between table files and graphics programs in this embodiment can support mutual conversion between table files and graphics programs, so that changes made by users in both table files and graphics programs can be accurately and synchronously converted to another format. This makes document maintenance easier for document creators and test use case developers, and makes it easier for test implementers to understand and create graphics programs. Particularly in the field of automotive testing, the conversion from table files to graphics programs improves the efficiency of the conversion from test use cases to test implementation and avoids the possibility of errors caused by manual conversion. The conversion from graphics programs to table files allows graphics programs changed by users in real time to be converted and saved into test use cases, similarly avoiding the possibility of errors caused by manual conversion.

[0017] Various non-limiting embodiments according to examples of the present disclosure are described in detail below in conjunction with the drawings.

[0018] 1A and 1B, some embodiments provide a method for converting between a table file and a graphics program, including converting a table file to a graphics program and / or converting a graphics program to a table file.

[0019] To convert a table file to a graphics program: Step S101: reading a table file, reading the text content and coordinate information of all cells in at least one page of the table file into corresponding two-dimensional object arrays, and setting the name of each two-dimensional object array to the name of the corresponding page; step S102 of sequentially analyzing each two-dimensional object array for each page as a flowchart region and an attribute region; and step S103 of constructing a graphics program based on the analysis results.

[0020] To convert a graphics program to a table file, Step S201 of creating empty table pages in the same number as the total number of main programs and nested subprograms in the graphics program; a step S202 of sequentially constructing corresponding table pages according to program categories within the graphics program, one page corresponding to the main program and all remaining pages corresponding to corresponding nested subprograms; and step S203 of saving the table file after construction is complete.

[0021] Specifically, in some embodiments, the number of nested subprograms may be zero.

[0022] Specifically, one table file corresponds to one graphics program. The table file includes at least one page corresponding to the main program within the graphics program, and other pages, if any, correspond to nested subprograms within the graphics program. The page corresponding to the main program is usually the first page of the table file and may be named "Main."

[0023] In some embodiments, the flowchart region includes at least one run unit type character corresponding to a run unit in a graphics program, and the method for analyzing the two-dimensional object array as a flowchart region includes: reading the text content of each array element in order from top to bottom to determine the text content; If it is determined that the text content is a run-unit type character, determining the run-unit type based on the text content, and if the content of an array element above the run-unit type character is also a run-unit type character, marking the corresponding run unit as the next run unit of the above run unit; if it is determined that the text content is empty, skipping the text content and continuing to read the next text content; If the text content of the entire column from top to bottom is empty, completing the analysis of the flowchart region.

[0024] Case 1 The method for analyzing the two-dimensional object array as a flow chart region will be explained in detail using one case.

[0025] Table A below is an example of a two-dimensional object array with four rows and six columns. [Table A] TIFF2026021487000002.tif28170

[0026] The first column is the flow chart area, and the third to sixth columns are the attribute areas. A flowchart region contains three run-unit type characters: EP, NOP, and NOP. An empty graphics program must contain at least the EP run-unit type character.

[0027] The method for analyzing a two-dimensional object array as a flowchart region is as follows. The text content of each array element is read from top to bottom, starting from the first column, and the text content is determined. In Case 1, the first column contains EP, NOP, and NOP, all of which are run-unit-type characters. Since the fourth line is blank, there are only three run-units in this column. The parent array element of the NOP on the third line is NOP, which is also a run-unit-type character, so the NOP on the third line is the next run-unit after the NOP run-unit on the second line. Furthermore, the parent array element of the NOP on the second line is EP, which is also a run-unit-type character, so the NOP on the second line is the next run-unit after the EP run-unit on the first line. The EP on the first line is the first run-unit and serves as the entry point for all graphics programs.

[0028] When parsing the second column, if the first line of the second column is empty, skip the empty text and continue reading the next text content. When parsing the second column, the entire column is empty, so the analysis of the flowchart region is complete.

[0029] In some embodiments, the flowchart region further comprises a connector.

[0030] The method for analyzing the two-dimensional object array as a flowchart region includes: reading the text content of each array element in left to right order to determine the text content; If it is determined that the text content is a connector, the method further includes the step of marking the first run unit found to the left of the connector as a run unit that supports execution in a right direction, and marking the first run unit found to the right of the connector as the next run unit that the run unit will execute in a right direction.

[0031] Case 2 The method for analyzing the two-dimensional object array as a flow chart region will be explained in detail using another case.

[0032] Table B below is an example of a two-dimensional object array with 5 rows and 8 columns. [Table B] TIFF2026021487000003.tif34170

[0033] The first to third columns are the flowchart area, and the fifth to eighth columns are the attribute area. The method for analyzing the two-dimensional object array in Case 2 as a flowchart region is as follows.

[0034] The text content of each array element is read from top to bottom and left to right to determine the text content. If the text content is determined to be a run-unit type character, the analysis method is the same as that for Case 1, as in the first column of Case 2. If the text content is determined to be a connector, that is, when analyzing the second column, if a connector "-" is found in the second line, mark the first run-unit found to the left of that connector. In other words, "NOP" in the second line of the first column is a run-unit that supports execution to the right. Also, mark the first run-unit found to the right of that connector. In other words, "NOP" in the second line of the third column is the next run-unit that the "NOP" run-unit in the second line of the first column will execute to the right.

[0035] When parsing the second column, if the first line of the second column is empty, skip the empty text and continue reading the next text content. When parsing the fourth column, the entire column is empty, so the analysis of the flowchart region is complete.

[0036] In some embodiments, the attribute area includes a definition column, a name column, a comment column, and a parameter setting column.

[0037] The method for analyzing the two-dimensional object array as an attribute region includes: reading the text content of each array element of the definition sequence from top to bottom, and the text content is a character within a run unit definition, a variable definition, or a program definition; reading the text content of each array element of the name string from top to bottom, and determining that the text content is a name attribute character corresponding to a definition in the definition string, such as a run unit name, a variable name, or a program name; The text content of each array element in the comment column is read in order from top to bottom, and the text content is a comment attribute character corresponding to the definition in the definition column.

[0038] If the array element is the character content of a program definition, the parameter setting column corresponding to the array element describes attribute information of the target graphics program, such as the program name, display name, number of repetitions, and whether it is active or not.

[0039] If an array element is the character content of a variable definition, the parameter setting column corresponding to the array element describes variable information of the target graphics program, such as the type of the variable and the initial value of the variable.

[0040] If an array element is the character content of a run unit definition, the parameter setting column corresponding to that array element describes the run unit information of the target graphics program. The character content of the run unit definition is a cell coordinate value, and the parameter setting requirements differ depending on the type of run unit, and the run unit has the following types:

[0041] 1. Entry point type, abbreviated as EP (Entry Point). A graphics program has only one entry point, which is the execution unit where the graphics program is first executed. The entry point does not perform any actual operations, and once the entry point is executed, execution can only proceed downwards.

[0042] 2. No-operation type, which can be abbreviated as NOP (No Operation). No operation does not actually perform any operation, and after the no-operation ends, it can be performed downward or to the right. No parameter setting information.

[0043] 3. Signal check type, abbreviated as RD (Read). This execution unit reads one or more signals and determines whether the signal value is within a set range. If it is as expected, the program continues to execute downwards; if not, the program continues to execute rightwards. The signal check type execution unit supports both downward and rightwards execution paths. The parameter setting information includes a judgment timeout period, the number of variables, the name of each variable, the type of each variable, the minimum value of each variable, the maximum value of each variable, and a judgment pass condition (and / or).

[0044] 4. Signal Write type, abbreviated as WR (Write). This execution unit writes one or more signals. Signal Write type execution units support either a downward or rightward execution path, but cannot support both downward and rightward paths simultaneously. The parameter setting information includes the number of variables, the name of each variable, the type of each variable, the value to be written to each variable, and the like.

[0045] 5. Jump-to type, abbreviated as JMP (Jump to). This execution unit supports programs that jump to a target execution unit and continue execution. Jump-to type has no paths connected downward or to the right. The parameter setting information includes a jump tag (jump between the same tags), the number of jump tags, and so on.

[0046] 6. Jump from type, abbreviated as FROM (Jump from). This execution unit supports programs that jump to this execution unit from the Jump to type and continue execution. The Jump from type supports downward or rightward execution paths, but cannot support both downward and rightward paths simultaneously. The parameter setting information includes a jump tag (jump between the same tags), the number of jump tags being one, and so on.

[0047] 7. Function call type, abbreviated as API (Application Interface). The execution unit is responsible for calling the target API function using the specified parameters. The function call type supports downward or rightward execution paths, but cannot support both downward and rightward paths simultaneously.

[0048] The parameter setting information may include, but is not limited to, the API function name, the API function type (e.g., system API, applet library API, user-created API), whether to ignore the return value of the API function, the type of the variable written in the return value, the name of the variable written in the return value, the number of parameters of the API function, the type of each parameter, the name of each parameter, the value of each parameter, etc.

[0049] 8. A subprocess type, which can be abbreviated as Group (Subchart Group). The execution unit contains nested subprograms. The nested subprogram type supports downward or rightward execution paths, but cannot support both downward and rightward paths simultaneously. The parameter setting information may include, but is not limited to, the type of a variable corresponding to the number of repetitions, the name of a variable corresponding to the number of repetitions, and the like.

[0050] 9. Expression type, which can be abbreviated as EXP (Expression). The execution unit is used to execute a given mathematical expression. The expression type supports downward or rightward execution paths, but cannot support both downward and rightward paths simultaneously. The parameter setting information includes the number of independent variables, the formula, the type of the variable into which the result of the formula is written, the name of the variable into which the result of the formula is written, the type of each independent variable, the name of each independent variable, and the like.

[0051] Case 3 The method for analyzing the two-dimensional object array as an attribute region will be described in detail below using one case.

[0052] Table C below is an example of a two-dimensional object array with 6 rows and 8 columns. [Table C] TIFF2026021487000004.tif60170

[0053] The attribute area ranges from the fifth column to the eighth column, which are the definition column, the name column, the comment column, and the parameter setting column, respectively.

[0054] The first line of the fifth column is Def, which indicates that the column is the character content of the definition column. The second line, Program, indicates that this line is the character content of the program definition. The character content of the third to fifth lines is cell coordinate values, and indicates that the row corresponding to the cell coordinate values ​​is the character of the related run unit definition. For example, A2 indicates that the related run unit is at the coordinate of the second row of column A. The character content of the sixth line, Var, indicates that the action is the character of the variable definition.

[0055] The first line of the sixth column is "Name," indicating that the column is a name column. The second line is "GP1," indicating that the name of the program is GP1. The third to fifth lines indicate that the names of the associated run units are NOP1, NOP2, and NOP3, respectively. The sixth line indicates that the name of the variable is v0.

[0056] The first line of the seventh column is Comment, which indicates that the column is a comment column. The second line is a comment for program GP1. Lines 3 to 5 show comments for the related run units NOP1, NOP2, and NOP3. Line 6 shows a comment for variable v0.

[0057] The first row of the eighth column is Configuration, which indicates that the column is a parameter setting column. The second row is parameter setting information for program GP1. The third to fifth rows show parameter setting information for related execution units NOP1, NOP2, and NOP3. The sixth row shows parameter setting information for variable v0.

[0058] In some embodiments, a graphics program is constructed based on the analysis results, specifically, the steps include constructing the graphics program based on attribute information of the target graphics program, adding variables to the graphics program based on variable information of the target graphics program, constructing an execution unit of a main program of the graphics program and jump relationships between each execution unit based on the analyzed flowchart regions, constructing each nested subprogram of the graphics program based on the analyzed flowchart regions and associating each nested subprogram with an execution unit corresponding to the main program or its upper-level nested subprogram, and finally constructing each execution unit in the nested subprogram of the graphics program and jump relationships between each execution unit based on the analyzed flowchart regions. Also, each execution unit of the graphics program is constructed based on the execution unit information of the target graphics program.

[0059] Case 4 A method for constructing a graphics program based on the analysis results will be explained in detail below using one case.

[0060] The following tables are two examples of two-dimensional object arrays: Table 1 shows the analysis results for the main program of a graphics program with 8 rows and 8 columns.

[0061] Table showing the analysis results of the main program [Table 1]

[0062] Table 2 shows the results of an analysis of nested subprograms for a graphics program with 3 rows and 6 columns.

[0063] A table showing the results of nested subprogram analysis [Table 2]

[0064] These two 2D object arrays have already been analyzed into a flowchart region and an attribute region. The attribute region of the main program contains program and variable attributes, while the attribute region of the nested subprogram does not contain program and variable attributes. The definition column, name column, comment column, and parameter setting column in the attribute regions of these two tables have already been analyzed and extracted. Next, construct a graphics program according to the following steps:

[0065] First, as shown in FIG. 2, an empty graphics program is constructed based on the analyzed program name, comment, and parameter setting information.

[0066] In this empty graphics program, the window title of the graphics program module is Program1, which is obtained from the parameter setting column of the analyzed program. The display name of the graphics program submodule is GP1, which is obtained from the name column of the analyzed program. The program name of the graphics program submodule is am_GP1, which is obtained from the parameter setting column information of the analyzed program. The comment information of the graphics program submodule is obtained from the comment column of the analyzed program.

[0067] Next, variables are added to the graphics program based on the parsed variable information. As shown in Figure 3, one variable is added, and its type is integer (Integer), which is obtained from the parameter setting column information of the parsed variable v0. The variable name is v0, which is obtained from the name column of the parsed variable. The variable's initial value (Init. Value) is 0, which is obtained from the parameter setting column information of the parsed variable v0. The variable comment is "variable define", which is obtained from the comment column of the parsed variable.

[0068] Next, based on the flowchart region analyzed in Table 1, the execution units of the main program of the graphics program and the jump relationships between each execution unit are constructed. The names (types) of the execution units of the main program are: It has Entry (EP), check (NOP), Ignore (NOP), jmp to (JMP), jmp from (FROM), and Group (Group). These jump relations are as follows:

[0069] Entry jumps downward to check. The check branches downwards and jumps to Ignore, then branches right and jumps to jmp to. Ignore jumps downward to jmp from. jmp to jumps to the right to jmp from. jmp from jumps downward to Group.

[0070] As shown in FIG. 4, a flowchart of the main program can be generated according to the run units constructed as described above and the jump relationships between the run units.

[0071] Next, in a similar manner, nested subprograms of the graphics program are constructed based on the flowchart regions analyzed in Table 2, and each nested subprogram is associated with an execution unit corresponding to the main program or its higher-level nested subprogram. That is, since the execution unit named Group in the main program in Table 1 is associated with the nested subprogram in Table 2, the user can open the nested subprogram by double-clicking the execution unit named Group in the interface of the main program.

[0072] Next, based on the analyzed flow chart region, each execution unit in the nested subprogram of the graphics program and the jump relationship between each execution unit are constructed. In case 4, the nested subprogram is a nested subprogram of the main program Group, and the name (type) of each execution unit is: It has Sub Entry (EP), NOP1 (NOP) and NOP2 (NOP). The jump relationship between these is as follows:

[0073] Sub Entry jumps downward to NOP1. NOP1 jumps downward to NOP2.

[0074] As shown in FIG. 5, a flowchart of the nested subprogram can be generated according to the execution units constructed as above and the jump relationships between each execution unit.

[0075] Finally, configure each execution unit of the graphics program based on the execution unit information of the target graphics program, as shown in Figure 6. Take the execution unit named check as an example. According to the analysis result in its attribute area, its execution type is no operation, its display name is check, the timeout period is 0, the comment information is "first Unit under EP", the next step is to execute rightward, and the result of the current step is set to OK.

[0076] In some embodiments, each nested subprogram is associated with a run unit corresponding to the main program. The method includes the steps of: setting the name of a two-dimensional object array corresponding to each nested subprogram as the cell coordinate value of the cell in which the corresponding execution unit of the main program corresponding to each nested subprogram exists; and associating the execution unit corresponding to the cell coordinate value of the two-dimensional object array name with the main program in which the execution unit exists.

[0077] In some embodiments, each nested subprogram is associated with a run unit that corresponds to the corresponding higher-level nested subprogram.

[0078] The method sets a name of a two-dimensional object array corresponding to each nested subprogram, sets a separator between the name of the two-dimensional object array corresponding to the upper-level nested subprogram and the cell coordinate value of the corresponding run unit in the upper-level nested subprogram corresponding to each nested subprogram, extracts the content to the left of the final separator in the name of the two-dimensional object array corresponding to each nested subprogram, and compares it with the remaining two-dimensional object array names. After a match is found, associates the run unit corresponding to the cell coordinate value to the right of the final separator in the name of the two-dimensional object array with the nested subprogram analyzed for the two-dimensional object array.

[0079] Specifically, the delimiter may be any symbol that can be named in Excel, including, but not limited to, "|", ",", ".", ">", etc. In this embodiment, "|" is used as an example.

[0080] Case 5 The method for associating each nested subprogram with the run unit corresponding to its corresponding higher-level nested subprogram will be described in detail below using one case.

[0081] As shown in Figure 7, a 2D object array file can be understood as a file with a format similar to that of a table file. Let's assume that a 2D object array file contains five pages of 2D object arrays. Page 1 is a 2D object array corresponding to the main program, and all other pages are 2D object arrays corresponding to nested subprograms. The name of the 2D object array on page 2 is A7, indicating that the contents of the 2D object array are the nested subprogram of the run unit located at cell A7 on the main program page. The name of the 2D object array for the nested subprogram on page 3 is "A7|A4", indicating that the contents of the 2D object array are the nested subprogram of the run unit located at cell A4 on page A7. And so on.

[0082] The name of the two-dimensional object array for the nested subprogram on page 3 is "A7|A4", and the run unit at cell C5 in the two-dimensional object array is a run unit with a lower-level nested subprogram. The method for associating the run unit at cell C5 with its lower-level nested subprogram is as follows:

[0083] First, like the two-dimensional object array on page 4 shown in FIG. 8, the two-dimensional object array corresponding to the nested subprogram at the lower level of cell C5 is named "A7|A4|C5".

[0084] Next, the content "A7|A4" to the left of the last delimiter in the name of the 2D object array on page 4, "A7|A4|C5," is extracted, and "A7|A4" is matched one by one with the names of each of the remaining 2D object arrays, and finally matched with the 2D object array on page 3, as shown in the figure above. The nested subprogram analyzed for the 2D object array on page 4 is associated with the corresponding execution unit in the 2D object array on page 3 that corresponds to the cell coordinate value "C5" to the right of the last delimiter in the name of the 2D object array on page 4.

[0085] Specifically, by associating the nested subprograms in this embodiment with the corresponding execution units of the main program, a multi-level nesting structure can be realized.

[0086] In some embodiments, the corresponding table pages are constructed in order according to the categories of programs within the graphics program, specifically including:

[0087] The execution units of the main program and the connections between each execution unit are written in text format in the corresponding cells of the table page and used as the flowchart area. That is, if a execution unit supports rightward execution, the execution unit, the execution units connected to the right of the execution unit, and their connections are displayed in the order of execution direction in cells of the same row but different columns.

[0088] If a run unit supports execution in the downward direction, the run unit and the run units connected to it below are displayed in the order of the execution direction in cells in different rows of the same column.

[0089] Here, run unit type characters are used as the text format of run units, and connectors are used as the text format of connection relationships. Specifically, the connector may be a symbol in the form of "-", "_", etc., but is not limited thereto.

[0090] Case 6 The method of constructing the corresponding table pages in order according to the categories of programs in a graphics program is described in detail below using one case. An example graphics program is shown in FIG.

[0091] The name (type) of each execution unit of the main program in the graphics program is: They are Entry (EP), check (NOP), Ignore (NOP), jmp to (JMP), jmp from (FROM), and Group (Group).

[0092] These jump relationships are as follows: The entry jumps downward to the check, and the entry and the check are in the same column. Check branches downwards and jumps to Ignore, and check and Ignore are in the same column. The check branches to the right and jumps to the jmp to, the check and the jmp to are on the same line, the check adds a connector to the right and connects to the jmp to on the right. Ignore jumps downward to jmp from, and Ignore and jmp from are in the same column. jmp to jumps right to jmp from, which is not directly connected to jmp to, so jmp to and jmp from are not on the same line. Jmp from jumps downward to Group, and jmp from and Group are in the same column.

[0093] The final output table content is shown in Figure 10. Here, the area where columns A to C exist is the constructed flowchart area.

[0094] In some embodiments, the method for building corresponding table pages in order according to categories of programs within the graphics program further includes:

[0095] If a run unit with a nested subprogram exists within the main program, the connection relationship between the run unit and the corresponding run unit of the nested subprogram is written in text format to the corresponding cell of the table page. The table page written by the run unit of the nested subprogram is not the same as the table page written by the run unit of the main program. The name of the page is set as the cell coordinate value of the run unit with the nested subprogram in the main program.

[0096] Case 7 The method of constructing the corresponding table pages in order according to the categories of programs in a graphics program is described in detail below using one case.

[0097] Taking the graphics program shown in FIG. 4 as an example, the execution unit "Group" of the main program GP1 includes nested subprograms shown in FIG.

[0098] First, as shown in FIG. 12, a table page corresponding to a nested subprogram is constructed according to the construction method of a table page corresponding to a main program.

[0099] Next, as shown in FIG. 13, the name of the page where the table page exists is set as the cell coordinate value A5 where the run unit having the nested subprogram in the main program exists.

[0100] In some embodiments, if a nested subprogram has a run unit with a lower-level nested subprogram, the name of the table page in which the lower-level nested subprogram of the nested subprogram resides is set as the name of the table page in which the nested subprogram resides + a "delimiter" + the cell coordinate value of the run unit with the lower-level nested subprogram within the nested subprogram.

[0101] Case 8 For example, as shown in Figure 14, in a nested subprogram with a page name of A7, the run unit in which cell A4 exists is a run unit that has a lower-level nested subprogram. The name of the page in which the lower-level nested subprogram exists is set as follows: The name of the page in which the nested subprogram exists ("A7"), the delimiter "|", and the cell coordinate value "A4" of the cell in which the run unit with the lower-level nested subprogram within the nested subprogram exists are combined to form the final page name "A7|A4".

[0102] In some embodiments, the method for building corresponding table pages in order according to categories of programs within the graphics program further includes:

[0103] Attribute regions are defined in each table page, and definition columns, name columns, comment columns, and parameter setting columns are constructed in the corresponding attribute regions. The text contents of the program definition, variable definition, and run unit definition are written in the cells of the definition column in this order from top to bottom. The text contents of the run unit definition are the coordinate values ​​of the corresponding cell. The attribute character content of each definition is written in the corresponding cells of the name column, comment column, and parameter setting column in order, row by row.

[0104] Case 9 Using the submodule GP1, variable v0, and execution unit check of the graphics program Program1 in the above case as examples, we will now explain in detail how to construct an attribute area on each page that consists of a definition column, a name column, a comment column, and a parameter setting column.

[0105] First, in the table page of the graphics program, the area to the right of a blank column separated from the flowchart area is defined as an attribute area, and a definition column, a name column, a comment column, and a parameter setting column are created in the attribute area. The column names are Def, Name, Comment, and Configuration, respectively.

[0106] Add Program to the definition column of the attribute area of ​​the table page corresponding to the main program, change the name column cell in the same row to the sub-module name "GP1", change the comment column cell in the same row to the sub-module comment "program comment", and finally change the parameter setting column cell in the same row to the sub-module setting information "1;1;am_GP1;Program1". The final display content of the row is as shown in Table D below. [Table D] TIFF2026021487000007.tif8170

[0107] Depending on the number of variables, add one row for Var to the definition column of the attribute area of ​​the table page corresponding to the main program, change the name column cell of the row to the variable name "v0", change the comment column cell of the row to the variable comment "variable define", and finally change the parameter setting column cell of the row to the sub-module setting information "0;0;". The final display content of the row is as shown in Table E below. [Table E] TIFF2026021487000008.tif8170

[0108] Next, various program run unit attributes are output line by line according to the number of run units, as shown in Figure 15. The run unit check is described below as an example.

[0109] First, the cell coordinate value A2 of the execution unit is output in the definition column, then the name of the execution unit "check" is output in the name column, then the comment of the execution unit "first Unit under EP" is output in the comment column, and finally the setting information of the execution unit "0;0;" is output in the parameter setting column.

[0110] Case 10 Taking an automobile parts test script table file as an example, the process of converting a table file into a graphics program is introduced below. The table file has five pages of tables. As shown in Figure 16, the table on the first page is the main program Main, the table on the second page is shown in Figure 17, the table on the third page is shown in Figure 18, the table on the fourth page is shown in Figure 19, and the table on the fifth page is an empty table, as shown in Figure 20.

[0111] The table file above is read into the corresponding 2D object array, and the name of each 2D object array is set to the name of the corresponding page. Taking the table on page 1 as an example, the generated 2D object array is shown in Table F below. [Table F] TIFF2026021487000009.tif232170TIFF2026021487000010.tif14170

[0112] Each two-dimensional object array is analyzed one by one. First, the flowchart area in the two-dimensional object array is analyzed to obtain the jump relationships between each run unit, and then the attribute area in the two-dimensional object array is analyzed to obtain the program attributes, variable attributes, and attribute information of each run unit. After all the analysis of the 2D object array is complete, construction of the graphics program begins according to the following steps:

[0113] First, a graphics program is constructed based on the attribute information of the target graphics program. For example, the name of the submodule of the current graphics program is Demo Program, and the comment information is program comment. Next, variables such as local1 and local2 are added to the graphics program based on the variable information of the target graphics program. Next, based on the analyzed flow chart region, execution units of the main program of the graphics program and jump relationships between each execution unit are constructed. Next, each nested subprogram of the graphics program is constructed based on the analyzed flow chart regions, and each nested subprogram is associated with an execution unit corresponding to the main program. Finally, based on the analyzed flow chart region, each execution unit in the nested subprogram of the graphics program and the jump relationships between the execution units are constructed, and each execution unit of the graphics program is configured based on the information of the execution unit of the target graphics program.

[0114] For the conversion method for each remaining page, please refer to the above-mentioned part of this embodiment, and the explanation will be omitted here.

[0115] The construction of the graphics program is finally completed. The main program of the graphics program is shown in Figure 21. The test script can be executed directly, and the program will perform the test process according to the logic defined in the table file.

[0116] Case 11 The Demo Program submodule of the graphics program in the automotive parts test script is used as an example to demonstrate the process of converting a graphics program into a table file. The graphics program has five flowcharts. As shown in Figure 22, the first one corresponds to the main program.

[0117] The second is a flowchart corresponding to the first level of nested subprograms, as shown in Figure 23. The third is a flowchart corresponding to the second level of nested subprograms, as shown in Figure 24. The fourth is a flowchart corresponding to the third level of nested subprograms, as shown in Figure 25. The fifth is an empty flowchart, as shown in Figure 26.

[0118] First, for each flowchart, a corresponding table page is output, including a flowchart region and an attribute region. Next, starting from the main program flowchart, each run unit in the chart is traversed, and run units of the flowchart containing nested subprograms are associated with the corresponding nested subprograms, and the corresponding table page is renamed according to the rules. Finally, the entire table file is saved, and the conversion from the graphics file to the table file is realized. For the specific conversion process, please refer to the above content of this embodiment and will not be described here. The converted table file is shown in FIG.

[0119] As shown in Figure 28, some embodiments further provide a conversion system including a computer device, the computer device including a table-to-graphics conversion module and / or a graphics-to-table conversion module.

[0120] The table-to-graphics conversion module is configured to read a table file, read the text content and coordinate information of all cells in at least one page of the table file into a corresponding two-dimensional object array, set the name of each two-dimensional object array to the name of the corresponding page, parse each two-dimensional object array into a flowchart region and an attribute region for each page in turn, and construct a graphics program based on the parse result.

[0121] The graphics-to-table conversion module is configured to create empty table pages. The number of empty table pages is equal to the total number of main programs and nested subprograms in the graphics program. Corresponding table pages are constructed in order according to the categories of programs in the graphics program, one page of which corresponds to the main program, and all the remaining pages correspond to the corresponding nested subprograms. The table file after construction is completed is saved.

[0122] The specific implementation functions of the table to graphics conversion module and the graphics to table conversion module are implemented by a computer device. For specific details, please refer to the above-mentioned method for converting table files and graphics programs, and the description will be omitted here.

[0123] In some embodiments, the table-to-graphics conversion module and the graphics-to-table conversion module may be used independently or in combination depending on the actual situation.

[0124] Hereinafter, electronic devices according to embodiments of the present disclosure will be described from the perspective of hardware processing. The embodiments of the present disclosure do not limit the specific implementation of the electronic devices.

[0125] As shown in Figure 29, some embodiments further provide an electronic device. The electronic device includes a processor and a computer-readable storage medium, and may further include a communication bus and a communication interface. The processor, the computer-readable storage medium, and the communication interface communicate with each other via the communication bus. The computer-readable storage medium is used to store a program that executes a method for converting between the table file and a graphics program, and the program causes the processor to perform operations corresponding to the above-mentioned conversion method.

[0126] As shown in FIG. 30 , some embodiments further provide an electronic device, which includes: It includes a processor, a display in communication with the processor for displaying the table file or the graphical interface, and a readable storage medium. The readable storage medium is configured to store a program of instructions. The processor is configured to execute the program of instructions, specifically to perform the following operations:

[0127] Reading a table file, reading the text content and coordinate information of all cells in at least one page of the table file into corresponding two-dimensional object arrays, setting the name of each two-dimensional object array to the name of the corresponding page, sequentially parsing each two-dimensional object array for each page as a flowchart region and an attribute region, and constructing a graphics program based on the parsing results; and / or The same number of empty table pages as the total number of main programs and nested subprograms in the graphics program are created, and the corresponding table pages are constructed in order according to the program categories in the graphics program, with one page corresponding to the main program and the remaining pages corresponding to the corresponding nested subprograms. After construction is complete, the table file is saved.

[0128] The display is configured to display a table file or to display a graphics program via a graphical interface.

[0129] In other embodiments, computer equipment, industrial computers, etc. may also be types of electronic devices.

[0130] It should be noted that the configurations shown in Figures 29 and 30 are not intended to limit the electronic device, which may include fewer or more components than those shown, may combine some components, or may have different arrangements of components.

[0131] In some embodiments, the communication interface may be a communication interface connectable to an external bus adapter, such as RS232, RS485, a USB port, a TYPE port, etc. A wired or wireless network interface may also be included, and the network interface may optionally include a wired and / or wireless interface (e.g., a WI-FI interface, a Bluetooth interface, etc.) typically used to establish a communication connection between the computing device and other electronic devices.

[0132] The storage module, readable storage medium, or computer-readable storage medium includes at least one type of memory. Memory includes flash memory, hard disk, multimedia card, card-type memory (e.g., SD or DX memory), magnetic memory, magnetic disk, optical disk, etc. In some embodiments, it may be an internal storage unit of a computer device, such as a hard disk of the computer device. In other embodiments, the memory may be an external storage device of a computer device, such as a plug-in hard disk installed in the computer device, a SmartMedia Card (SMC)®, a Secure Digital Card (SD), a Flash Card, etc. Furthermore, the memory may include both an internal storage unit of a computer device and an external storage device. The memory is used to store various data, such as application software and computer program code installed in the computer device, as well as to temporarily store output data or data to be output.

[0133] In some embodiments, the processor may be a Central Processing Unit (CPU), controller, microcontroller, microprocessor, or other data processing chip for executing program code stored in memory or processing data, e.g., executing a computer program.

[0134] In some embodiments, the communication bus may be an input / output bus, which may be a Peripheral Component Interconnect (PCI) bus or an Enhanced Industry Standard Architecture (EISA) bus, etc. The bus may be divided into an address bus, a data bus, a control bus, etc.

[0135] Optionally, the computer device may further include a user interface. The user interface may include input units such as a display and a keyboard, and optionally, the user interface may also include a standard wired interface or a wireless interface. Optionally, in some embodiments, the display or display module may be an LED display, a liquid crystal display, a touch-sensitive liquid crystal display, an OLED (Organic Light-Emitting Diode) touch device, etc. In this case, the display or display module is also called a display screen or a display unit, since it displays information processed in the computer device and a visualized user interface.

[0136] When the processor executes the program, the steps in the embodiment of the method for converting a table file to a graphics program shown in Figures 1A and 1B are realized, for example, the flowcharts shown in Figures 1A and 1B. Alternatively, when the processor executes the computer program, the functions of each module or unit in each of the above-described device embodiments are realized.

[0137] Some embodiments further provide a computer-readable storage medium configured to store any of the possible table file to graphics program conversion methods described above.

[0138] Some embodiments further provide a computer-readable storage medium storing computer-readable instructions that, when executed by at least one processor, cause the computer to perform the above-described conversion method, specifically as follows:

[0139] The text content and coordinate information of all cells in at least one page of the table file are read into a corresponding two-dimensional object array, and the name of each two-dimensional object array is set to the name of the corresponding page, and each two-dimensional object array is sequentially parsed into a flowchart region and an attribute region for each page, and a graphics program is constructed based on the parsing results; and / or The same number of empty table pages as the total number of main programs and nested subprograms in the graphics program are created, and the corresponding table pages are constructed in order according to the category of the programs in the graphics program, with one page corresponding to the main program and all the remaining pages corresponding to the corresponding nested subprograms. The table file after construction is completed is saved.

[0140] Please refer to the detailed explanation of how to convert between table files and graphics programs, and we will not explain it here.

[0141] Some embodiments further provide a computer program product comprising a computer program or instructions that, when executed on a computer, enable the computer to perform any of the possible methods of converting between table files and graphics programs described above.

[0142] Some embodiments further provide a computer program product including a computer-readable storage medium having stored thereon computer-readable program code, the computer-readable program code including instructions that cause at least one processor or one or more computing devices to perform any of the possible table file to graphics program conversion methods described above.

[0143] The text content and coordinate information of all cells in at least one page of the table file are read into a corresponding two-dimensional object array, and the name of each two-dimensional object array is set to the name of the corresponding page, and each two-dimensional object array is sequentially parsed into a flowchart region and an attribute region for each page, and a graphics program is constructed based on the parsing results; and / or The same number of empty table pages as the total number of main programs and nested subprograms in the graphics program are created, and the corresponding table pages are constructed in order according to the category of the programs in the graphics program, with one page corresponding to the main program and all the remaining pages corresponding to the corresponding nested subprograms. The table file after construction is completed is saved.

[0144] As shown in FIG. 31, some embodiments further provide a system including one or more processors and a memory.

[0145] The memory stores one or more programs configured to be executed by one or more processors, the one or more programs including instructions for performing operations to convert table files to graphics programs and convert graphics programs to table files.

[0146] The operation of converting the table file into a graphics program includes: reading the table file, reading the text content and coordinate information of all cells in at least one page of the table file into corresponding two-dimensional object arrays, setting the name of each two-dimensional object array to the name of the corresponding page, sequentially parsing each two-dimensional object array into a flowchart region and an attribute region for each page, and constructing a graphics program based on the parsing result; and / or The operation of converting a graphics program into a table file includes the following: creating empty table pages in the same number as the total number of main programs and nested subprograms in the graphics program, sequentially constructing corresponding table pages according to the categories of programs in the graphics program, with one page corresponding to the main program and all the remaining pages corresponding to the corresponding nested subprograms, and saving the table file after construction is complete.

[0147] In some embodiments of the present invention, it should be understood that the disclosed apparatus and method may be implemented in other ways. The apparatus embodiments described above are merely exemplary. For example, the flowcharts and block diagrams in the drawings illustrate possible architectures, functions, and operations of apparatuses, methods, and computer program products according to various embodiments of the present invention. In this regard, each block in a flowchart or block diagram may represent a module, a program segment, or a portion of code. The module, program segment, or portion of code includes executable instructions for implementing one or more predetermined logical functions. Note that in some alternative implementations, the functions depicted in the blocks may occur in a different order than depicted in the drawings. For example, two consecutive blocks may actually be executed substantially in parallel, or may sometimes be executed in the reverse order, depending on the functionality involved. It should also be noted that each block in the block diagrams and / or flowcharts, and combinations of blocks in the block diagrams and / or flowcharts, may be implemented in a dedicated hardware-based system that performs the predetermined functions or operations, or may be implemented in a combination of dedicated hardware and computer instructions.

[0148] Furthermore, each functional module in each embodiment of the present invention may be integrated together to form a single independent part, each module may exist independently, or two or more modules may be integrated to form a single independent part.

[0149] The above functions can be realized in the form of software functional modules and stored in a computer-readable storage medium when sold or used as an independent product. Based on this understanding, the technical solution of the present invention essentially or a part that contributes to the prior art or a part of the technical solution can be expressed in the form of a software product. The computer software product is stored in a storage medium and includes a plurality of instructions to cause a computer device (which may be a personal computer, a server, a network device, etc.) to perform all or part of the steps of the methods described in each embodiment of the present invention.

[0150] The above-described preferred embodiments of the present invention have been enlightened, and those skilled in the art can make various changes and modifications based on the above description without departing from the technical spirit of the present invention. The technical scope of the present invention is not limited to the content of the specification, but should be determined based on the claims.

Claims

1. A method for converting between a table file and a graphics program, comprising the steps of: A method for converting a graphics program into a table file, wherein each step is executed by a computer, and the method includes the steps of: creating a number of empty table pages equal to the total number of main programs and nested subprograms in the graphics program; building corresponding table pages in order according to program categories in the graphics program, one page of which corresponds to the main program and all remaining pages correspond to corresponding nested subprograms; and saving the table file after the building is complete.

2. The method for building corresponding table pages in order according to the category of programs in a graphics program is as follows: A step of writing the execution units of the main program and the connections between each execution unit in text format in corresponding cells of the table page to construct a flowchart area; If the run unit is a run unit that supports execution in the right direction, the run unit, the run units connected to the run unit on the right side, and their connection relationships are displayed in cells in the same row but different columns in the order of the execution direction; 2. The conversion method according to claim 1, wherein run-unit type characters are used as the text format of the run units, and connectors are used as the text format of the connection relationships.

3. The method for building corresponding table pages in order according to the category of programs in a graphics program is as follows: A step of writing the execution units of the main program and the connections between each execution unit in text format in corresponding cells of the table page to construct a flowchart area; If the run unit is a run unit that supports execution in a downward direction, the run unit and the run units below the run unit that are connected to the run unit are displayed in order of the execution direction in cells in different rows of the same column, 2. The conversion method according to claim 1, wherein run-unit type characters are used as the text format of the run units, and connectors are used as the text format of the connection relationships.

4. The method for building corresponding table pages in order according to the category of programs in a graphics program is as follows: If there is a run unit having a nested subprogram in the main program, the connection relationship between the run unit and the run unit of the nested subprogram corresponding to the run unit is written in text format in the corresponding cell of the table page, and the table page written by the run unit of the nested subprogram is not the same as the table page written by the run unit of the main program; 2. The method of claim 1, further comprising: setting the name of the page as a cell coordinate value in which the execution unit having the nested subprogram in the main program exists.

5. The method for building corresponding table pages in order according to the category of programs in a graphics program is as follows:

2. The conversion method according to claim 1, wherein, when a nested subprogram has a run unit having a lower-level nested subprogram, the method for naming the table page in which the lower-level nested subprogram of the nested subprogram exists includes setting a separator between the name of the table page in which the nested subprogram exists and the cell coordinate value in which the run unit having the lower-level nested subprogram within the nested subprogram exists.

6. The method for building corresponding table pages in order according to the category of programs in a graphics program is as follows: defining attribute regions on each table page respectively, and constructing definition columns, name columns, comment columns and parameter setting columns in the corresponding attribute regions; In the cells of the definition column, write the text contents of the program definition, variable definition, and run unit definition in order from top to bottom. The text contents of the run unit definition are the step, which is the coordinate value of the corresponding cell, and 2. The method according to claim 1, further comprising the step of writing the attribute text content of each definition into corresponding cells of the name column, comment column and parameter setting column in order by row.

7. A method for converting between a table file for an automobile part test script and a graphics program, comprising: and converting a graphics program for an automobile part test script into a table file by the conversion method according to any one of claims 1 to 6.

8. A computer readable storage medium storing computer readable instructions which, when executed by at least one processor, cause the method of any one of claims 1 to 6 to be carried out.

9. An electronic device, a processor, and An electronic device comprising a computer-readable storage medium for storing computer-readable instructions that, when executed by a processor, cause the processor to execute a program for the conversion method according to any one of claims 1 to 6.

10. A program for causing a computer to execute the conversion method according to any one of claims 1 to 6.

11. 1. A conversion system comprising a computer device, the computer device configured to include a graphics-to-table conversion module; The graphics to table conversion module is configured to create empty table pages, the number of which is equal to the total number of main programs and nested subprograms in the graphics program, and corresponding table pages are constructed in sequence according to program categories in the graphics program, one page of which corresponds to the main program and all the remaining pages correspond to corresponding nested subprograms, and the table file after construction is completed is saved.

12. The table pages are constructed in order according to the category of the program in the graphics program. The execution units of the main program and the connection relationships between each execution unit are written in text format in the corresponding cells of the table page to construct a flowchart area; If the run unit is a run unit that supports rightward execution, the run unit, the run units connected to the run unit on the right, and their connections are displayed in the order of the execution direction in cells of the same row but different columns; If the run unit is a run unit that supports execution in the downward direction, the run unit and the run units below it connected to the run unit are displayed in order of the execution direction in cells of different rows in the same column, 12. The conversion system according to claim 11, wherein run-unit type characters are adopted as the text format of run units, and connectors are adopted as the text format of connection relationships.

13. The table pages are constructed in order according to the category of the program in the graphics program. When a run unit having a nested subprogram exists in a main program, the connection relationship between the run unit and the run unit of the nested subprogram corresponding to the run unit is written in text form in the corresponding cell of the table page, and the table page written by the run unit of the nested subprogram is not the same as the table page written by the run unit of the main program; The name of the page is set as a cell coordinate value of the run unit having the nested subprogram in the main program; 12. The conversion system of claim 11, wherein when a nested subprogram has a run unit with a lower-level nested subprogram, the method for naming the table page in which the lower-level nested subprogram of the nested subprogram exists includes setting a separator between the name of the table page in which the nested subprogram exists and the cell coordinate value in which the run unit with the lower-level nested subprogram within the nested subprogram exists.

14. The table pages are constructed in order according to the category of the program in the graphics program. Each table page defines an attribute area, and a definition column, a name column, a comment column, and a parameter setting column are constructed in the corresponding attribute area; The text contents of the program definition, variable definition, and run unit definition are written in the cells of the definition column in order from top to bottom, and the text contents of the run unit definition are the coordinate values ​​of the corresponding cells.

12. The conversion system according to claim 11, further comprising: writing the attribute text content of each definition into corresponding cells of the name column, the comment column, and the parameter setting column in order by row.

Images