Crown block operation control system

Abstract

The invention discloses a crown block operation control system which comprises a main program and a real-time processing core used for carrying out motion execution control on a crown block, the main program and the real-time processing core are communicated with a daemon program module, and the daemon program module monitors the operation states of the main program and the real-time processing core and sends the real-time processing core to the main program when it is determined that the main program operates abnormally. And closing the real-time processing core, and restarting the real-time processing core when it is determined that the real-time processing core runs abnormally. The running states of the main program and the real-time processing core are monitored by setting the daemon module, and when the main program is abnormal, the real-time processing core for controlling the crown block to run can be stopped immediately, so that wrong processing of the real-time processing core caused by the abnormality of the main program is avoided, the collision of the crown block can be greatly reduced, and the service life of the crown block is prolonged. And meanwhile, the abnormal condition of the real-time processing core can be timely found and processed, so that the reliable operation of the real-time processing core is effectively ensured.

Description

Technical Field

[0001] The present invention relates to the field of overhead crane handling systems, especially the overhead crane operation control system. Background Art

[0002] The OHT system is a dedicated material handling system, which realizes the handling of materials by the movement of an overhead crane on a suspended track.

[0003] The overhead crane is controlled by an overhead crane operation control system. The overhead crane operation control system includes a main program running in a first core (main core) and a real-time processing core (slave core) communicating with the first core. The main program is responsible for sending control instructions for controlling the overhead crane to execute various actions to the real-time processing core, and the real-time processing core is responsible for executing the corresponding control instructions so that the overhead crane executes various actions.

[0004] During the operation of the overhead crane, when an exception occurs in the main program of the overhead crane operation control system, the operation of the real-time processing core is not affected. If the main program has an exception after sending a control instruction indicating that the overhead crane travels at high speed to the real-time processing core, the real-time processing core will still control the overhead crane to travel at high speed according to the control instruction, which may cause the overhead crane to hit the track at high speed and cause economic losses. For example, the main program sends a control instruction to move at a speed of 5 m / s to the real-time processing core. After the instruction is sent, the main program has an exception, and the real-time processing core will still control the overhead crane to move at a speed of 5 m / s. When the overhead crane runs to a turning track, the overhead crane will hit the turning track, causing damage to the turning track and the overhead crane.

[0005] Moreover, the main program requires high real-time performance, which makes the main program unable to "distract" to monitor the system load, resulting in the inability to adjust the control strategy in real time according to the current system load situation. Summary of the Invention

[0006] The purpose of the present invention is to solve the above problems existing in the prior art and provide an overhead crane operation control system.

[0007] The purpose of the present invention is achieved through the following technical solutions: An overhead crane operation control system includes a main program and a real-time processing core for controlling the execution of the movement of the overhead crane, and further includes a daemon program module. The daemon program module monitors whether there is an exception in the main program during operation after normal startup. When it is detected that there is an exception in the main program during operation, the daemon program module shuts down the real-time processing core. And / or, the daemon program module monitors whether there is an exception in the real-time processing core during operation after normal startup. When it is detected that there is an exception in the real-time processing core during operation, the daemon program module restarts the real-time processing core.

[0008] Preferably, a semaphore is adopted between the main program and the daemon program module to implement inter-process communication.

[0009] Preferably, when the semaphore used for communication between the main program and the daemon program module does not perform an increment operation within a specified time, the daemon program module shuts down the real-time processing core.

[0010] Preferably, when the overhead traveling crane operation control system starts, the daemon program module is started by systemd. After the daemon program module starts, it starts the main program and monitors whether the main program starts normally. When it is determined that the main program starts normally, the watchdog monitors whether the main program runs normally.

[0011] Preferably, the daemon program module determines whether the main program starts normally by monitoring the proc_events file in the kernel space to determine whether the initialization event feedback by the main program is received within a specified time.

[0012] Preferably, after calling the script to start the real-time processing core, the daemon program module monitors the uevent event in the kernel space and determines whether the real-time processing core start event is detected within a scheduled time. If so, the daemon program module uses inotify to monitor the Message log of the Linux system and determines whether there is a change in the Message log of the Linux system. When it is determined that there is a change, the daemon program module reads the content of the Message log of the Linux system and determines whether it contains the watchdog-unfed flag. If so, the daemon program module calls a custom script to restart the real-time processing core.

[0013] Preferably, the daemon program module determines the occupancy rate of each core and / or the CPU occupancy rate and / or the CPU load by periodically reading the / proc / stat file and stores them in the shared memory.

[0014] Preferably, the daemon program module sends data packets to the hardware watchdog of the overhead traveling crane operation control system at a certain period. If the daemon program module fails to send data packets on time, the hardware watchdog generates a restart signal to restart the overhead traveling crane operation control system.

