WO2023178723A1

WO2023178723A1 - Simulation control platform based on model development, and loading handover test method

Info

Publication number: WO2023178723A1
Application number: PCT/CN2022/084038
Authority: WO
Inventors: 杜文豪
Original assignee: 上海御微半导体技术有限公司
Priority date: 2022-03-24
Filing date: 2022-03-30
Publication date: 2023-09-28
Also published as: CN114690663A

Abstract

A simulation control platform based on model development, and a loading handover test method. The simulation control platform based on model development comprises an upper computer module (10), a process logic conversion module (20), a lower computer module (30) and a virtual object module (40), which are sequentially in communication connection, wherein the upper computer module (10) is used for communicating with the lower computer module (30); the lower computer module (30) is used for generating motion firmware that can be executed by the virtual object module (40); the virtual object module (40) is used for performing modeling design on a target control object; and the process logic conversion module (20) is used for performing logical conversion on a process in the lower computer module (30), so as to unify time sequences in the lower computer module (30) and the upper computer module (10). Nonlinear hardware is linearly modeled, such that system modeling is performed on a controlled object, so as to complete system-level test and simulation, thereby improving the development efficiency.

Description

Simulation control platform and material loading and handover test method based on model development

cross reference

This application claims priority to the Chinese application with application number 2022102961506 submitted on March 24, 2022. The contents of the above application are incorporated herein by reference.

Technical field

The invention relates to the technical field of electromechanical system equipment, and in particular to a simulation control platform based on model development and a material loading and handover test method.

technical background

With the continuous development of the manufacturing industry, precision control is particularly important in the semiconductor industry or the medical device industry. The development of a set of precision instruments requires the coordination and unification of multiple disciplines in optics, mechanics, electronics, control, and software. The development process includes requirement identification, design, material input, testing, optimized design, and launch.

Traditional model-based development only designs and develops core algorithms or functional logic, then generates code and integrates it into manual code, generates executable files, and burns them into the control board for debugging. In the automotive field, model-based development has been relatively mature for various vehicle subsystems, such as automatic power steering systems, lane departure warning systems, etc. When doing model-in-the-loop testing, there are already mature commercial software (such as Carsim, Trucksim) as a vehicle model for joint simulation testing. However, in the traditional high-precision instrument and equipment industry, such as semiconductor equipment and medical equipment, there is currently no mature commercial software to simulate control objects. The use of model-based development is relatively simple and superficial, and no development tool chain has been formed. The use of matlab/simulink is only It is limited to the simulation and analysis of control algorithms and the use of toolboxes for data analysis. The advantages of model-based development, including improving development efficiency, reducing development time and labor costs, and reducing coding work, are not reflected.

Therefore, it is necessary to provide a new model-based simulation control platform and material loading and handover test method to solve the above problems existing in the existing technology.

Summary of the invention

The purpose of the present invention is to provide a simulation control platform and a loading and handover test method based on model development. By linearly modeling nonlinear hardware, system modeling of the control object is realized to complete system-level testing and simulation, and improve Improve development efficiency.

In order to achieve the above object, the simulation control platform based on model development of the present invention includes a host computer module, a process logic conversion module, a lower computer module and a virtual object module that are communicated in sequence, wherein the host computer module is To communicate with the lower computer module, the lower computer module is used to generate motion firmware that can be executed by the virtual object module. The virtual object module is used to model and design the target control object. The process logic The conversion module is used to logically convert the processes in the lower computer module to unify the timing in the lower computer module and the upper computer module.

The beneficial effect of the simulation control platform based on model development of the present invention is that: the simulation control platform is composed of a host computer module, a process logic conversion module, a lower computer module and a virtual object module, and the nonlinear hardware is linearly modeled to realize Control objects perform system modeling to complete system-level testing and simulation through the simulation control platform, which not only reduces coding work and technical complexity, but also allows developers to focus on functionality and performance, further improving product competition. Powerful, and can run the entire machine software separately from the physical object, decouple software and hardware, and improve maintainability and inheritance.

