JPS58222357A - Debug system of drive control program - Google Patents

Abstract

PURPOSE:To attain quickly the debug of a control drive program, by replacing the characteristics of the drive system hardware into a software program and regarding it as the drive system hardware for executing the drive control program. CONSTITUTION:A CPU 1, a memory 3, and an interface circuit 4 are coupled to a bus 2 to control a drive system 11 in a robbot drive controller. In debugging the drive control program PG, various characteristics data of the drive system hardware 11 and a drive system simulation SMPG and the PG relating to a CRT display 15 are stored in advance in a memory 13 of a debugging processor 16, the drive system SMPG is executed the same as the execution of the drive control PG of the memory 3 and the result of SM is saved and stored in the memory 3. After the SM, the result of analysis is displayed on the display 15 after analyzing the control state by using the result. If the result of analysis is inadequate, the characteristics data of the hardware is changed and if the drive control PG is in error, the processor 16 corrects it and the SMPG is executed again.

Description

DETAILED DESCRIPTION OF THE INVENTION The present invention relates to a drive control program debugging method for debugging a drive control program in a state where optimal conditions for drive control can be predicted without actually performing drive control.

Conventionally, in debugging devices including drive systems, the software program and hardware are debugged separately and then combined to drive and control the drive system using a drive control program that is also guaranteed to be reliable. This is the actual situation. Separate debugging is performed because if these are combined to control the drive system without debugging, an uncertain drive control program or a defect in the drive system hardware will result in the drive system running out of control. This is because there is a risk of causing damage to the surrounding area. However, even if debugging is performed separately, the debugging is done in a separate state, and it is impossible to ensure that the debugging is complete. As described above, it is generally not easy to set the optimal control conditions, and there are problems in that setting is risky and takes a lot of time.

SUMMARY OF THE INVENTION Therefore, an object of the present invention is to provide a drive control program debugging method that allows a drive control program to be quickly debugged in a state where optimal control conditions can be predicted without actually driving drive system hardware.

For this purpose, the present invention debugs the drive control program by replacing the characteristics of the drive system hardware with a software program, treating this as the drive system hardware, and running that program simultaneously with the execution of the drive control program. This is how it was done.

Hereinafter, the present invention will be explained with reference to FIGS. 1 to 3, taking as an example the drive control of a robot.

FIG. 1 shows a robot drive control system according to the present invention. According to this figure, other processing devices can be directly connected to the bus 2 for the control processing device that executes the drive control program, or other processing devices can be connected to the bus 2 as appropriate. It is possible to connect if the device is equipped with input/output devices. The control processing unit has a CPU on bus 2 as shown in the figure.
1. Memory 3 and external connection interface circuit 4
)-C, and the drive system 11 is controlled by this control processing device.
be. “□□:: That is, the drive control program and robot passing point data are stored in advance in the memory 3 via the external connection interface circuit 4.
pvl is designed to execute the drive control program using robot passing point data appropriately.

Drive control command data is sequentially generated by executing the drive control program, and this drive control command data controls the rotation of a DC servo motor 8 for driving the robot via a D/A converter 5 and a servo amplifier 6. That's why. When the DC servo motor 8 rotates, its rotation speed is detected by the tacho generator 9 for feedback control, and its rotation amount or rotation position can be known by counting the rotation pulses from the encoder 10 with the counter 7. This is what has become.

Normal drive control is performed as described above, but when debugging a drive control program, at least the drive system 11 is not controlled by the program. The debugging processing device 16 is configured to execute a software program (drive system simulation program) replaced by drive system hardware.The processing device 16 includes a CPU 12, a memory 13, an interface circuit 14, etc. However, a CRT display device 15 having a keyboard input function is accommodated and connected to the processing device 16 as an input/output device via an interface circuit 14.
It is possible to connect directly to

Therefore, if the drive system simulation program is stored in the memory 13 in advance, the drive system simulation program is executed at the same time as the drive control program is executed, and the simulation results are saved and stored in the memory 13, after the simulation Using these results, it is possible to analyze the control situation and display the analysis results on the CRT display device 15. The memory 13 stores in advance various characteristic data regarding the drive system hardware, an input/output control program regarding the CRT display device 15, etc., in addition to the drive system ξ acceleration program. .

Now, how the drive control program is debugged will be explained as follows.

That is, prior to debugging, the processing device 16 is first connected to the control processing device via the bus 2. In this situation, cR
When the CPU 12 is activated by the I' display device 15,
The display on the CE display screen is as shown in FIG. 2, and the necessary one can be selected from the nine menus. Here, the "DATA INPUT" mode is first selected.

