You need to know the network node nearest to the bay of the item to unload. If you depend on the logic of the rack place in bay, then it is getting tricky, because where should the taskexecuter travel to? He has to go to a network node at the rack which is connected nearest on his path. This is NN2. Then he gets the place offset data by the rack.
You can try to imitate the procedure of entering item a rack by calling the node functions Place in Bay and Place in Level. Then you would evaluate the Bay and the Level data that the taskexecuter travels to the networknode nearest to the rack bay, then the tasksequence of transport would continue the original sequence. But you must transfer the already evaluated data of bay and level into the functions of Place in Bay and Place in Level.
There are alternatives.
- You places a rack with a single bay at each networknode.
- You don’t depend on the Place in Bay and Place in Level logic of the rack. Your own logic tells you where the item level and bay will be. You put the data at labels on your item. You evaluate the data in the functions Place in Bay and Place in Level. You dispatch a tasksequence that lets travel the taskexecuter to the nearest network node, then the item gets unloaded to the rack.
- You allow offset travel, but there are only two network nodes at the rack: before the first bay and behind the last bay. Both are connected by the connection type “d”. This type connects two different networks. The taskexecuter begins his offset travel at the last node of the network1 and continues his travel on the first node of network2, if the taskexecuter has to reach other nodes in network 2. Both nodes are connected with the rack.