Optionally, the process logic conversion module includes at least one of a blocking state switching unit, a periodic interrupt unit, a process switching unit and a priority switching unit. The blocking state switching unit is used to convert the blocking state in the lower computer module to The state process is switched to a non-blocking state process, and the periodic interrupt unit is used to convert the multi-period interrupt task in the lower computer module into a time slice polling task; the process switching unit is used to convert the lower computer module to a polling task. Some multi-process diagnostic tasks in the lower computer module are switched to single-process diagnostic tasks; the priority switching unit is used to adjust the priority and task scheduling of some processes in the lower computer module.

Optionally, the blocking state switching unit includes at least one of a timeout conversion subunit and an asynchronous switching subunit. The timeout switching subunit is used to set a timeout time for the blocking state process in the lower computer module, and in After waiting for the timeout period and no valid data is received, switch from the current process to execute other processes; the asynchronous switching subunit is used to switch the synchronous command processing mechanism in the communication process to an asynchronous command processing mechanism to achieve Parallel processing of multiple commands.

Optionally, the motion firmware generated in the lower computer module includes a hardware diagnostic process, which includes queue processing tasks, communication tasks, control algorithms, diagnostic tasks and command processing tasks, and the periodic interrupt unit is used to The queue processing task, the communication task, the control algorithm, the diagnostic task and the command processing task are executed according to a polling mechanism.

Optionally, the periodic interrupt unit expands the cache of the queue processing task and sets timeout logic for the communication task.

Optionally, the diagnostic tasks include chip-level diagnostic subtasks, board-level diagnostic subtasks, component-level diagnostic subtasks, and system-level diagnostic subtasks. The process switching unit switches the chip-level diagnostic subtasks, the board-level diagnostic subtasks, and the board-level diagnostic subtasks. The level diagnosis subtask, the component level diagnosis subtask and the system level diagnosis subtask are executed in the same cycle to locate the fault location and fault time.

Optionally, the priority switching unit switches the tasks of different priorities of some processes in the lower computer module to a unified priority, and switches preemptive task scheduling to non-preemptive task scheduling.

The invention also discloses a loading and handover test method, which uses the above-mentioned simulation control platform based on model development for testing. The loading and handover test method includes:

Send handover command data to the slave computer module through the host computer module, so that the slave computer module controls the virtual object module to move to the handover position and feeds back the first environment data to the slave computer module;

After the lower computer module uses the first environment data to indicate the presence of materials at the handover position, it notifies the upper computer module;

The lower computer module sends material movement command data to simulate the movement of materials to be transported and fix them at a preset position;

The upper computer module sends processing command data to the lower computer module, so that the lower computer module controls the virtual object module to move to the processing position to complete the loading test process.

The beneficial effect of the loading and handover testing method of the present invention is that the loading and handover testing method is executed through the above-mentioned simulation control platform based on model development, and the entire testing process can be completed only by the cooperation of the upper computer module and the lower computer module. The entire testing process can be completed without physical operations, which not only improves testing efficiency, but also significantly reduces testing costs and can be applied to various scenarios.

Optionally, sending handover command data to the lower computer module through the upper computer module, so that the lower computer module controls the virtual object module to move to the handover position, includes:

The host computer module sends the handover command data to the slave computer module, where the handover command data includes handover position coordinate data;

The lower computer module runs the firmware control algorithm according to the handover position coordinate data in the handover command data to obtain the first force data, and obtains the displacement data and the first sensor data before the firmware control algorithm is run;

The lower computer module sends the first force data, the displacement data and the first sensor data to the virtual object module, and runs the control object model in the virtual object module through the first force data. Algorithm to move the virtual object module to the handover position.

Optionally, the feedback of the first environment data to the lower computer module includes:

During the process of running the control object model algorithm, the displacement data and the first sensor data are obtained, and the displacement data and the first sensor data are sent to the lower computer module.

Optionally, the lower computer module sends material movement command data to simulate the movement of materials to be transported and fix them at a preset position, including:

The lower computer module sends flag information to the virtual object module to simulate the movement of materials to the preset position, where the flag information includes moving material flags and fixed material flags.

Optionally, the upper computer module sends processing command data to the lower computer module, so that the lower computer module controls the virtual object module to move to the processing position, including:

The upper computer module sends the processing command data to the lower computer module, runs the processing command data through the lower computer module to obtain the second force data, and sends the second force data to the virtual computer module. and an object module to run the control object model algorithm through the second force data to move the virtual object module to the processing position.

Description of the drawings