[0015] Preferably, the daemon program module monitors the real-time performance of each core of the overhead traveling crane operation control system and stores the monitored real-time performance data in the shared memory.

[0016] Preferably, the main program obtains the real-time performance data from the shared memory and adjusts the running speed of the overhead traveling crane according to the real-time performance data.

[0017] The advantages of the technical solution of the present invention are mainly reflected in: The present invention monitors the operating states of the main program and the real-time processing core by setting a daemon module. When the main program is abnormal, the real-time processing core that controls the operation of the overhead crane can be immediately stopped, avoiding incorrect control caused by the abnormal main program while the real-time processing core works normally, effectively avoiding the problem of the overhead crane hitting the track, reducing safety accidents, and at the same time being able to promptly detect and handle abnormal conditions of the real-time processing core, effectively ensuring the reliable operation of the real-time processing core.

[0018] The present invention also communicates with the daemon module through a hardware watchdog, so that the entire operating control system can be restarted when the daemon module is abnormal, further ensuring the reliable operation of the entire system.

[0019] The daemon module of the present invention can monitor in real time system load data such as the real-time performance and occupancy rate of each core of the operating control system and share the data with the main program. The main program does not need to be distracted to monitor the system load, and the main program can adjust the operation of the overhead crane and the operation of the system according to the system load and real-time performance data monitored by the daemon module, making the main program have a stronger control over the overhead crane and avoiding the situation where the system freezes and the overhead crane cannot be controlled. BRIEF DESCRIPTION OF THE DRAWINGS

[0020] Figure 1 is a schematic diagram of the overhead crane operating control system of the present invention; Figure 2 is a schematic diagram of the process of the daemon module of the present invention monitoring the main program; Figure 3 is a schematic diagram of the process of the daemon module of the present invention monitoring the real-time processing core. DETAILED DESCRIPTION OF THE INVENTION

[0021] The objectives, advantages and features of the present invention will be illustrated and explained by the following non-limiting description of preferred embodiments. These embodiments are only typical examples of applying the technical solutions of the present invention, and any technical solutions formed by equivalent replacement or equivalent transformation fall within the scope of protection required by the present invention.

[0022] In the description of the solution, it should be noted that the orientation or positional relationship indicated by the terms "center", "upper", "lower", "left", "right", "front", "rear", "vertical", "horizontal", "inner", "outer", etc. is based on the orientation or positional relationship shown in the drawings, and is only for the convenience of description and simplification of the description, rather than indicating or implying that the device or element referred to must have a specific orientation, be constructed and operated in a specific orientation, and therefore cannot be understood as a limitation of the present invention. In addition, the terms "first", "second", "third" are only used for descriptive purposes and cannot be understood as indicating or implying relative importance.

[0023] Embodiment 1 The overhead crane operation control system disclosed by the present invention will be described below in conjunction with the accompanying drawings. As shown in the attached drawings Figure 1 it includes a first core and a real-time processing core communicating with the first core. The first core adopts the Linux system, which has powerful performance and is used to run high-performance programs such as the main program. The main program is used for communicating and interacting with the server, sending control instructions for controlling the movement of the overhead crane to the real-time processing core according to the server instructions, etc.

[0024] The real-time processing core runs a real-time operating system (RTOS, Real-Time Operating System) and has extremely strong real-time performance. Based on the strong real-time characteristics of the real-time processing core, the real-time processing core is used to run the EtherCAT (EtherCAT) master station and perform motion execution control. For example, controlling the overhead crane to perform forward and backward movement actions, controlling the overhead crane to perform steering actions, controlling the grasping device on the overhead crane to perform picking and placing actions, controlling the lifting mechanism on the overhead crane to perform lifting actions, controlling the translation mechanism on the overhead crane to perform translation actions, etc.

[0025] When the main program needs to make the overhead crane perform a certain action, it issues a control instruction to the real-time processing core through the interface. The real-time processing core will execute the corresponding control instruction to make the overhead crane complete the corresponding action and return the execution result to the main program. Since the main program is in the first core and the motion execution is in the real-time processing core, the communication between the cores needs to use the rpmsg protocol under the OpenAMP architecture. The corresponding communication technology is a known technology and will not be elaborated here.

[0026] As shown in the attached drawings Figure 1 the overhead crane operation control system further includes a daemon program module. The daemon program module runs in the background and monitors whether there are any abnormalities during the operation of the main program after normal startup and / or the real-time processing core after normal startup; when it is detected that there is an abnormality during the operation of the main program, the real-time processing core is shut down; when it is determined that there is an abnormality during the operation of the real-time processing core, the real-time processing core is restarted.

