JP4802775B2 - Controller support device and programmable controller - Google Patents

Description

  The present invention relates to a controller support device and a programmable controller, and in particular, a programmable controller and a user program debugging function when a general-purpose microcomputer is used as a CPU for executing a user-side application program (hereinafter referred to as “application”). Thus, the present invention relates to a controller support device and a programmable controller that support the programmable controller.

The programmable controller is a computer used for applications such as FA (Factory Automation).
Conventionally, a programmable controller is controlled mainly by bit operations such as ON / OFF of a switch, and therefore a dedicated LSI (ASIC) that can perform bit operations at high speed is often used. However, ASICs are expensive, and cannot be used for products that should have low performance or products that require low cost. In addition, with the recent increase in speed of LSIs, there is a case where a sufficiently high computing performance can be obtained by using a high-speed general-purpose microcomputer without using an ASIC. There are also many programmable controllers using general-purpose microcomputers as substitutes.

  Among such general-purpose microcomputers, microcomputers using RISC (reduced instruction set computer) instructions (hereinafter referred to as “general-purpose RISC microcomputers”) are suitable for increasing the processing speed because of the simplicity of the instruction set. Also, since it is superior in code portability to a microcomputer using a CISC (Compound Instruction Set Computer) instruction, it is used as a CPU capable of porting execution processing of a controller-dedicated machine language executed by a controller-dedicated ASIC. Has been.

As a debugging system for a programmable controller, for example, as disclosed in Patent Document 1, a system that enables step execution line by line without changing a control program has been proposed.
JP-A-9-265413

  By the way, in the conventional programmable controller described in the background art, for example, in the case of a controller using the above-mentioned general-purpose RISC microcomputer, providing a debugging function for a user program has become one problem. An example of such a debugging function is a break function.

  In this break function, there are some processes that you want to execute, such as referencing the operation results at that time and displaying the information of the operation execution flag, as well as simply stopping the execution of the user program. Must be performed for one instruction selected for break.

  In a conventional controller that implements execution of a user program using an ASIC, the program number of the currently executing user program (hereinafter abbreviated as “execution PC”) and the program position that the user wants to stop are displayed. The hardware is compared by a comparison circuit (comparator) in the ASIC, and an internal interrupt signal is generated when they match, and the break function can be realized in the interrupt processing.

  However, in a controller using a general-purpose microcomputer, it is impossible to compare execution addresses by means using hardware as described above, so a break code for performing break processing at a position where execution is to be stopped in the user program. The program is embedded and compiled in advance, and at the time of execution, whenever the control flow encounters this break process, it is downloaded to the controller and debugged.

FIG. 11 is an explanatory diagram showing the arrangement of break codes in a conventional general-purpose microcomputer controller.
As shown in FIG. 11A, a user program 72 and system firmware 74 are initially arranged in the controller memory 71. However, when the debug function is executed, as shown in FIG. In the user program 72, a break processing code 73 is inserted between the user program 72a and the user program 72a.

However, when configured in this way,
(1) Most of the user program area is consumed by the subroutine of the debug function.
(2) At the time of debugging completion, unless the user downloads a legitimate user program from which debug processing has been explicitly deleted, the debug code remains embedded in the user program, causing malfunction.
This problem is also an object of the present invention.

  The present invention has been made in view of the above-mentioned conventional problems, and eliminates the trouble of including debug code in a user program and eliminates the need for compiling and downloading accompanying debugging work. The object is to provide a device.

  Another object of the present invention is to provide a programmable controller that can automatically replace specified instructions in a user program with debug code at any timing during operation.

  In order to solve the above problems, a controller support apparatus according to the present invention is a controller support apparatus that has a debugging function and executes a user program including a debug instruction instruction such as a break setting, and means for reading the user program; Translation means for translating a controller-dedicated machine language constituting the user program into an execution code of a general-purpose microcomputer; and execution means for executing a user program corresponding to the reduced instruction set and converted into the execution code of the general-purpose microcomputer; Means for embedding an absolute branch instruction to the controller firmware for debugging in the pseudo instruction code in the user program converted to the execution code of the general-purpose microcomputer, and a break is designated by a debug instruction such as a break setting from the user The previous user program code By replacing the relative branch instruction to an absolute branch instruction directive in the code during execution of said execution means and thereby enable the debugging features.

