Patent Application
20240382382
The invention relates to a method for step dispensing discrete medicaments from a dispensing system, and to a dispensing system for step dispensing discrete medicaments from feeder units. Furthermore, the invention relates to a method for controlling operation of a system, and to a system having one or more distinct modules. A method for step dispensing discrete medicaments from a dispensing system is known from WO 2014/171818, wherein the dispensing system accommodates a series of feeder units and is arranged for selectively dispensing an amount of the medicaments from one or more feeder units and for packing the dispensed amount, and wherein the system comprises: a dispensing device provided with an array of dispensing positions arranged adjacently in a plane, wherein the dispensing device at each of the array of dispensing positions is provided with a holder for one of the feeder units and with a through opening for passing discharged discrete medicaments there through; a collection frame arranged below the dispensing device, wherein the collection frame and the dispensing device are movable with respect to each other, wherein the collection frame is provided with a series of collection trays, each having an elongated shape with a longitudinal direction which extends substantially parallel to the plane and over a length of at least two of the through openings, wherein the trays comprise a receiving opening at a side facing the dispensing device for capturing the discharged discrete medicaments and each comprises an output; a packing unit arranged below the collection frame for collecting the captured discrete medicaments from the output of a tray and packing the solid medications; and a controller for controlling the working of the dispensing system and the feeder units arranged on the dispensing device. The controller is configured for controlling the dispensing system, such that it packs one or more discrete medicaments into a pouch at very high speed, wherein each pouch comprises a specific number and types of discrete medicaments and specific data associated with the patient for which the respective pouch is intended.
An important aspect of the known dispensing system relates to controlling the feeder units in order to dispense discrete medicaments therefrom, which may be understood as driving the feeder units so that one or more discrete medicaments are dispensed therefrom. For example, the known dispensing system may have over 1000 positions for holding feeder units and a large part of the more than 1000 positions, for example over 300 positions, may be used for dispensing discrete medicaments. At a rate of three or more pouches per second, the more than 300 positions need to be continuously controlled with data on the number of discrete medicaments to be dispensed, parameters to control the process of dispensing the discrete medicaments and a real-time trigger signal indicating that the dispensing action should start. A disadvantage of the described method is that receiving the real-time trigger signal too early can lead to dispensing errors, for example, in which one or more discrete medicaments may be packed in erroneous pouches. Receiving the real-time trigger signal too late can lead to a delay in the dispensing process.
In order to overcome these disadvantages, known dispensing systems control the feeder units entirely via a real-time bus, such as Ethercat™ or Varan™. A disadvantage of using a real-time bus for controlling the feeder units is that such a real-time bus is rather expensive. Furthermore, each feeder unit receiving control data via the real-time bus requires that each dispensing position on that real-time bus must have its own address on the real-time bus, which disadvantageously renders each dispensing position rather expensive. A further disadvantage of using a real-time bus for controlling the feeder units is that the amount of data that may be sent over such real-time bus is relatively limited.
It is an object of the present invention to ameliorate or to eliminate one or more disadvantages of the prior art, to provide an improved dispensing method or system or to at least provide an alternative dispensing method or system.
According to a first aspect, the invention provides a method for step dispensing discrete medicaments from a dispensing system accommodating one or more feeder units and arranged for selectively dispensing an amount of discrete medicaments from the one or more feeder units, the system comprising:
During use, the method allows the dispensing command, which for example states the number of discrete medicaments to dispense and parameters such as how to dispense the discrete medicaments, to be sent to one or more of the dispensing positions via a non-real-time bus, in particular before the one or more discrete medicaments have to be dispensed. The sent dispensing command is buffered at the respective dispensing position until the discrete medicaments have to be dispensed. When the one or more discrete medicaments actually have to be dispensed, the dispensing trigger is sent to the respective dispensing position of the array of dispensing positions via the real-time connection. The dispensing trigger is used for triggering the feeder unit placed at the respective dispensing position(s) to dispense the discrete medicament upon receiving the dispensing trigger. Since the dispensing command comprises data regarding the dispensing parameters, the dispensing command needs more bandwidth than the dispensing trigger. By sending the dispensing command to the respective dispensing position(s) via the non-real-time connection, before sending the dispensing trigger via the real-time connection, the dispensing command is provided to the dispensing positions in a much cheaper manner in comparison to a real-time connection. As only the dispensing trigger (which may be the same for all dispensing positions) is sent via the real-time connection, the real-time connection only needs to have sufficient bandwidth for sending the dispensing trigger. For example, the dispensing trigger only has to be a few bits wide, such that very little bandwidth is needed for triggering the feeder unit(s) at the dispensing position(s). This is advantageous as the real-time connection may be kept small, thereby keeping the costs associated with controlling dispensing by the feeder units low. This results in a cheaper method for step dispensing discrete medicaments in comparison to the prior art.
In the context of the present disclosure, non-real-time can be understood as a term used to indicate a process, event or action that is not guaranteed a response within a predefined timeframe. Most common general purpose computer systems like Windows™ are non-real-time. Real-time can be understood as a term to indicate a process, event or action of which input data is guaranteed to be processed within a specified time (deadline), usually a relative short time.
In an embodiment, the step of sending a dispensing command comprises sending a dispensing command in advance of the step of sending a dispensing trigger. In the context of the disclosure, sending a dispensing command in advance can be understood as that the dispensing command is sent at a time, such that the dispensing command has arrived before the dispensing trigger arrives. This is advantageous as this enables that dispensing of discrete medicaments may start immediately after receiving a dispensing trigger.
In an embodiment, the step of sending a dispensing command comprises sending multiple dispensing commands to the dispensing position of the array of dispensing positions. During operation, each of the dispensing commands is buffered at the respective dispensing position, such that a queue of dispensing commands is available at the respective dispensing position. It is thereby prevented that the step of dispensing is interrupted due to a missing dispensing command.
In an embodiment, the data of the dispensing command comprises information about the number of discrete medicaments to dispense, and/or parameters about how to dispense the number of discrete medicaments. Thus, the data may comprise all parameters needed for being able to dispense discrete medicaments, except for the trigger to start dispensing.
In an embodiment, the step of sending a dispensing command comprises the step of including a command cycle identifier into the dispensing command. In an embodiment thereof, for each time the step of sending a dispensing command is performed, the step of including a command cycle identifier comprises adjusting the command cycle identifier. In an even further embodiment, the step of sending a dispensing trigger comprises the step of sending a trigger cycle identifier along with the dispensing trigger. Preferably, for each time the step of sending a dispensing trigger is performed, the step of including a trigger cycle identifier comprises adjusting the trigger cycle identifier. Even more preferably the command cycle identifier and the trigger cycle identifier are substantially identical to each other. According to this embodiment, each dispensing command is provided with a unique command cycle identifier and each dispensing trigger is provided with a unique trigger cycle identifier, wherein the unique command cycle identifier and the unique trigger cycle identifier are substantially identical to each other. Therefore, the command cycle identifier and the trigger cycle identifier may be used for determining which dispensing command needs be executed when a dispensing trigger is received at a dispensing position. This helps to prevent a wrong dispensing command being executed upon receiving a dispensing trigger at a dispensing position.
Furthermore, when the command cycle identifier and the trigger cycle identifier are adjusted in an ascending or descending manner, they also may be used for indicating the position of the respective dispensing command in an order of multiple dispensing commands.
In an embodiment, the method comprises, at the dispensing position of the array of dispensing positions, checking whether a corresponding dispensing command is received at the dispensing position upon receipt of the dispensing trigger. Checking whether a dispensing command is received can comprise the steps of:
Preferably, the method comprises the step of:
In an embodiment, reporting of an error situation is done via the non-real-time connection and/or via the real-time connection.
In an embodiment, the method comprises, upon report of an error situation, querying one or more dispensing positions of the array of dispensing positions in order to receive information about the error situation. In an embodiment thereof, querying the one or more dispensing positions of the array of dispensing positions is performed via the non-real-time connection. By querying information about the error situation via the non-real-time connection, large pieces of data, such as dispensing parameters and information about an error situation are transferred via the non-real-time connection. This is advantageous, as it allows the bandwidth of the real-time connection to be as small as possible, thereby keeping the costs for the real-time connection to a minimum.
In an embodiment, the method comprises, upon report of an error situation, pausing the dispensing system. In an embodiment thereof, the method comprises, upon pausing the dispensing system, sending a command to each dispensing position of the array of dispensing positions to remove one or more buffered dispensing commands, wherein the command is sent via the non-real-time connection. According to this embodiment, the dispensing commands which are not yet executed are resent to the dispensing positions or the clusters of dispensing positions. This can prevent that dispensing commands are skipped or are executed more than once, and the dispensing may be continued in a reliable manner.
In an embodiment, a dispensing position of the array of dispensing positions comprises one dispensing position or an array of dispensing positions. This allows the method according to this embodiment to control one dispensing position or multiple dispensing positions (segment control) with a single dispensing command.
According to a second aspect, the invention provides a dispensing system for step dispensing discrete medicaments from feeder units, wherein the dispensing system accommodates one or more feeder units and is arranged for selectively dispensing an amount of discrete medicaments from the one or more feeder units, the system comprising:
In an embodiment, the non-real-time connection is selected from a group comprising an Ethernet connection and a non-real-time bus, and/or wherein the real-time connection is selected from a group comprising a real-time bus, Ethercat™, Varan™ and hardware I/O lines.
According to a third aspect, the invention provides a method for controlling operation of a system, wherein the system comprises one or more distinct modules, wherein the method comprises the steps of:
In the prior art, a system with one or more distinct modules, such as a dispensing system for step dispensing discrete medicaments, is provided with a real-time controller, such as a Programmable Logic Controller (PLC) for controlling operation of the system. Such a PLC is very suitable for reading and controlling sensors and actuators in complex systems. For example, the PLC is enabled to precisely control specific motors, such as position motors, with the PLC having very accurate timing such that mechanical steps can be matched precisely. Complex systems, such as the dispensing system, further require a controller, in particular a non-real-time controller, that uses complex algorithms to determine which tasks have to be executed, for example, for dispensing the correct amount of discrete medicaments. For example, the dispensing system comprises various mechanical modules, which sometimes have to execute a particular task and sometimes have to idle. The non-real-time controller is used for controlling the PLC. When the dispensing system has a very high operating speed, e.g. a very high dispensing speed, controlling the PLC by the non-real-time controller quickly leads to delays, since the PLC has to wait for commands from the non-real-time controller.
In the method according to the third aspect of the invention, control of the real-time controller takes place asynchronously. Asynchronous control of the real-time controller allows the non-real-time controller to send task parameter commands to one or more distinct modules and task trigger commands to the real-time controller, without the need for waiting for a feedback, such as a confirmation, from the one or more distinct modules and/or from the real-time controller. Therefore, after sending a task parameter command or a task trigger command, the non-real-time controller, may quickly send a following task parameter command or task trigger command. As a result thereof, the real-time controller queues a number of task trigger commands to be executed and, therefore, is always provided with a next task trigger command to be executed. Therefore, the non-real-time controller has to be fast enough to send enough task parameter commands and task trigger commands on average, but not exactly on time each time. This can be understood to mean that a delay at the side of the non-real-time controller does not result in a delay at the side of the real-time controller. This is advantageous, as the method enables the system to operate at a high speed, while the risk of a delay in operation is reduced or eliminated.
In an embodiment, the step of determining the execution plan comprises determining an order in which the tasks need to be executed, and including the tasks to be executed in the execution plan in the determined order. In an embodiment thereof, the real-time controller executes the queued task trigger commands in the order in which the task trigger commands are received and queued at the real-time controller. By providing the task trigger commands in the order in which they have to be executed to the real-time controller, the real-time controller may simply queue and execute the task trigger commands in the order in which they are received.
In an embodiment, the step of executing the queued task trigger commands comprises executing the queued task trigger commands one-by-one.
In an embodiment, each of the task parameter commands and the task trigger commands sent in relation to the tasks of the execution plan is provided with a synchronization identifier. In an embodiment thereof, the method comprises, at the real-time controller, the step of aligning the one or more tasks executed by and/or to be executed by the one or more distinct modules by use of the synchronization identifiers. In the context of the present disclosure, it has to be understood that during operation of the system the task of one distinct module sometimes has to wait until another task of another distinct module is completed. By providing the synchronization identifiers, it is made clear to the real-time controller which tasks have to be aligned with each other. Additionally, by aligning the one or more tasks by means of the synchronization identifiers, a task can be started as soon as a previous task is nearly or fully completed. Thus, the operating speed of the system is kept as high as possible.
In a further embodiment, the step of aligning the one or more tasks comprises, at the real-time controller, after triggering a module to execute a task by executing the associated task trigger command at the real-time controller, checking whether the following task depends on the task currently being executed. In an embodiment thereof, the method comprises, at the real-time controller, awaiting a confirmation from the module executing the current task in which it is confirmed that the task is completed before executing the following task, when it is determined that the following task depends on the task currently being executed. According to this embodiment, it advantageously is prevented that the following task is triggered and/or executed before the current task, on which the following task depends, is nearly or fully completed.
In an embodiment, the method comprises, at each of the one or more distinct modules, sending a response message from the module to the non-real-time controller indicating that the task is completed by the module, when a task is completed by the module. In an embodiment thereof, the method comprises reporting an error state of the module from the module to the non-real-time controller, when executing a task at the particular module fails and/or cannot be completed, wherein an error handling mode is triggered by the non-real-time controller upon report of the error state. By reporting an error state and triggering an error handling mode when it is determined that a module is not capable of completing the task sent to it, it is prevented that the system keeps operating and outputs an erroneous product, such as a pouch with incorrect discrete medicaments. According to this embodiment, the error will be solved before the system continues with normal operation.
In a further embodiment thereof, the error handling mode comprises the steps of:
According to a fourth aspect, the invention provides a system having one or more distinct modules, a non-real-time controller and a real-time controller,
The system according to the fourth aspect of the invention has at least the same technical advantages as described in relation to the method according to the third aspect of the invention.
In an embodiment, the real-time controller is selected from a group comprising a Programmable Logic Controller (PLC) and a Remote Telemetry Unit (RTU).
In an embodiment, the non-real-time controller is operatively connected to each of the one or more distinct modules and the real-time controller via a non-real-time connection, such as an Ethernet connection, and wherein the real-time controller is operatively connected to each of the one or more distinct modules via a real-time connection, such as EtherCAt and/or hardware I/O lines.
The various aspects and features described and shown in the specification can be applied, individually, wherever possible. These individual aspects, in particular the aspects and features described in the attached dependent claims, can be made subject of divisional patent applications.
The invention will be elucidated on the basis of an exemplary embodiment shown in the attached drawings, in which:
A schematic cross-section of a dispensing system 1 that accommodates a number of feeder units 2 for selectively dispensing an amount of medicaments, pharmaceuticals or solid items, articles or substances for medical use, e.g. pills, tablets, capsules or the like, from one or more feeder units 2 and for packing the dispensed amount of medicaments, is shown in
The dispensing system 1 comprises a dispensing device 3 configured for dispensing the medicaments. A collection device 4 is arranged below the dispensing device 3, which collection device 4 is configured for collecting the dispensed medicaments from the dispensing device 3. A packing unit 5 is arranged below the collection device 4, which packing unit 5 is configured for packing the collected medicaments. Optionally, the dispensing system 1 is provided with a (not shown) housing for shielding the dispensing device 3, the collection device 4 and the packing unit 5 from unauthorized access.
The dispensing device 3 is provided with an array of dispensing positions 20 with a (not shown) holder for holding a plurality of feeder units 2, also known as canisters or tablet cases. The dispensing positions 20 are distributed circumferentially about a rotation axis R. In particular, as best shown in
As further shown in
As shown in
The collection trays 40 are arranged in a collection frame 41 and are distributed circumferentially around the rotation axis R. The collection frame 41 is rotatable in a collection direction A about the rotation axis R in order to rotate the collection trays 40 with respect to the plurality of dispensing positions 20. For example, the rotation may be a stepped rotation such that each step of a tray aligns the collection tray 40 with a subsequent series of feeder units 2 arranged within the dispensing device 3.
The non-shown valve of a respective one of the plurality of trays 40 is opened when the respective one of the plurality of trays 40 is located above the packing unit in order to release collected medicaments from the respective one of the plurality of trays 40 into the packing unit 5. The packing unit 5 comprises a stock member for holding the packaging material, in this example a foil, a printer for printing information about the medicaments on the foil, a filling member for positioning the foil to receive the medicaments, a seal member for forming a pouch around the received medicaments, a perforation member for providing the foil with perforations between subsequently formed pouches and an output member for outputting the packaged medicaments from the dispensing system 1.
The dispensing system 1 further comprises a controlling unit 30 for controlling operation of the dispensing system 1. In particular, the controlling unit 30 is provided with a non-real-time controller 31 that is operatively connected to the feeder units 2, the dispensing device 3, the collection device 4, the packing unit 5, the robotic manipulator 6, and other electronic equipment, such as drives, sensors and the like, via a non-real-time connection, such as a non-real-time bus, for example an Ethernet connection, and with a real-time controller 32 that is also operatively connected to the feeder units 2, the dispensing device 3, the collection device 4, the packing unit 5, the robotic manipulator 6, and other electronic equipment, such as drives, sensors and the like, via a real-time connection, such as a real-time bus, for example a hardware I/O line. Each of the non-real-time controller 31 and the real-time controller 32 may comprise a processor and a non-transitory computer-readable medium having computer instructions saved thereon that, when executed by the processor, cause the dispensing system 1 to perform the methods described in more detail below. Alternatively, the controlling unit 30 comprises a processor and a non-transitory computer-readable medium having computer instructions saved thereon that, when executed by the processor, cause the dispensing system 1 to perform the methods described in more detail below, wherein the non-real-time controller 31 and the real-time controller 32 are software-based and/or part of a software program. This may be understood as that the non-real-time controller 31 and the real-time controller 32 define a non-real-time environment and a real-time environment, respectively.
In the context of the present disclosure, it is noted that each of the feeder units 2 may be provided with its own active modules, such as a driving motor, among others for driving dispensing of the respective feeder unit 2, in which case the respective feeder unit 2 is operatively connected to the controlling unit 30 via interface connections of the feeder unit 2 and of the dispensing position at which the feeder unit 2 is located. In this case, the feeder units 2 are directly operatively connected to the controlling unit 30, in particular the non-real-time controller and the real-time controller. Alternatively, each of the feeder units 2 may not have its own active modules, in which case the active modules, such as an external driving motor, are provided at each of the dispensing positions for driving dispensing by the feeder units 2. In this case, the external driving motor of each dispensing position is operatively connected to the controlling unit 30, in particular the non-real-time controller and the real-time controller, and the feeder units 2 are indirectly operatively connected to the controlling unit 30, in particular the non-real-time controller and the real-time controller. Herein below, when it is described that data, a message, a trigger or the like is sent to a dispensing system, this can be understood as the data, message, trigger or the like is being sent to the active modules at a respective dispensing position or to the active modules within a respective feeder unit 2.
Upon receipt of the dispensing command at the respective dispensing position 20 or the respective cluster of dispensing positions 20, the dispensing command is buffered at the respective dispensing position 20 or the respective cluster of dispensing positions 20, step S3. By buffering the dispensing command at the respective dispensing position 20 or the respective cluster of dispensing positions 20, the dispensing command may be sent in advance to the respective dispensing position 20 or the respective cluster of dispensing positions 20, such that the dispensing command is available at the respective dispensing position 20 or the respective cluster of dispensing positions 20 when required. It does not matter how much in advance the dispensing command is sent. It is noted that a number of dispensing commands may be buffered at the respective dispensing position 20 or the respective cluster of dispensing positions 20, since each dispensing command includes a command cycle identifier, in particular a unique command cycle identifier.
Subsequently, it is determined whether the dispensing command needs to be executed, in step S4. Determining whether the dispensing commands or one of the dispensing commands needs to be executed may be understood as receiving an indication that particular discrete medicaments need to be dispensed, for example because a specific collection tray 40 is located at or near the dispensing position 20 at which the dispensing command is buffered.
When it is determined that the dispensing command or one of the dispensing commands needs to be executed, in step S5, a dispensing trigger is sent from the real-time controller to the respective dispensing position 20 or the respective cluster of dispensing positions 20, wherein the dispensing trigger is sent via the real-time connection. The dispensing trigger is configured for triggering the feeder unit(s) at the respective dispensing position 20 or at the cluster of respective dispensing positions 20 to start dispensing discrete medicaments therefrom. The dispensing trigger is provided with a trigger cycle identifier, which trigger cycle identifier is used for identifying an associated dispensing command on a basis of the command cycle identifier thereof, wherein each of the trigger cycle identifier and the command cycle identifier indicates the cycle of the particular dispensing trigger and dispensing command, respectively, to indicate an order in which the dispensing commands have to be processed.
Upon receipt of the dispensing trigger at the respective dispensing position 20 or at the respective cluster of dispensing positions 20, in step S6, the dispensing trigger activates looking for whether a corresponding dispensing command is buffered at the respective dispensing position 20 or at the respective cluster of dispensing positions 20. This is done by looking for a dispensing command of which the command cycle identifier is substantially identical to the trigger cycle identifier, thereby indicating the dispensing command that needs to be executed.
When it is determined that a corresponding dispensing command is buffered at the respective dispensing position 20 or at the respective cluster of dispensing positions 20, in step S7, the feeder unit 2 or the feeder units 2 at the respective dispensing position 20 or at the respective cluster of dispensing positions 20 start dispensing the discrete medicaments as indicated in the corresponding dispensing command.
When it is determined that a corresponding dispensing command is not buffered at the respective dispensing position 20 or at the respective cluster of dispensing positions 20 and, optionally, when it is determined that a subsequent dispensing command is already available, in step S8, the respective dispensing position 20 or the respective cluster of dispensing positions 20 return(s) an error signal, in particular to the non-real-time controller, indicating that the particular dispensing command is missing. Subsequently, the non-real-time controller queries the respective dispensing position 20 or the respective cluster of dispensing positions 20, step S9, in order to find out which error has occurred. Thereafter, or simultaneously, the dispensing system 1 is stopped or paused, step S10.
When the dispensing system is stopped or paused, the non-real-time controller instructs the dispensing positions 20 to remove the already received and buffered dispensing commands, step S11, whereafter new dispensing commands may be sent to the dispensing positions 20.
The system 100 further is provided with a non-real-time controller 102 and a real-time controller 103, such as a Programmable Logic Controller (PLC). The non-real-time controller 102 is operatively connected to each of the modules 101 of the system 100 and to the real-time controller 103, wherein the real-time controller 103 is also operatively connected to each of the modules 101 and to the non-real-time controller 102. As indicated in
Upon receiving one or more orders that need to be fulfilled, the non-real-time controller 102, in step S101, determines an execution plan defining tasks that need to be executed by the modules 101 of the system 100 in order to be able to fulfill the received one or more orders. Optionally, the non-real-time controller 102 also determines the order in which the tasks need to be executed and includes the tasks in the right order in the execution plan. When the execution plan has been determined, in step S102, the non-real-time controller 102, for each task in the execution plan while sticking to the order of the tasks in the execution plan, sends a task parameter command to the module 101 that needs to execute the respective task. The task parameter command comprises parameters needed to execute the respective task, but does not trigger the respective module 101 to execute the task. Additionally, the task parameter command includes a synchronization identifier for aligning the tasks of the different modules 101 of the system 100.
After sending the task parameter command for a respective task, the non-real-time controller 102 sends a task trigger command to the real-time controller 103, step S103. The task trigger command indicates that the real-time controller 103 may trigger the respective module 101 to execute the task with which the task trigger command is associated, and which module 101 to trigger. The task trigger command is also provided with the same synchronization identifier as the corresponding task parameter command in order to align the tasks of the different modules 101 of the system 100.
The non-real-time controller 102 is continuously sending task parameter commands and task trigger commands, while sticking to the order of the tasks in the execution plan, as a result of which multiple task trigger commands are received at the real-time controller 103. Upon receiving the task trigger command(s) at the real-time controller 103, the task trigger command(s) is (are) queued, also called buffered, at the real-time controller, step S104.
The real-time controller 103 executes the task trigger commands in the order in which they are received at the real-time controller 103. When the real-time controller 103 executes one of the task trigger commands, the real-time controller 103 sends a trigger to the module 101 indicated in the task trigger command in order to trigger the respective module 101 to execute the task as indicated in the corresponding received task parameter command, step S105. When the task trigger command has been sent to the respective module 101, it is determined whether there are further task trigger commands queued at the real-time controller 103, step 106. If no further task trigger commands are queued at the real-time controller 103, the method is ended.
When it is determined that at least one further task trigger command is queued at the real-time controller 103, in step 107, it is determined whether the following task associated with the following task trigger command in the queued task trigger commands depends on the current task as indicated by the current task trigger command. If depending, the following task may only be triggered when the current task is completed. This is determined by means of the synchronization identifiers included in the task parameter commands and the task trigger commands. When it is determined that the following task is independent from the current task, the following task is executed as indicated in
If it is determined that the following task depends on the current task, such that the current task has to be nearly or fully completed before the following task may be executed, the real-time controller 103 checks during a predetermined time period whether or not the module 101 that had to execute the task sends feedback that the task associated with the current task trigger command, which is the task trigger command that has been executed last, has been executed, step 108. If the real-time controller 103 receives feedback that the task has been nearly or fully completed, the real-time controller 103 continues with executing the following task trigger command.
Additionally, and optionally simultaneously, in step S108, when a task has been executed by the particular module 101, the particular module 101 sends a response message indicating completion of the executed task to the non-real-time controller 102. When executing a task at the particular module 101 fails and/or cannot be completed, the task ends in an error state and this error state is reported to the non-real-time controller 102 directly.
When the error state is reported to the non-real-time controller 102, the method switches to an error handling mode, step S109, which is schematically shown in
If it is determined that the error may not be corrected automatically, the error is reported to an operator of the system 100, step 112, such that the operator may perform manual actions, step S113, in order to correct the error. After the manual actions of the operator, it is determined whether the one or more orders may be completed without errors, step S114. If not, the error handling mode interrupts processing of the one or more orders, step S115. If the one or more orders may be completed without errors, the error handling mode continues to step S111, whereafter the method is continued at step S102 with a re-determined execution plan.
It is to be understood that the above description is included to illustrate the operation of embodiments and is not meant to limit the scope of the invention. From the above discussion, many variations will be apparent to one skilled in the art that would yet be encompassed by the scope of the present invention.
| Number | Date | Country | Kind |
|---|---|---|---|
| 2028895 | Jul 2021 | NL | national |
| Filing Document | Filing Date | Country | Kind |
|---|---|---|---|
| PCT/EP2022/071447 | 7/29/2022 | WO |