[0027] The daemon program module and the main program implement inter-process communication using semaphores. The daemon program module and the real-time processing slave core communicate using the rpmsg protocol under the OpenAMP architecture. Moreover, when the semaphore used for communication between the main program and the daemon program module is not incremented within a specified time, the daemon program module directly uses the Remoteproc framework to shut down the real-time processing core. When the real-time processing core is shut down, the ECAT master station deployed on the real-time processing core will stop running. At this time, the servo system on the overhead crane will automatically stop because it cannot receive periodic control data, and thus all actions of the overhead crane will stop.

[0028] The daemon program module introduces JSON as a configuration file to improve the configurability of the daemon program module. Some functions can be enabled or disabled, and the parameters of the daemon program module can be modified in the configuration file.

[0029] As shown in the appendix Figure 2 When the overhead crane operation control system is powered on, the systemd starts the daemon program module. After the daemon program module is started, it starts the main program and monitors whether the main program starts normally. Specifically, the daemon program module determines whether it receives the initialization event feedback from the main program within a specified time by monitoring the proc_events file in the kernel space, and then determines whether the main program starts normally. When it is determined that the initialization event is received, the daemon program module determines that the main program starts normally; when it is determined that the initialization event is not received, the daemon program module determines that the main program fails to start. At this time, the error script is called to inform the outside world that the main program fails to start.

[0030] The reason for such an operation is that the daemon program module is used to assist the main program and monitor it. First, the daemon program module is started, and then the daemon program module starts the main program and monitors whether the main program starts successfully. Only in this way can a closed loop be achieved to ensure that the entire running process of the main program is under the monitoring of the daemon program module.

[0031] When the daemon program module determines that the main program starts normally, it monitors whether the main program is normal during the running process through a watchdog. The watchdog can determine whether the main program is normal during the running process according to whether the main program feeds the dog as required. The corresponding technology is well-known technology and will not be elaborated here. When the daemon program module determines that there is an abnormality in the running process of the main program, the daemon program module can call a custom script to shut down the real-time processing core, and at the same time, the main program can be restarted. The method of shutting down the real-time processing core is the same as above and will not be elaborated here. And when it is determined that the main program starts normally, the real-time processing core can be restarted.

[0032] As shown in the appendix Figure 3As shown, after the main program or daemon module calls the script to start the real-time processing core, the daemon module monitors uevent events in the kernel space and determines whether a real-time processing core startup event is detected within a scheduled time. If not, it determines that the startup of the real-time processing core fails, records it in the log file and exits. If so, it determines that the real-time processing core starts up normally. At this time, the daemon module uses inotify to monitor the Message log of the Linux system and determines whether there are changes in the Message log of the Linux system. Inotify is a subsystem (API) newly added in the Linux kernel version 2.6.13 (June 18, 2005). It provides a mechanism to monitor file system events, which can monitor changes in the file system such as file modification, addition, deletion, etc., and can notify corresponding events to applications.

[0033] When it is determined that there are changes in the Message log of the Linux system, read the content of the Message log of the Linux system and determine whether it contains an un-watchdog flag. The un-watchdog flag is generated by the Linux driver file used in conjunction with the daemon module in the Linux kernel using the sysfs system. If so, that is, if the un-watchdog flag exists in the Message log of the Linux system, it determines that there is an abnormality in the real-time processing core and calls a custom script to restart the real-time processing core. Otherwise, it continuously monitors the Message log of the Linux system and determines whether there are changes in the Message log of the Linux system.

[0034] This method effectively solves the problem that the real-time processing core is affected by the multi-core heterogeneous hardware architecture, resulting in the inability to have a built-in hardware watchdog and the inability to monitor the real-time processing core alone. And using inotify monitoring enables the CPU to do what it should do most of the time and only checks when the Message log of the Linux system changes. In this way, both the monitoring effect can be achieved and resources are not occupied.

[0035] At the same time, the daemon module also communicates with the hardware watchdog of the crane operation control system. The daemon module sends data packets to the hardware watchdog at a certain period. If the daemon module fails to send data packets on time, it may be that there are serious problems in the operation control system, such as system jamming, which causes the daemon module to fail to run normally or the daemon module may be abnormal. At this time, the hardware watchdog generates a restart signal to restart the crane operation control system.

[0036] Moreover, the daemon module determines the occupancy rate of each core and / or the CPU occupancy rate and / or the CPU load by periodically reading the / proc / stat file and stores them in the shared memory. Monitoring the above parameters is to monitor the current system load of the operating control system.

[0037] Meanwhile, the daemon module monitors the real-time performance of each core of the overhead crane operating control system and stores the monitored real-time performance data in the shared memory. The real-time performance of a core is the actual wake-up time when the core is woken up after sleeping for a specified time. The real-time performance monitoring can be achieved by creating a thread and binding it to different cores. The corresponding technology is well-known and will not be elaborated here.