In the controller support device, the execution means is realized by a microcomputer using RISC (that is, a reduced instruction set / computer instruction).
Moreover, the programmable controller which concerns on this invention is a programmable controller which comprises the execution means in the controller assistance apparatus of Claim 1 or Claim 2, Comprising: The branch instruction to a debugging process is arranged at a fixed address as a table. Thus, the code address change of the debug processing firmware in the controller is configured not to affect the controller support device.

  In the present invention, a debugging process procedure is configured in advance on the system firmware of the controller main body, and a code (hereinafter referred to as “pseudo instruction code”) that is not executed by a controller that is used only for reference by a support tool in a user application. The absolute branch instruction to the debugging process in the controller system firmware is embedded in the above, and when the debugging operation such as the break setting from the user is performed, the break target instruction is embedded in advance. Replacing with a branch instruction relative to the branch instruction realizes saving of the return address to the register and branching to the system firmware.

  At this time, the branch destination is changed from the debugging process itself to the branch instruction table, so that it is not necessary to modify the generated code of the support tool due to the controller firmware change, and the version dependency between the controller and the support tool And the dependency on the model is eliminated, so that the function can be updated independently of the controller body and the support tool.

  As described above, according to the programmable controller and its support device of the present invention, it is not necessary to include debug code in the user program. It has the effect of disappearing.

In addition, there is an effect that it is possible to prevent problems such as forgetting to take debug code when debugging is completed.
In addition, it is possible to automatically replace specified user program instructions with debug code at any time during operation. There is no need to consider the position on the support tool side, and the degree of freedom of change between the controller main body and the support tool is improved.

BEST MODE FOR CARRYING OUT THE INVENTION Hereinafter, a preferred embodiment of a programmable controller and its support apparatus according to the present invention will be described in detail with reference to the drawings.
FIG. 1 is a configuration diagram showing a conceptual configuration of a controller support device including a programmable controller according to an embodiment of the present invention.

  In the figure, the controller support apparatus of the present embodiment transmits a controller support unit 10 for inputting a user program, a compiler 11 for converting the input program into an executable program, and the executable program. The transmission apparatus 12 and the controller 13 (programmable controller which concerns on embodiment of this invention) which performs the program of the said execution format are provided.

  The controller support unit 10 includes an input device 15 that receives an input of the user's program, a display device 14 that displays the input program, and a storage medium 16 that stores the input program.

  In the configuration shown in FIG. 1, the compiler 11 and the controller support unit 10 are shown as different components, but both may be configured by the same hardware (for example, a personal computer) with a debugging function. Further, the transmission apparatus 12 may also be configured with the same hardware elements as these. Therefore, as another configuration of the controller support device according to the embodiment of the present invention, a configuration including the compiler 11 and the transmission device 12 in addition to the above-described configuration may be employed.

Hereinafter, the function of the programmable controller of this embodiment will be described.
The user program is input to the input device 15 of the controller support unit 10, displayed on the display device 14, and recorded on the recording medium 16.

The compiler 11 converts the input program into an executable program (object code).
The transmission device 12 transmits the execution format program to the controller 13.

The controller 13 temporarily stores the transmitted execution format program and executes it.
The controller 13 according to the present embodiment is a controller using a general-purpose RISC microcomputer, and therefore the execution code of the controller 13 is a general-purpose microcomputer machine language. Therefore, the compiler 11 performs code conversion in the order of user program → controller dedicated machine language → general purpose microcomputer machine language.

Hereinafter, the controller 13 according to the present embodiment will be described.
The controller 13 includes a general-purpose RISC microcomputer (not shown), a user program, a RAM having a data area for data used by the user program, a ROM for storing system firmware, and the like. It is a configuration for realizing a part of the controller hardware function, and in addition, there may be an interface for communication.

  The user program can be temporarily stored in a rewritable ROM (flash memory, etc.) and executed there. However, in order to speed up the processing, it is written to the flash memory at the time of download, and the access speed is higher. It is preferable to execute the program after expanding it in the RAM.

  In the case of using a commercially available controller main body as the controller 13, the system firmware is developed in a general-purpose microcomputer firmware development environment different from the support tool according to the present invention. The system firmware is already mounted on the existing controller body.

  However, the user program is created on the above-described support tool, and is converted into machine language by the compiler 11 as described above. Since the user program can access only the user data memory and the user program. Normally, the address of the function on the system firmware is not referenced from within the user program.

