How to use preempt for seize blocks

Question

I am currently building a model on a manufacturing process line. The intention is to create a model with multiple machines and operators. An operator is seized at multiple points for performing various taskings. However, I require operators to follow a certain work schedule and go for breaks at staggered timings. As such, I have created the schedule within each agent to customise their break times.

The problem that I am faced with is I need the operator to suspend his/her current tasking whenever its time for break. Hence, I have been exploring the preempt feature within the seize block, but have failed to get what I require.

I'll illustrate an example below. Assuming that the operator is performing the current task of "receiveLot_V", while at this task, it is time for break. Upon break time, the schedule triggers to enter the flowchart to seize the current operator for break (I need to capture the duration where each operator is at break and at the same time not allow the operator at break to be available in the resource pool to be seized elsewhere).

I have allowed the seize block for break to have a higher task priority, however the operator just stays at the current position and does not seem to proceed with the process flow for break after he/she is being seized.

In addition, for certain taskings I am sending my operator to a particular node upon seizing to perform a tasking. While the operator is moving and the breaktime hits, I face an error as shown in the last image. root.pop_DirectOperators[0].enter refers to the process flow within the operator to be seized for break, and root.pop_Equipments[0].seizeDO.sendTo refers to the process where the operator is being sent to a particular node to perform his/her tasks.

How can I resolve this issue? Am I understanding the preempt feature wrongly? I've tried multiple combinations of settings with the preempt but none of them seems to work for my case.

Answer 1

It sounds like you're trying to use a separate process to represent the breaks, which is one (uncommon) alternative (see below). The error suggests you are sending the resource agent into that process instead of a dummy agent which represents the 'break request' (and which will then seize the appropriate resource agent to take its break).

The typical ways of modelling pre-empting breaks are:

• Set up breaks specified by the Resource Pool properties (ensuring they have a higher priority than that for agents which seize those resources). This works fine if your breaks have a fixed schedule of occurrence. Then have pre-emption occur in all Service/Seize blocks that you want to be affected by break pre-emption.

• As above but use a Downtime block to specify the pattern of breaks. Gives a bit more flexibility in how breaks are specified but still only within the limits of what a Downtime block can specify.

• For a completely 'custom' situation (where, for example, breaks might need to be determined dynamically for indivividual resource units in some way), use a separate process flow to 'cause' the breaks: inject agents representing the break request (so e.g., of custom type BreakRequest) into the process which seize the appropriate resource from the appropriate pool (where this injection could be driven from behaviour within the individual resource unit agents themselves), and model the ensuing break in whatever way is needed (e.g., just a plain Delay or something more complex that determines when their break will end). You need to ensure that the break request agent has a higher priority than other tasks (i.e., other agents flowing into other Service/Seize blocks) and is set to pre-empt.

The important things to understand are:

• You specify "Task may preempt" on the blocks where the tasks that will pre-empt others (if higher priority) occur (i.e., you specify this on the Service/Seize blocks of the 'pre-empters').

• You specify "Task preemption policy" on the blocks where the tasks that will be pre-empted occur (i.e., you specify this on the Service/Seize blocks for the 'pre-empted'). And then you have the specified options in terms of what to do with the task (agent) that has been 'kicked out'. If you specify "No preemption" then the pre-emption won't happen even if the 'source' task is set to pre-empt and has a higher priority.

• Priorities are 'global' (e.g., if you say in a special breaks process flow Seize block that the incoming agent has priority 100, then the seize request that it then sends to the relevant resource pool will be compared against the priorities of all other tasks those resource agents are doing or have been asked to do, which are determined from whatever Seize/Service block they arrived in originally).

Your screenshots suggest you haven't set up the pre-emption block options on the correct blocks (as well as possibly/probably sending the wrong agent into your special breaks flow); see info above.