<< Click to Display Table of Contents >> Navigation: »No topics above this level« Commands "Blocked" and "Starved" |
mapp Services V5.16
This section explains what happens in the machine if:
•A module no longer receives products from another module ("Starved")
•A module can no longer forward products to the next module ("Blocked")
If one of these cases occurs, the production must be interrupted at the machine line so that the machine operator can solve the problem and restart the production process.
The machine line or the modules must be in state "Execute". Otherwise, there is no reaction to command "Blocked" or "Starved".
Defining process variables
In order to use function Blocked or Starved, process variables must be specified in the MpPackMLCore configuration under "Blocked module" and "Starving module". The process variables are of data type MpPackMLModulePVType.
These process variables contain the information about which module has triggered a "Starved" or "Blocked" command.
Triggering a "Starved" or "Blocked" command
Each module in the hierarchy has the possibility to trigger a "Starved" or "Blocked" command. The command is triggered via function block MpPackMLModule. Input parameter "Command" is used for this. Depending on the situation, command "Starved" or "Blocked" can be started. If one of the two commands was set to TRUE, the information is automatically forwarded to the main module. The process variables ("Blocked module", "Starved module") specified in the MpPackMLCore configuration can be used to find out which module started the command.
Main module starts command "Suspend"
As soon as the main module receives command "Starved" or "Blocked" from a module, it starts command "Suspend". Command "Suspend" is forwarded to all underlying modules. The command is forwarded as explained in section Communication between the modules.
If value "Overwrite.AllOtherCommands" was set to FALSE in the parameter structure of function block MpPackMLModule, command "Suspend" is not applied. This prevents the affected module from entering state "Suspending". It is important to ensure that no damage is caused to the machine through continued operation of the module. The underlying modules also do not contain command "Suspend". For additional information, see section Communication in asynchronous state.
The modules underneath now enter state "Suspending". The module is usually stopped in this state. It is ensured that the production is stopped so that the machine operator can find the cause of command "Starved" or "Blocked".
Resetting command "Starved" or "Blocked"
After the desired action of state "Suspending" has been executed, e.g. stopping a conveyor belt, command StateComplete can be started in the individual modules. The modules now enter state "Suspended". Command "Starved" or "Blocked" has been successfully executed since the machine has been stopped and the reason for the stop can be solved. If the error has been corrected on the machine, command "Starved"or "Blocked" can be set to FALSE. The machine is now ready to be returned to state "Execute".
Returning the machine to state "Execute"
The main module automatically triggers command "Unsuspend" as soon as command "Starved" or "Blocked" is set to FALSE. The individual modules then go into state "Unsuspending". The command is forwarded using the method explained in section Communication between the modules. In state "Unsuspending", preparations can be made in the modules to restart production. Recipes can be loaded or conveyor belts started, for example. As soon as the preparation of an individual module has been completed, command StateComplete can be triggered in the respective modules. When all affected modules have issued command StateComplete, the machine is again in state "Execute". Command "Starved" or "Blocked" was executed successfully.
If command "Starved" or "Blocked" is retained and the machine is in state "Execute" again, command "Suspend" is automatically started again by the main module.
It is important to note the following:
•If multiple modules trigger command "Blocked" or "Starved", the signal that was triggered in the task with the highest priority wins. If the respective module contains modules that are still below it, the module that is at the bottom of the hierarchy is displayed.
•The first "Blocked" or "Starved" command that occurs writes the module information in the process variable ("Blocked module"/"Starving module") specified in the MpPackMLCore configuration. If additional "Blocked" or "Starved" commands occur, the information on the process variables will not be updated. The information on the respective process variables can only be updated if the machine unit changes back to state "Execute" and command "Blocked" or "Starved" is triggered.
•If command "Blocked" or "Starved" is reset to MpPackMLModule, the information on the process variable specified in the MpPackMLCore configuration is reset to its default values on "Blocked module"/"Starving module".
•If a module should not enter state "Blocked" or "Starved", parameter "AllOtherCommands" can be set to FALSE via the parameter structure of the module. For additional information, see here.
In this example, two machines exist in a machine line. A hierarchy was set up for each machine. The next section explains how to use command "Blocked" or "Starved" in this case.
The machine line is divided into two machine units: "Unit 1" and "Unit 2".
Both machine units each have an input module and an output module.
If the output module of "Unit 1" no longer forwards any products to the input module of "Unit 2", command "Blocked" is triggered at the output module in "Unit 1" and command "Starved" is triggered at the input module in "Unit 2". Both machine units must interrupt production so that the operator can solve the problem and restart the production process. This means that the machine line must change to state "Suspend".
Information about which module has triggered command "Starved" or "Blocked" is displayed via "Starving module" or "Blocked module" in the respective MpPackMLCore configuration. A process variable of data type MpPackMLModulePVType must be created and specified on "Starving module" or "Blocked module".
Fig.: Example for machine unit "Unit 1"
Command "Starved" and "Blocked" is executed via function block MpPackMLModule. This means that the output module in "Unit 1" starts command "Blocked" and the input module of "Unit 2" starts command "Starved".
The commands are forwarded to the respective main modules, which changes the machine unit to state "Suspend".
Command "Suspend" is automatically sent to the main module as soon as command "Blocked" or "Starved" has been started.
Once changed to state "Suspending", the main module sends command to all subordinate modules. Command "Suspend" is forwarded in the same way as described in section Communication between the modules.
As soon as the machine units change to state "Suspended", the machine line was successfully stopped.
The machine operator can then find the cause of the problem and correct it. The machine line can then be changed back to state "Execute".