The branch (jump) instruction of the RISC microcomputer used in the present invention will be described below. Branch instructions include relative branches and absolute branches.
A relative branch instruction is an instruction mainly used in a subroutine call or the like. Here, the term “relative” means that it is possible to specify branching to an address that is moved by how many words (or what number of words behind) the address of the execution instruction (relative branch instruction) is the origin address. ing.

  Although this relative branch instruction has a difference in jump size, in the case of a general-purpose RISC microcomputer, it is generally composed of one instruction. Since the called subroutine needs to return to the instruction next to the branch instruction as a return destination after the processing is completed, the next execution address (return PC) is set to a register or stack at the time of execution of the branch. When the subroutine is finished, this value is set in the program counter register (PC) to realize the return from the subroutine.

  On the other hand, the absolute branch instruction is an instruction for realizing a branch by setting a specific physical address in the PC. Any address that can be set in the PC can be branched to any address. Some microcomputers do not have instructions for absolute branching, and branching is realized by generating an address on a general-purpose register and moving it to a PC. In the absolute branch instruction, the return PC in the relative branch instruction is not saved.

  Hereinafter, an example showing the above-described relative branch instruction and absolute branch instruction will be described with reference to an ARM series assembler code which is a general-purpose RISC microcomputer manufactured by ARM. ARM's general-purpose RISC microcomputer is widely used all over the world as the core of general-purpose RISC microcomputer (refer to ARM's manual etc. for its specifications).

FIG. 2 is an explanatory diagram showing registers of a general-purpose RISC microcomputer manufactured by ARM.
In the figure, the ARM general-purpose RISC microcomputer includes R0 to R15 (21) as general-purpose registers. R14 is used as a link register (LR) (22) for storing the return PC, and R15 is used as a register (PC) (23) for storing the execution PC.

FIG. 3 is an explanatory diagram illustrating relative branch instructions and absolute branch instructions as assembler codes of a general-purpose RISC microcomputer manufactured by ARM.
In the drawing, an instruction (reference numeral 31) written as bl is a relative branch instruction, and when this instruction is executed, a relative branch to an instruction labeled “Calc” is performed. In an actual machine language, such a label is converted into a relative code number up to the instruction with the label. With this instruction bl (reference numeral 31), addition of a relative address offset to the PC (general-purpose register indicated by reference numeral 23 in FIG. 2) and return to the LR (general-purpose register indicated by reference numeral 22 in FIG. 2) PC (PC of the instruction indicated by reference numeral 34 in FIG. 3) is set at the same time.

  The mov instruction indicated by reference numeral 33 in FIG. 3 is a value movement instruction between registers. Here, a value is moved from the LR to the PC, and an absolute branch that moves the control flow (execution) to the return destination. Plays the role of instruction. Therefore, execution of this mov instruction branches to the PC of the instruction next to the bl instruction indicated by reference numeral 31 (that is, the mov instruction indicated by reference numeral 34).

Hereinafter, an example of a user program assumed in the present invention will be described.
In general, various information is embedded in the user program executed by the programmable controller so that the program created by the user can be restored on the above-described support tool only by the user program on the programmable controller. These pieces of information are called pseudo instructions and are stored in the controller as codes that are not normally executed.

  When a general-purpose microcomputer is used as the controller 13, the pseudo instruction is a jump instruction to the next effective effective instruction, and arbitrary information is stored between the jump instruction and the jump destination instruction. Arbitrary information stored in this way includes a program name, a program creation date, page break information when the program screen is displayed, and the like.

FIG. 4 is an explanatory diagram showing an example of a user program executed by the programmable controller according to the present embodiment.
As shown in the figure, since the user program (user application) executed by the controller 13 is composed of a plurality of programs, a program number (reference numeral 41) for identifying them is given to each program. After that, the user describes the program code (reference numeral 42) to be processed.

FIG. 5 is an explanatory diagram showing an example of conversion of the user program shown in FIG. 4 into a controller-dedicated code.
In the figure, a DEF instruction (reference numeral 51) is pseudo code for storing a program number (reference numeral 41) in the code, and is not processed in code execution. Similarly, the END instruction (reference numeral 53) is pseudo code for indicating the end position of the program, and is not processed in code execution. In this example, for the sake of simplicity, variable names A, B, and C are used in the execution code (reference numeral 52), but the address number of the controller 13 is normally assigned.