With this selection, the display on the CRT display screen becomes as shown in FIG. 3, prompting input of initial values and characteristics of various data required for the simulation. For example, regarding the D7A conversion, the initial value is "0" assuming that the motor starts from a stopped state, and the characteristic is the digital value ""7FFF (1
When outputting an analog value of "+1r)V" for 1 (in hexadecimal notation), these relationships are input as shown in FIG. These values are stored in the memory 13, but if the analog value corresponding to the given digital value is calculated by proportional calculation based on the above relationship when the simulation program is executed, it will be as if the D7A converter 5
It can perform the same function as .

Further, to explain the remaining parts in detail, the initial value of the servo amplifier 6 is set to "0", and the amplification factor is input. For example, if the output voltage is "50V" with respect to the input voltage "10r1" and the input/output characteristics can be expressed by a linear relationship, that relationship should be input as shown in FIG.

In this case, since the servo amplifier 6 is feedback-controlled by the output of the tacho generator 9, the servo amplifier 6
It is also necessary to input the transfer function of This is Sil M
The shimmy range result for the conversion is λ′□
, the output value is determined based on the characteristics. Further, the characteristics of the rotation speed with respect to the input voltage are similarly input for the DC servo motor 8. As a result, the number of rotations of the DC servo motor 8 during shimmy rayon is calculated. Furthermore, the relationship between the rotational speed of the DC servo motor 8, the output voltage, and the number of generated pulses is input to the tachogenerator 9 and the encoder 10. Finally, regarding the counter 7, information such as how many pulses of the 10-color encoder are used for one count and whether the mode is count-up mode or count-down mode are entered. Such input settings are made for each drive axis of the robot. In addition, when expressing characteristics, there are cases where it is not possible to express them using a linear relationship. The output can be found by doing this.

When the input of various data required for the simulation, such as initial values and characteristics, is completed in this way, the screen returns to the menu and the "511111.Ir1QN" mode is selected next. This starts the simulation program. After starting the simulation program, the drive control program and robot passing point data are stored in the memory 3 via the external connection interface circuit 4, and the CPU 1 is started to execute the drive control program. be.

Normally, the CPU 1 sequentially generates drive control command data by appropriately using robot passing point data and executing a drive control program, and generates drive control command data for the DyA converter 5 and servo amplifier 6.
Although it has already been described that the DC servo motor 8 is drive-controlled through the simulator, when the shimmy race is started, the operation of the drive system 11 is substituted by the execution of a simulation program. In this case, the control processing device executes the drive control program, and the processing device 1
6, the simulation programs are executed in parallel at the same time, but the execution of the simulation program is
It is clear that this is not particularly burdensome for U 1. That is, the drive control program can be executed as if the drive system 11 is actually controlled, and the drive control program can be debugged in the same drive control state. The processing device 16 executes a simulation program based on the drive control command data given by CWl and various characteristic data stored in the memory 13, and as a result, it performs the same function as the counter 7. Therefore, the CPU 1 can execute the drive control program as if the drive system 11 actually existed. If there is an error in the drive control program during execution, or if the set drive system 11
If the characteristics of the debugger are inappropriate, an error message is displayed and the execution of the program is stopped, so that not only the drive control program but also the drive system 11 can be debugged at the same time without any danger.

By the way, while the drive control program and the simulation program are being executed, various intermediate results of the simulation are saved and stored in the memory 13. Therefore, it is easy to analyze the operation of the drive system 11 using these intermediate results. It is not enough for the robot to simply move through the taught passage points; its movement speed must be variable and appropriate. Therefore, operation analysis is required after simulation. Menu after simulation “MONITO”
By selecting the R' mode and specifying the analysis items, the operating status is displayed on the CRT display screen and numerical analysis becomes possible. For example, the relationship between the speed, acceleration curve, and drive control command data indicating motor followability from startup to stop of the robot and the count value of the counter can also be displayed as a graph or table. If the analysis result is inappropriate, please return “DATAIN” again.
After selecting the PUT' mode, changing the characteristic data, and taking measures such as correcting any errors in the drive control program using the processing unit 16, the simulation program is executed again. Make it.

In this case, the drive control program can be modified without danger, or the drive system can be quickly debugged, and the characteristics of the drive system hardware can be adjusted to match the optimal conditions obtained through debugging. This can be adjusted.

As explained above, the present invention replaces the characteristics of the drive system hardware with a software program so that the characteristics can be changed, and considers this as the drive system hardware.At the same time as the drive control program is executed, the software program can be used to generate intermediate results. It can be displayed externally and the depth can be increased using another processing device. Therefore, in the case of the present invention, the drive control program or the drive system can be quickly debugged without actually controlling the drive system hardware and without any danger. The effect is that optimal control conditions can be found by analyzing intermediate results.

[Brief explanation of drawings]

FIG. 1 is a diagram showing a robot drive control system according to the present invention;
FIGS. 2 and 3 are diagrams showing display examples of a CRT display device as an input/output device according to the present invention. 1...C for control processing) CPU S...(for control processing) Memory 11...Drive system 12...
・CPU 15 (for debugging), memory 15 (for debugging), CRI display device (as an input/output device) Patent attorney Susuki 1) Utilization: 1. '7:j-,l',k. 3 〒1 figure 1 1,02 figure coin 5 figure

Claims (1)

[Claims] The characteristics of the drive system hardware are replaced with a software program so that the characteristics can be changed, and the program is regarded as the drive system hardware and the drive control program is executed in the control processing unit. A drive control program debugging method characterized in that the software program is executed with intermediate results displayed.