Tasksequences: BREAK, CALLSUBTASKS, or PREEMPT?

Hi,

I would like an operator to do a long tasksequence (TS), and to be called away to do a different TS in certain cases (priority?). Before switching to the different TS, the operator should finish a part of the current TS. How could this be done?

Two options which are not satifying, are:

1)
The different TS is preempting (PREEMPT_ONLY), which causes the operator to switch to the different TS right away.

2)
The first, long TS has several TASKTYPE_BREAK tasks, at the places where the operator could interrupt the TS. The problem here is that the operator will break to a task which is in its TS queue, even if the long TS has an equal or higher priority.

Thanks!

Change the 'BreakTo Requirement' option on the operator to include a test for priority.

Example attached.

Hi All,

thanks Jason for your reply and example. That was very helpful. What I'd like to do is to interrupt a normal task sequence with a coordinated task sequence which should be preempting.
In my model this works only if I use PREEMPT_AND_ABORT_ACTIVE. In case PREEMPT_ONLY is used, the current task is not interrupted and the TE is just continuing with his orignila task sequence while the other operator which is necessary for the coordinated work is allocated and waiting.
I'm still very unsure about the PREEMPT and Priority stuff. Maybe someone can shed some light on this topic.

Thanks,
Stephan

A few tips might help:

1) If you're using a dispatcher, it will not decide to preempt tasks from its task executers. You'll need to return the port number of the connected TE (the one you want to preempt) in the dispatcher's Pass To to get it to work.

2) The prempt only takes place if the activetask has a lower priority value or the active task is PREEMPT_NOT. For coordinated task sequences you pass in the priority and preempt values to the insertallocatetask() function.

3) Bear in mind that preempting TEs that are travelling on networks has caused them to disconnect from the network and travel in undesirable straight lines to the next network node. For this reason I try and avoid preempting TEs with networks.

The User Manual has a section on Task Sequence Preempting providing further detail.

Attached is the same example model, but with the lower example using two coordinated operators, where one of them is acting as the dispatcher. It's a limited case example on the Operator's PassTo trigger where I just detect if the dispatching operator is already allocated when a second preempting Allocate task comes in.

Generally, if you're using a dispatcher object to dispatch, you'll need to either keep a more comprehensive track of which TEs have been allocated to coordinated tasks in order to pass them appropriately, or scan through them each time to see which are already allocated to the coordinated task sequence and which can be preempted away from their current tasks.

Thanks Jason. Your example was indeed helpful. I introduced network nodes to it and found that the second operator (the one not carrying an item) just stops at the last network node whereas the other operator goes all the way to the queue. I assume this has to do with travelling offset for unloading. I will try to compare your solution with my model tomorrow as i dont have it available right now and post my findings.

Good night,
Stephan

I checked everything on my model but wasn't able to fix the problem. This is what I'm trying to do:
TaskExecuter Flowitems (Customers) are created in a source and given a Task Sequence to travel to a certain network node (SecurityGate), break there and continue their travel to the sink. At the Security Gate network node some of the TEFlowitems will be given a coordinated, preempting task sequence which is to travel to another network node, wait for the Security Operator to arrive and wait together for some time. Once this has been finished the Security Operator is to return to his standby network node and the TEFlowitem continues its travel to the sink. Doesn't sound complicated but it just wont work. The Task Sequences are generated on the "Request Transport from" field in the Source and the OnMessage Trigger of the NNSecGate network node.
I would assume from Jasons earlier reply that this kind of task is not possible because the TE detach from the network and cannot travel to their destination. Therefore they skip the preempting task and continue with their older task. But to be honest: I'm pretty clueless about how to solve that problem.

All the best,
Stephan

I don't believe you can use a BREAK or CALLSUBTASK task to trigger the creation of a coordinated task sequence. In the OnMessage you would need to return a reference to (not dispatch) the task sequence you want the TE to continue, and a coordinated task sequence must be dispatched (not returned) using dispatchcoordinatedtasksequence() in order to work properly.

Usually, if I want to preempt a TE traveling on a network I use the network node's OnArrival to send a message to itself with a reference to the TE. In the OnMessage I then create the preempting TS. In the attached model I use this same approach to create a coordinated TS.

I assumed that the SecChecker operator in your model was not required to be in the standby position for the passengers to pass through the SecGate. You could simply add another node before the SecGate node, then connect the TrafficControl to control the passenger flow accordingly.