Figure 1 is a structural block diagram of a simulation control platform based on model development according to the embodiment of the present invention;

Figure 2 is a schematic diagram of a process based on synchronization command processing in the prior art;

Figure 3 is a schematic diagram of the process of asynchronous command processing of the simulation control platform based on model development according to the embodiment of the present invention;

Figure 4 is a schematic diagram of the hardware diagnosis process in the prior art;

Figure 5 is a schematic diagram of the processing process of the hardware diagnosis process by the simulation control platform based on model development according to the embodiment of the present invention;

Figure 6 is a schematic diagram of the processing process of a diagnostic task in the prior art;

Figure 7 is a schematic diagram of the processing process of diagnostic tasks by the simulation control platform based on model development according to the embodiment of the present invention;

Figure 8 is a schematic diagram of the processing process of tasks with different priorities in the prior art;

Figure 9 is a schematic diagram of the processing process of unified priority tasks by the simulation control platform based on model development according to the embodiment of the present invention;

Figure 10 is a schematic diagram of the design process of the simulation control platform based on model development according to the embodiment of the present invention;

Figure 11 is a flow chart of the material loading and handover test method according to the embodiment of the present invention;

Figure 12 is a schematic diagram of the specific process of the material loading and handover test method according to the embodiment of the present invention;

Figure 13 is a structural block diagram of the process logic conversion module of the simulation control platform developed based on the model according to the embodiment of the present invention.

Contents of the invention

In order to make the purpose, technical solutions and advantages of the present invention clearer, the technical solutions in the embodiments of the present invention will be clearly and completely described below in conjunction with the accompanying drawings of the present invention. Obviously, the described embodiments are part of the present invention. Examples, not all examples. Based on the embodiments of the present invention, all other embodiments obtained by those of ordinary skill in the art without making creative efforts belong to the protection scope of the present invention. Unless otherwise defined, technical or scientific terms used herein shall have their ordinary meaning understood by one of ordinary skill in the art to which this invention belongs. The use of "comprising" and similar words herein means that the elements or things appearing before the word include the elements or things listed after the word and their equivalents, without excluding other elements or things.

In view of the problems existing in the existing technology, embodiments of the present invention provide a simulation control platform based on model development. Referring to Figure 1, it includes a host computer module 10, a process logic conversion module 20, a lower computer module 30 and Virtual object module 40, wherein the upper computer module 10 is used to communicate with the lower computer module 30, and the lower computer module 30 is used to generate motion firmware that can be executed by the virtual object module 40. The virtual The object module 40 is used to model and design the target control object, and the process logic conversion module 20 is used to perform logical conversion on the processes in the lower computer module 30 to combine the lower computer module 30 and the upper computer. Timing unification in module 10.

In this embodiment, the simulation control platform forms a platform that can run independently through the upper computer module 10, the process logic conversion module 20, the lower computer module 30 and the virtual object module 40. The target control object is processed through the virtual object module 40. Modeling is designed to obtain a virtual model corresponding to the target control object, and the upper computer module 10 communicates with the lower computer module 30 to issue control instructions to control the lower computer module 30, and the lower computer module 30 is mainly used to generate The motion firmware is executed by the virtual object module 40 to control the motion of the virtual object module 40 through the lower computer module 30, thereby facilitating the control of the virtual model generated by the virtual object module 40.

In some embodiments, the simulation control platform runs on a Windows platform of a computer, and the host computer module 10 is software developed based on a programming language, which is called host computer software or host computer project (Host.sln); The lower computer module 30 is generated by the modeling software based on the motion control situation, and forms engineering firmware that can be run independently based on the centralized development environment; the virtual object module 40 is also generated by the modeling software based on the target control object modeling. The engineering firmware formed by the code; among them, the engineering firmware is a file that can be run and executed independently to facilitate the completion of the simulation process.

Specifically, in this embodiment, the upper computer module 10 is upper computer software developed based on the programming language C# or python, including interfaces, various types of drivers and module components with different functions. The lower computer module 30 and the The virtual object modules 40 are all engineering firmware modeled based on the modeling software simulink, and the centralized development environment of the lower computer module 30 and the virtual object module 40 is VS2019.