[0038] The reason for monitoring the real-time performance of each core is that if the real-time performance of each core is very poor, the faster the speed, the greater the offset position after issuing commands. For example, when the real-time performance is excellent at 1 us, and the overhead crane is controlled to move at a speed of 5 m / s, the offset position can be basically ignored. However, when the real-time performance of the core becomes 100 us, the position offset can no longer be ignored. Moreover, during the control of the overhead crane, there will be multiple task switches in the middle, and each task switch will add an additional 100 us. The cumulative offset position will be even larger, seriously affecting the position accuracy of the overhead crane.

[0039] Therefore, the real-time performance data and occupancy rate data stored by the daemon module in the shared memory will be synchronized to the main program, and the main program can complete various dynamic adjustments based on the real-time performance data and occupancy rate data.

[0040] For example, after the main program obtains the real-time performance data of each core from the shared memory, it can adjust the running speed of the overhead crane according to the real-time performance data, so as to achieve safer, more intelligent, and more controllable control of the overhead crane.

[0041] Another example is that after the main program senses the system load of the operating control system, it can understand the current operating conditions of the operating control system, and can issue warnings, adjust control logic, and adjust the operation control of the overhead crane according to the current system load.

[0042] For example, if a large number of IO operations are a factor affecting the system load, the control logic can be adjusted. For instance, when an IO operation is required, first check the system load. If the load is very high, do not perform the IO operation immediately but carry out other operations instead, and wait until the system load drops to the normal state or a lower level before performing the IO operation. Another example is that when it is determined that the CPU occupancy rate reaches 99%, it indicates that an abnormality has occurred inside the control system. At this time, the main program needs to sense the corresponding situation and let the outside world sense it in a certain way, such as the LED flashing red, the screen displaying a high system load, and the speaker emitting an error alarm sound, so as to achieve early warning for processing. Moreover, when the load of the handling system is relatively high, the crane cannot be controlled to move at a high speed. For example, when the CPU occupancy rate reaches 80%, the main program controls the moving speed of the crane not to be higher than 3 m / s, etc.

[0043] There are still many implementation manners of the present invention. All technical solutions formed by means of equivalent transformation or equivalent substitution fall within the protection scope of the present invention.

Claims

1. The overhead crane operation control system, including a main program and a real-time processing core for overhead crane motion execution control, is characterized in that: It further includes a daemon module, The daemon module monitors whether there are any abnormalities during the operation of the main program after normal startup. When it detects that there are abnormalities during the operation of the main program, the daemon module shuts down the real-time processing core; and / or, the daemon module monitors whether there are any abnormalities during the operation of the real-time processing core after normal startup. When it detects that there are abnormalities during the operation of the real-time processing core, the daemon module restarts the real-time processing core.

2. The overhead crane operation control system according to claim 1, characterized in that: The main program and the daemon module use semaphores to achieve inter-process communication.

3. The overhead crane operation control system according to claim 2, characterized in that: When the semaphore used for communication between the main program and the daemon module does not perform a +1 operation within a specified time, the daemon module shuts down the real-time processing core.

4. The overhead crane operation control system according to claim 1, characterized in that: When the overhead crane operation control system starts, the systemd starts the daemon module. After the daemon module starts, it starts the main program and monitors whether the main program starts normally. When it determines that the main program starts normally, it monitors the operation of the main program through a watchdog.

5. The overhead crane operation control system according to claim 4, characterized in that: The daemon module determines whether the main program starts normally by monitoring the proc_events file in the kernel space to determine whether it receives the initialization event feedback from the main program within a specified time.

6. The overhead crane operation control system according to claim 1, wherein: After calling the script to start the real-time processing core, the daemon module monitors the uevent event in the kernel space and determines whether the real-time processing core startup event is detected within a scheduled time. If so, the daemon module uses inotify to monitor the Message log of the Linux system and determines whether there are changes in the Message log of the Linux system. When it determines that there are changes, the daemon module reads the content of the Message log of the Linux system and determines whether it contains the un-fed watchdog flag. If so, the daemon module calls a custom script to restart the real-time processing core.

7. The overhead crane operation control system according to claim 1, characterized in that: The daemon module sends data packets to the hardware watchdog of the overhead crane operation control system at a certain period. If the daemon module fails to send data packets on time, the hardware watchdog generates a restart signal to restart the overhead crane operation control system.

8. The overhead crane operation control system according to claim 1, wherein: The daemon module determines the occupancy rate of each core and / or the CPU occupancy rate and / or the CPU load by periodically reading the / proc / stat file and stores them in the shared memory.

9. The overhead crane operation control system according to any one of claims 1-8, characterized in that: The daemon module monitors the real-time performance of each core of the overhead crane operation control system and stores the monitored real-time performance data in the shared memory.

10. The overhead crane operation control system according to claim 9, characterized in that: The main program obtains the real-time performance data from the shared memory and adjusts the running speed of the overhead crane according to the real-time performance data.

Images