Multiple operators at different locations performing a single processor

[Paul Dowling]

Hi,

Im trying to get multiple operators to perform a process (at a processor) but not all stand at the same location and was hoping someone could help me out.

The approach i tried was using a traffic controller of the path to the first processing location and setting mutual exclusion to 1, to see if the second operator went to the second processing location (model attached). It succeeded in stopping any more operators entering that particular processing location, but they did not continue on to an alternative. I also tried a similar approach by closing edges in the on continue trigger of the "divert" node but had the same effect.

I suspect this is because operators by default travel by the shortest path (as documented), i would like to somehow change this to shortest AVAILABLE path.

Regards
Paul

[Jason Lightfoot]

Paul,

There's nothing to stop you creating the task sequences for the operators yourself, and then you can send each of them to different locations - which could be network nodes for example. The code here is not complete, and is taken from the callprocessoperators and calloperator functions - but if you need a fully working example, just let me know and I'll put one together.

#define OPERATOR_STOP_ID 100002

for (int index = 1; index <= nrofops; index++)stopobject(<processor>,STATE_WAITING_FOR_OPERATOR, OPERATOR_STOP_ID, priority);
treenode newts = createemptytasksequence(<dispatcher>, priority, preempt);
inserttask(newts, TASKTYPE_MILESTONE, NULL, NULL, 3);
inserttask(newts, TASKTYPE_TRAVEL, <travellocation[index]>, NULL);
inserttask(newts, TASKTYPE_STOPREQUESTFINISH, <processor>, NULL, 0, OPERATOR_STOP_ID);
inserttask(newts, TASKTYPE_UTILIZE, item, <processor>);
dispatchtasksequence(newts);
}I'm pretty sure you can put this on the process dispatcher trigger and return 0 instead of a valid dispatcher pointer.

The only problem is that the involved doesn't then get set on the flowitem so you may need to send a message (0 delay) to set it to the dispatcher by doing the equivalent of :

setnodenum(rank(itemtype(item),QUEUENODERANK_INVOL VED),tonum(dispatcher))
Suggestion: Perhaps there should be -1 return check to indicate that we've already done the operation within the processdispatcher trigger, to avoid the item's involved node being set to NULL.

[Jason Lightfoot]

Here it is in operation using the getnetnode function to determine where to send the operators, and with two processors so that they move from one to the other. The code is in the processdispatcher and messagetrigger nodes of each processor.

[Paul Dowling]

Thanks Jason. That works perfectly.

Wondering did you mean requestoperators instead of calloperators (can't seem to find either of the commands starting with call)?

Also, how does one view the contents of these commands (other than just using the command index)? That would allow you to create your own custom "versions" of functions (using usercommands or something) very quickly and easily...

[Jason Lightfoot]

The callprocessoperators is a method of the Processor class found within library tree. It uses calloperator in a similar way to requestoperators does, except that it records which dispatcher was used on the flowitem in order to release the operators when the job is done :- when you use requestoperators you need to code the freeoperators part yourself when the process is finished. Because you wanted the operators to go to specific nodes and yet do a TASKTYPE_STOP_REQUEST_FINISH on the processor once they arrive, you can't use requestoperators.

The calloperator command is one of the globalC++ commands found in the exec part of the tree (not all commands are listed there).

Note that we could have used freeoperators instead of recording the dispatcher on the item, I just did it that way so that it behaves more like a default processor. Ideally we would be able to do this in the same trigger and avoid sending the message - I'll put it on the development wish list.

Glad I could help.