In some other embodiments, the lower computer module 30 and the upper computer module 10 run on the windows platform of the same computer, so that during the operation of the entire simulation control platform, the upper computer module 10 does not need a separate The driver software layer can control the lower computer module 30 to realize the full-scenario test process, effectively reducing the labor cost and time cost of testing.

In some embodiments, the lower computer module 30 is a motion control firmware in a semiconductor device. In this embodiment, the motion control firmware is modeled and designed through the modeling software simulink to obtain the firmware model Fireware.mdl. The coder simulink coder generates the code source file Fireware.c of the firmware model, and then imports it into the integrated development environment VS2019 to obtain the VS project Fireware.sln.

The virtual object module 40 is a Plant.mdl file obtained through the modeling and design of the modeling software simulink. It generally includes a scheduling module, an algorithm module, a diagnostic module, a communication module and a queue module. The firmware is generated through the modeling software simulink coder. The code source file Plant.c of the model is then imported into the integrated development environment VS2019 to obtain the VS project Plant.sln, so that the host computer module 30 and the virtual object module 40 can correspond one-to-one on different platforms.

Since there are many processes in the Fireware.sln file modeled by the lower computer module 30 in the integrated development environment VS2019, if the PC is directly used for process management, the user cannot complete the running status of each process because the computer is time slice polling. If it is predicted, orderly communication between the upper computer module 10 and the lower computer module 30 cannot be guaranteed. The process in the lower computer module 30 is logically converted through the process logic conversion module 20 to convert the lower computer module 30 and the lower computer module 30 . The timing in the host computer module 10 is unified to facilitate orderly communication.

In some embodiments, the process logic conversion module 20 includes at least one of a blocking state switching unit 201, a periodic interrupt unit 202, a process switching unit 203, and a priority switching unit 204. The blocking state switching unit 201 is used to convert The blocking state process in the lower computer module 30 is switched to a non-blocking state process, and the periodic interrupt unit 202 is used to convert the multi-period interrupt task in the lower computer module 30 into a time slice polling task; The process switching unit 203 is used to switch some multi-process diagnostic tasks in the lower computer module 30 to single-process diagnostic tasks; the priority switching unit 204 is used to adjust some processes in the lower computer module 30 priority and task scheduling.

In this embodiment, referring to Figure 13, the process logic conversion module 20 includes a blocking state switching unit 201, a periodic interrupt unit 202, a process switching unit 203 and a priority switching unit 204, so that the process logic conversion module 20 can The computer module 30 performs blocking state switching, cycle termination, process switching and priority switching processing, thereby unifying the communication timing between the lower computer module 30 and the upper computer module 10 in each state.

In some embodiments, the blocking state switching unit 201 includes at least one of a timeout switching subunit 2011 and an asynchronous switching subunit 2012. The timeout switching subunit 2011 is used to switch the blocking state in the lower computer module 30. The process sets a timeout, and after waiting for the timeout and not receiving valid data, switches from the current process to executing other processes; the asynchronous switching subunit 2012 is used to switch the synchronous command processing mechanism in the communication process It is an asynchronous command processing mechanism to achieve parallel processing of multiple commands.

Specifically, since multiple processes in the lower computer module 30 include communication modules and queue modules, and communication modules and queue modules generally include blocked processes, they are in a state of receiving data for a long time, resulting in It takes a long time and is time-consuming to wait. The timeout switching subunit 2011 performs timeout switching, and a timeout time t is set for the blocked process in the lower computer module 30. During the execution of the blocked process, after the timeout time t, the blocked process still does not receive the message. If there is valid data, it will switch to the execution of other tasks, thereby switching the blocking process to the non-blocking process to improve the execution efficiency of the process and avoid excessive waiting.

On the other hand, during the communication process between the upper computer module 10 and the lower computer module 30, referring to Figure 2, a synchronous command processing mechanism is usually used, that is, after the upper computer module 10 sends a command, the lower computer module 30 sequentially accepts the command, The process of command execution and response sending is completed after the host computer module 10 accepts the response. However, this method requires that the entire synchronization command processing be completed before other processes can be carried out, which prolongs the processing time of the process to a certain extent, and The timing cannot be controlled. In this solution, referring to Figure 3, by using the asynchronous switching subunit 2012 to switch synchronous command processing to asynchronous command processing, based on the asynchronous command processing mechanism, the upper computer module 10 can receive the "command acceptance" from the lower computer module 30. "After receiving the return signal of the process, other processes can be processed. There is no need to wait until the "command acceptance", "command execution" and "response sending" on the lower computer module 30 are completed and the "response accept" signal is received before proceeding. For other processes, multiple command acceptance and command execution can be processed in parallel, thereby reducing process time.