FIG. 6 is an explanatory diagram showing an example of a code of a general-purpose microcomputer actually executed by the controller.
As shown in FIG. 5, the DEF instruction (reference numeral 51) in FIG. 5 is a b-instruction (reference numeral 61), PG0 information (reference numeral 62), and a jump label (reference numeral 61) in the general-purpose microcomputer code actually executed by the controller. 63).

  The b instruction is a kind of branch instruction and is a branch instruction that does not save the return PC to the LR. Here, the information (reference numeral 62) of the PG0 for use in the above-described support tool is skipped and used to move the execution to the jump label (reference numeral 63). Since the information of PG0 is not executed by normal program execution, it is possible to store arbitrary information that is desired to be saved. Note that the codes denoted by reference numerals 64, 65, and 66 are the execution codes shown in FIG. 5 expressed as codes of general-purpose microcomputers, but they are not important parts in the present invention, and thus description thereof is omitted.

FIG. 7 is an explanatory diagram showing an example of a user program including an absolute branch instruction to debug processing.
In the present invention, as described above, it is an object to solve the problems (1) and (2). Therefore, debugging processing is incorporated in the controller 13 in advance as system firmware, and an absolute branch instruction to the address of the debug code in the system firmware is changed to a pseudo instruction in the user program as indicated by reference numeral 81 in FIG. Keep it inside. Originally, in the support tool, it is not necessary to refer to the function address of the system firmware (BREAK_ADDR indicated by reference numeral 83 in FIG. 7). However, since the address of the break function is at most one, It is not difficult to get the address and give it to the support tool as a fixed value.

FIG. 8 is an explanatory diagram showing a memory arrangement of the controller 13 in the programmable controller according to the embodiment of the present invention.
As shown in the figure, the user program is stored in a program area denoted by reference numeral 92 in the memory built in the controller 13. The break process (reference numeral 95) is defined in advance in the system firmware (reference numeral 93). The address of the break process specified in the pseudo instruction shown in FIG. 7 is an address indicated by reference numeral 94, which is an address determined when the system firmware is generated. Now, consider setting a break for a certain instruction according to a user instruction. When an instruction position to be broken is selected on the support tool, a branch instruction that replaces the instruction is generated. The branch instruction generated here is not an absolute branch instruction but a relative branch instruction to the absolute branch instruction in the pseudo instruction.

  By the way, when an absolute branch instruction is used, at least 3 instructions are required to prepare the branch destination address in the general-purpose register, set it to the PC, and save the return address. Program operation may become abnormal. Also, in order to avoid this, there is a possibility that means such as interrupt prohibition during the replacement process is required, or the last instruction of the user program may not be replaced.

  Here, the reason for not making a relative branch directly to the break processing in the system firmware is that the address offset may exceed the relative branchable range, and the user program is placed in the controller memory in the first place. This is because it is known for the first time when the user program is actually arranged in the RAM by the controller 13 and cannot be grasped on the above-described support tool.

  Relative branching to a specific position in the user program is generally performed by jumping or loop processing of the user program, and its address generation is not difficult if the compiler function of the support tool described above is used. .

  Returning to the description, if a branch instruction that replaces the instruction at the instruction position to be broken is generated, the controller 13 requests the controller 13 to perform a replacement process for the instruction. In this case, since the instruction to be replaced is at most one instruction (one branch instruction), this instruction replacement can be performed without causing a malfunction during operation without particularly performing processing such as interrupt prohibition. .

  The instruction replacement for the break is performed on the user program developed on the RAM when there is a debugging operation from the user using the support tool. In this way, if the controller 13 is reset after the end of debugging, the user program not including the debug replacement code is re-deployed from the flash memory, so that it is possible to eliminate forgetting to delete the debug processing code. it can.

