question

A more advanced solution consists still of an operator. But now I use the data stored at the items to distribute them on the conveyor system. A conveyor is aware of all directly attached objects to it. These are decision points and transfer objects like entry transfer, exit transfer and transfers as interfaces between conveyors.

A senditem method of a conveyor class expects only a reference of an attached object to distribute conveyor items to it. So instead of analyzing where on item should be diverted later on a system, you can use a bit of data at an item that a taskexecuter uses to transport an item originally to. The destination is still available, when the taskexecuter put an item to a conveyor system in this case. The data is inside of an attribute node at the item called "itemtype". The destination is in itemtype inside an value called "transportInCompleteObject".

getsdtvalue(item.attrs.itemtype.subnodes[1],"transportInCompleteObject");

This command returns the destination of an item as a treenode. The node contains data in type of simple data type.

Each of your processors is connected by its first input port connection to an Exit Transfer of your conveyor system.

Object processor = getsdtvalue(item.attrs.itemtype.subnodes[1],"transportInCompleteObject");
treenode destination = processor.inObjects[1]; // Object at first input port of processor 
Conveyor.sendItem(item, destination);  

This code above sends each conveyor item to the right processor, which the operator would have done so. You can put this code into a decision point trigger or a photo eye object trigger. Important is only, that the code gets executed on a main branch of your conveyor system before any item diverts to a conveyor in front of a processor.

Because of the way items got onto the conveyor by an operator, there is still a requirement to prepare each processor to receive items from its connected exit transfer. First a "transport in" has to end by command:

transportincomplete(receiving object, item, input port, transporter object);

Then the processor must receive items again.

receiveitem(receiving object , input port number);

You can put this into a decision point trigger or the exit transfer Send to Port function. Following here you see a complete source code of this function Send to Port:

Object item = param(1);
Object current = ownerobject(c);
/**Custom Code - port 1*/
Object transporter = Model.find("Operator1");
transportincomplete(current.outObjects[1],item,2,transporter);
receiveitem(current.outObjects[1],1); // receiveitem at processor from input port 1
return 1 ; // ouput port of exit transfer

items_on_demand_of_processor_on_conveyors.fsm

This is a runtime problem. A processor must receive only one item. Then he processes this item and he receives next item. You need a different convey logic, which take into account exactly this behavior.

You can missuse the function "use transport" for such a behavior in a queue. An Operator loads an item that you want to get received by a processor. But on load event (trigger) you divert this item to be unloaded to an entrytransfer object at your conveyor system instead. A logic must be built in a matter that it manipulates an involved variable at your processor called "nroftransportsin". As long this variable is larger than 0 this processor rejects items to be transported in. When a processed item has left this processor, you call a command of transportincomplete to change this variable back to zero to accept next item to get transported into this processor.

A Taskexecuter (e.g. an operator) must be set as a stationary object to do this transport job. Place a network node into your model. Connect it to your queue, the entry transfer object and your taskexecuter. On load trigger (event) you change executed active tasksequence that travel task (task number 4) destination is your entry transfer- it is involved1 parameter. Further you change destination in task 5 (unload task) destination - involved2 parameter, too. You tell in properties of this taskexecuter, that he does not perform offset travel tasks for load and unload. He is then stationary, loads and unloads instantly any items he has to transport.

Now comes the difficult part: You need to divert items to your processors depending on items still in transit to your processors. You can set a label at each processor, when he is going to receive an item, because you send an item to it by an decision point on your conveyor system. Once this item has left the processor you reset this label.

Edit: There is another obstacle to overcome. Because a processor expects now to receive an item to be unloaded, you have to tell him, that he has to receive items again. You can the processor from which he has to receive items. You put this code into a decision point previous the processor.

receiveitem(Model.find("Processor3"),1);