Specifically, after the upper computer module 10 sends the command to the lower computer module 30, after receiving the command, the lower computer module 30 sends an accept return instruction to the upper computer module 10, and the upper computer module 10 receives the accept return instruction. Other processes can be executed, and the command execution process is executed in the lower computer module 30. If the upper computer module 10 wants to obtain the response result, the lower computer module 30 will send the response result after receiving the instruction to send the response, and the upper computer module 10 will obtain the response result. response results, thereby realizing parallel processing of multiple command acceptance and command execution, effectively reducing the execution time of the process.

In some embodiments, the motion firmware generated in the lower computer module 30 includes a hardware diagnostic process, which includes queue processing tasks, communication tasks, control algorithms, diagnostic tasks and command processing tasks. The periodic interrupt unit 2012 is used to execute the queue processing task, the communication task, the control algorithm, the diagnosis task and the command processing task according to a polling mechanism.

Specifically, referring to Figure 4, for the hardware diagnosis process in the lower computer module 30, the traditional running sequence is a multi-cycle interrupt task. Within the time Ts, the control algorithm is first completed, and the queue processing tasks and communication tasks are completed in sequence during the rest of the time. , diagnostic tasks, but because the running environment on the computer is a time-sharing processing system, it cannot be guaranteed to be processed according to this timing. Therefore, the hardware diagnosis process is processed through the periodic interrupt unit 2012. Referring to FIG. 5, the hardware diagnosis process is changed from the original execution timing to polling.

In some further embodiments, the periodic interrupt unit 2012 expands the cache of the queue processing task and sets timeout logic for the communication task. This expands the performance of queues and communications to ensure that queue processing tasks and communication tasks will not be blocked when executing the hardware diagnostic process.

In some embodiments, the diagnostic tasks include chip-level diagnostic subtasks, board-level diagnostic subtasks, component-level diagnostic subtasks, and system-level diagnostic subtasks. The process switching unit 2013 converts the chip-level diagnostic subtasks into The board-level diagnosis subtask, the component-level diagnosis subtask and the system-level diagnosis subtask are executed in the same cycle to locate the fault location and fault time.

Specifically, referring to Figure 6, the traditional method is to interrupt chip-level diagnostic subtasks, board-level diagnostic subtasks, component-level diagnostic subtasks and system-level diagnostic subtasks in different cycles. For example, the chip-level diagnostic subtask is interrupted in The board-level diagnostic subtask is scheduled to interrupt at 200us, the component-level diagnostic subtask is scheduled to interrupt at 500us, and the system diagnostic subtask is scheduled to interrupt at 1ms. However, because the priority and timing mechanisms in the computer cannot operate effectively at the same time, this This method cannot ensure that the diagnostic subtasks are executed in a multi-cycle time and sequence, which affects the efficiency of fault diagnosis. In this solution, referring to Figure 7, chip-level diagnostic subtasks, board-level diagnostic subtasks, component-level diagnostic subtasks, and system-level diagnostic subtasks are run cyclically within a diagnostic cycle to ensure that on the computer time flow Complete each diagnostic function in a controllable manner, locate the corresponding fault location and time, complete the fault diagnosis process, and improve diagnostic efficiency.

In some embodiments, the priority switching unit 204 switches tasks with different priorities of some processes in the lower computer module 30 to a unified priority, and switches preemptive task scheduling to non-preemptive task scheduling.