FIG. 9 is an explanatory diagram showing an example of a user program in which an instruction in the user program is replaced with a jump instruction to break processing.
If the processing of the user program shown in the figure is followed in sequence, the instruction B indicated by reference numeral 101 is executed first, and as a result, execution shifts to the instruction labeled PG0_CODE (reference numeral 104). From there, a series of instructions indicated by reference numeral 105 is executed, and a replacement instruction (reference numeral 106) is reached. Since this replacement instruction is a BL (relative branch) instruction, the address of the next instruction (reference numeral 107) is saved in LR (register indicated by reference numeral 22 in FIG. 2). Then, it moves to the address (reference numeral 102) indicated by the label (JMP_BREAK) (actually a relative offset from the instruction being executed is set). Then, since a code (reference numeral 103) for setting an address in the PC is described there, the address setting to the PC is executed, and the break processing on the system firmware is executed.

  When the break processing is completed, the instruction replaced in the break processing is restored, the address of the replaced instruction (reference numeral 106) is calculated from the address stored in the LR, and then the control flow is returned to the user program ( Here, if it is directly returned to the address indicated by LR, the processing of the instruction replaced with the relative branch instruction remains unexecuted).

FIG. 10 is an explanatory diagram for explaining a method of executing break processing with reference to a jump table.
The address of the debug function is an address that changes every time the system firmware is changed, although the number is small. Therefore, the absolute branch instruction embedded in the pseudo instruction must be changed every time the controller firmware is corrected. However, the correction or change of the main body firmware occurs asynchronously with the change of the support tool, and it is inefficient if the support tool is changed every time the main body firmware is changed.

  Therefore, as shown in FIG. 10, the absolute branch destination in the pseudo-instruction generated by the support tool is not the start address of the debug process itself, but the address to the jump table 111 that branches to the debug process. Then, if the contents of the jump table 111 (symbol 112) is used as a branch instruction to the actual break processing function start address (symbol 113), unless the position of the jump table 111 is changed, Fixes will not affect support tools.

It is a block diagram which shows the notional structure of the controller assistance apparatus containing the programmable controller which concerns on embodiment of this invention. It is explanatory drawing which shows the register of the general purpose RISC microcomputer of ARM company. It is explanatory drawing which illustrated the relative branch instruction and the absolute branch instruction by the assembler code of the general purpose RISC microcomputer of ARM company. It is explanatory drawing which shows an example of the user program performed with the programmable controller which concerns on this embodiment. It is explanatory drawing which shows the example of conversion into the controller exclusive code | cord | chord of the user program shown in FIG. It is explanatory drawing which shows an example of the code | cord | chord of the general purpose microcomputer actually performed with a controller. It is explanatory drawing which shows an example of the user program containing the absolute branch instruction to a debugging process. It is explanatory drawing which shows the memory arrangement | positioning of the controller 13 in the programmable controller which concerns on embodiment of this invention. It is explanatory drawing which shows an example of the user program which replaced the instruction with the user program with the jump instruction to a break process. It is explanatory drawing explaining the method of performing a break process with reference to a jump table. It is explanatory drawing which shows arrangement | positioning of the break code in the conventional general purpose microcomputer controller.

Explanation of symbols

DESCRIPTION OF SYMBOLS 10 Controller support part 11 Compiler 12 Transmission apparatus 13 Controller (programmable controller which concerns on this invention)
14 Display device 15 Input device 16 Recording medium 21 General-purpose register 71 Controller memory 72 User program 74 System firmware 111 Jump table

Claims (3)

A controller support device having a debugging function and executing a user program including a debug instruction instruction such as a break setting,
Means for reading the user program;
A translation means for translating a machine language dedicated to the controller constituting the user program into an execution code of a general-purpose microcomputer;
An execution means for executing a user program corresponding to a reduced instruction set and converted into an execution code of the general-purpose microcomputer;
Means for embedding an absolute branch instruction to the controller firmware for debugging in the pseudo instruction code in the user program converted into the execution code of the general-purpose microcomputer,
By replacing the user program code that has been specified by a debug instruction such as a break setting from the user with a relative branch instruction to an absolute branch instruction in the pseudo instruction code, the debugging function is enabled during execution of the execution means. A controller support device characterized by comprising:   2. The controller support apparatus according to claim 1, wherein the execution means is realized by a microcomputer using RISC (that is, a reduced instruction set / computer instruction).   3. A programmable controller constituting execution means in the controller support apparatus according to claim 1 or 2, wherein a branch instruction to debug processing is arranged as a table at a fixed address, so that code of debug processing firmware in the controller is obtained. A programmable controller characterized in that an address change does not affect the controller support device.