Specifically, refer to Figure 8, taking five execution tasks as an example. The priorities of task one, task two and task three increase in sequence. When task one returns to the ready state from the suspended state, under the action of the preemptive scheduler, The execution of task one will be preempted by task two. The implementation of this task preemption logic on the computer is more complicated, and when there are shared resources, it is difficult to realize the common use of multiple tasks. Therefore, this solution uses the priority switching unit 2014 to switch tasks of different priorities in some processes to a unified priority, and switches preemptive task scheduling to non-preemptive task scheduling, which can effectively reduce the workload of task allocation and timing design. Referring to Figure 9, the design is four tasks one, two, three and four with the same priority. The time allocated to each task is fixed and is a multiple of the system clock, such as 5 times. The running process is as follows: run task one first, and after running for 5 clock cycles, switch to task two through time slice scheduling. After task two runs for 5 system clock cycles, switch to task three through time slice scheduling. Task three is in The blocking API function is called during operation. After calling the function, it will switch to the next task four through time slice scheduling. Even if the five system time ticks of task three have not been used up at this time, task four will run for five system clock ticks. , switch to task one through time slice scheduling. Under the above time slice polling, the workload of task allocation and task timing design can be reduced, and the platform construction time is greatly reduced.

In some other embodiments, for different devices, the design process of the lower computer module 30 and the virtual object module 40 in the simulation control platform is as follows:

First, input the characteristic information of the target control object and the characteristic information of the motion firmware into the simulation software Simulink. The characteristic information of the target control object includes mechanical characteristic information, electrical characteristic information, motion characteristic information and application scenario characteristic information. The characteristic information of the motion firmware Including functional requirement information and performance requirement information, the simulation software Simulink models the target control object and motion firmware. After the modeling is completed, the target control object and motion firmware are integrated for simulation testing based on the simulation software Simulink to further optimize the model. The project files Plant.mdl and Firmware.mdl corresponding to the virtual object module 40 and the host computer module 30 are obtained respectively.

Since the obtained optimization model is a project file in mdl format, Plant.mdl and Firmware.mdl are synchronized to generate C language code, and a .sln project file is formed based on the integrated development environment VS2019, that is, Plant.sln and Firmware.sln, which can be found in Plant.sln and Firmware.sln are jointly tested under the integrated development environment to verify the accuracy of the final model. Specifically, the testing process is software-in-the-loop testing.

It should be noted that during the design process of motion firmware and target control objects, the design of the host computer module is completed simultaneously to obtain the corresponding project file Host.sln of the host computer, which can then be combined with Plant.sln and Firmware.sln. Test, complete the full-scenario test of the host computer module, and finally verify with the hardware, the final host computer module 10 can be obtained to complete the model design process.

In some embodiments, the specific design process is as follows. Referring to Figure 10, the firmware design process is first carried out. After the characteristic information of the target control object and the characteristic information of the motion firmware are input into the simulation software Simulink, the code is modeled and generated respectively and obtained Project files Plant.mdl and Firmware.mdl; then perform firmware function test, performance test and interface test on the project files Plant.mdl and Firmware.mdl respectively. If the motion firmware is not tested, optimize the Firmware.mdl and retest until After the test is completed, the firmware design process ends.

Then enter the host computer design process, input the host computer requirements, develop the corresponding host computer model, and perform test optimization to obtain the optimized host computer model. After the host computer model is debugged, conduct full-scenario testing, and complete the full scenario After the testing process, continue to judge whether the debugging is completed. After confirming that the final debugging of the host computer model is completed, the design process ends and the final host computer model is obtained. Among them, every time it is judged whether the debugging is completed, if the debugging is not completed, the process of testing and optimizing the host computer model will continue to be performed, which will not be described again here.

It should be noted that the simulation control platform of the present invention is suitable for traditional manufacturing industries, including medical equipment, semiconductor equipment and other equipment that require high-precision control. Based on this simulation control platform, the software development process can be freed from the constraints of hardware. , through precise analysis and complete modeling of the control objects, the host computer can complete the entire process test in the Windows environment. When installing the complete machine, the host computer only needs to debug the performance of the device, and the workload related to the hardware is It can be greatly reduced, and the development time can be greatly shortened and the development efficiency can be improved.

The present invention also provides a loading and handover test method. Referring to Figure 11, the above-mentioned simulation control platform based on model development is used for testing. The loading and handover test method includes the steps:

S1101. Send handover command data to the slave computer module through the host computer module, so that the slave computer module controls the virtual object module to move to the handover position and feeds back the first environment data to the slave computer module.

In some embodiments, sending handover command data to the lower computer module through the upper computer module, so that the lower computer module controls the virtual object module to move to the handover position, includes:

The lower computer module runs a firmware control algorithm according to the handover position coordinate data in the handover command data to obtain the first force data, and obtains the displacement data and the first sensor data before the firmware control algorithm is run;

Specifically, with reference to Figure 12, at the beginning of loading, the host computer module first sends the data containing the handover position coordinates to the lower computer module through Ethernet, so as to control the XY axis movement in the loading equipment to the handover position, where the handover position The coordinate data is recorded as (x _exchange , y _exchange ).

After the lower computer module receives the handover position coordinate data in the handover command data, the lower computer module cyclically runs the firmware control algorithm according to the handover position coordinate data to obtain the first force data, and sends the first force data through the Ethernet after each cycle. force data to the virtual object module. At the same time, the slave computer module obtains the displacement data and the first sensor data respectively when running the firmware control algorithm in each cycle. The displacement data is the displacement data of the XY axis moving to the handover position. The first sensor data includes sensor data Flag _EX of the handover position.

Afterwards, the lower computer module sends the first force data, the displacement data and the first sensor data to the virtual object module, and runs the control object model algorithm in the virtual object module according to the first force data, thereby causing the virtual object module to simulate Move to the handover position to complete the preliminary motion simulation process.

In some embodiments, the feedback of the first environment data to the lower computer module includes:

Specifically, after each cycle of running the control object model algorithm ends, the displacement data and the first sensor data are sent to the lower computer module to facilitate subsequent judgment of whether there is material at the handover position.

S1102. After the lower computer module uses the first environment data to indicate the presence of materials at the handover position, notify the upper computer module.

Specifically, after the host computer module receives the first environment data, it obtains the pressure data of the vacuum sensor in the first environment data to determine whether there is material at the handover position. After determining that the material exists, a notification message is sent to the host computer module so that The loading process is simulated in the host computer module.

S1103. The lower computer module sends material movement command data to simulate the movement of materials to be transported and fix them at a preset position.

In some embodiments, the process includes:

Specifically, the lower computer module sends moving material flags and fixed material flags to the virtual object module respectively, thereby simulating the process of the material moving to the preset position. Among them, the moving material mark indicates that the robot moves the material to the corresponding position in the equipment, while the fixed material mark indicates that the simulated vacuum solenoid valve is opened to vacuum to simulate the material being fixed at the corresponding position.

In some embodiments, the process of simulating the material moving to the corresponding position and being fixed at the corresponding position is set to 1 to 10 seconds.

S1104. The upper computer module sends processing command data to the lower computer module, so that the lower computer module controls the virtual object module to move to the processing position to complete the loading test process.

In some embodiments, the above process includes:

When the material moves and is fixed at the corresponding position, the upper computer module sends processing command data to the lower computer module, so that the lower computer module runs the firmware model algorithm according to the processing command data to obtain the second force data, and sends the second force data to The virtual object module enables the virtual object module to run the control object model algorithm according to the second force data, thereby moving the virtual object module to the processing position on the platform to complete the entire loading and testing process.

Wherein, the processing command data includes processing position coordinate data

In order to facilitate the virtual object module to simulate movement to this position.

In the above loading and handover test method, the loading and handover test is carried out through the simulation control platform established above. The entire loading and handover process can be tested only in the Windows environment of the computer. There is no need to use With physical testing, the workload related to hardware is greatly reduced, which not only effectively reduces testing time, but also improves development efficiency.

Although the embodiments of the present invention have been described in detail above, it will be obvious to those skilled in the art that various modifications and changes can be made to these embodiments. However, it should be understood that such modifications and changes are within the scope and spirit of the invention as described in the claims. Furthermore, the invention described herein is capable of other embodiments and of being practiced or carried out in various ways.

Claims

A simulation control platform based on model development, characterized by including a host computer module, a process logic conversion module, a slave computer module and a virtual object module that are communicated with each other in sequence, wherein the host computer module is used to communicate with the slave computer module communicates, the lower computer module is used to generate motion firmware that can be executed by the virtual object module, the virtual object module is used to model and design the target control object, and the process logic conversion module is used to The process in the lower computer module is logically converted to unify the timing in the lower computer module and the upper computer module.
The simulation control platform based on model development according to claim 1, characterized in that the process logic conversion module includes at least one of a blocking state switching unit, a periodic interrupt unit, a process switching unit and a priority switching unit, and The blocking state switching unit is used to switch the blocking state process in the lower computer module to a non-blocking state process, and the periodic interrupt unit is used to convert the multi-cycle interrupted tasks in the lower computer module into time-based rounds. The process switching unit is used to switch some multi-process diagnostic tasks in the lower computer module to single-process diagnostic tasks; the priority switching unit is used to adjust some processes in the lower computer module priority and task scheduling.
The simulation control platform based on model development according to claim 2, characterized in that the blocking state switching unit includes at least one of a timeout switching subunit and an asynchronous switching subunit, and the timeout switching subunit is used to The blocked process in the lower computer module sets a timeout, and after waiting for the timeout and no valid data is received, it switches from the current process to executing other processes; the asynchronous switching subunit is used to switch the communication process The synchronous command processing mechanism in is switched to an asynchronous command processing mechanism to achieve parallel processing of multiple commands.
The simulation control platform based on model development according to claim 2, characterized in that, the motion firmware generated in the lower computer module includes a hardware diagnosis process, and the hardware diagnosis process includes queue processing tasks, communication tasks, control algorithms, Diagnosis task and command processing task, the periodic interrupt unit is used to execute the queue processing task, the communication task, the control algorithm, the diagnosis task and the command processing task according to the polling mechanism.
The simulation control platform based on model development according to claim 4, characterized in that the periodic interrupt unit expands the cache of the queue processing task and sets timeout logic for the communication task.
The simulation control platform based on model development according to claim 4, characterized in that the diagnostic tasks include chip-level diagnostic sub-tasks, board-level diagnostic sub-tasks, component-level diagnostic sub-tasks and system-level diagnostic sub-tasks. The process switching unit executes the chip-level diagnosis subtask, the board-level diagnosis subtask, the component-level diagnosis subtask and the system-level diagnosis subtask in the same cycle to locate the fault location and fault time.
The simulation control platform based on model development according to claim 2, characterized in that the priority switching unit switches the tasks of different priorities of some processes in the lower computer module to a unified priority, and preemptively Task scheduling switches to non-preemptive task scheduling.
A loading and handover test method, characterized in that the simulation control platform based on model development according to any one of the above claims 1 to 7 is used for testing, and the loading and handover test method includes:

Send handover command data to the slave computer module through the host computer module, so that the slave computer module controls the virtual object module to move to the handover position and feeds back the first environment data to the slave computer module;

After the lower computer module uses the first environment data to indicate the presence of materials at the handover position, it notifies the upper computer module;

The lower computer module sends material movement command data to simulate the movement of materials to be transported and fix them at a preset position;

The upper computer module sends processing command data to the lower computer module, so that the lower computer module controls the virtual object module to move to the processing position to complete the loading test process.
The material loading and handover test method according to claim 8, characterized in that the handover command data is sent to the slave computer module through the host computer module, so that the slave computer module controls the virtual object module to move to the handover position, include:

The host computer module sends the handover command data to the slave computer module, where the handover command data includes handover position coordinate data;

The lower computer module runs a firmware control algorithm according to the handover position coordinate data in the handover command data to obtain the first force data, and obtains the displacement data and the first sensor data before the firmware control algorithm is run;

The lower computer module sends the first force data, the displacement data and the first sensor data to the virtual object module, and runs the control object model in the virtual object module through the first force data. Algorithm to move the virtual object module to the handover position.
The material loading and handover test method according to claim 9, characterized in that the feedback of the first environmental data to the lower computer module includes:

In the process of running the control object model algorithm, the displacement data and the first sensor data are obtained, and the displacement data and the first sensor data are sent to the lower computer module.
The material loading and handover test method according to claim 8, characterized in that the lower computer module sends material movement command data to simulate the movement of the material to be transported and fix it at a preset position, including:

The lower computer module sends flag information to the virtual object module to simulate the movement of materials to the preset position, where the flag information includes moving material flags and fixed material flags.

The material loading and handover test method according to claim 8, characterized in that the upper computer module sends processing command data to the lower computer module, so that the lower computer module controls the virtual object module to move to the processing position. ,include:
The upper computer module sends the processing command data to the lower computer module, runs the processing command data through the lower computer module to obtain the second force data, and sends the second force data to the virtual computer module. and an object module to run the control object model algorithm through the second force data to move the virtual object module to the processing position.