question

You are creating a number of task sequences for the picks in series and then the unloads in series. You could instead create them as complete pick and unload tasksequences each with a BREAK task in the middle to allow the transporter to evaluate if it can start another new task sequence. There are disadvantages of this and you may be better creating a single task sequence for each rack containing multiple picks - see comments below.

The Break task type which allows the task executer to check its spare capacity and start another task sequence in the middle of the current one and is added by a custom task activity and selecting the task type - in this case 'break'

If you dont' want the forklift to drive into the rack and load it, another task type you can use with the custom task activity is the pickoffset type of travel which will make the task executer travel to collect the item using only selected component(s) of the offset - so in this case just travel the x component along the face of the rack.

This means your process flow can be simplified to this:

The pick offset settings would be:

There are no setting for the BREAK tasks, but you should set the transporter to break to new task sequences only.

You can run all the tasks sequences at the same time with these settings on the run-subflow.

Then you can set the flip threshold on the transporter to 170.

With these changes your transporter will enter then aisle, travel to each item and load it, travelling backward up the aisle to an item in an earlier bay. This is probably not what you want/need.

To fix that you should create a task sequence that visits the racks in the correct order based on route and picks from each rack in bay order. This means you should sort the items in the array in descending bay order in the case of this rack.

Also, you don't need to tell the TE to travel to network nodes but to the rack. The rack will be enough since the one way settings will tell it it needs to go to the first network node that is attached. Switch the TE to not travel offsets for load/unload tasks which will still allow it to travel the PICKOFFSET in the X direction and not perform its own movement when you give it the Load task.

Also I would like to point out that while you're using task sequences, you don't need to acquire and release the task executer since the task sequences themselves take control of the task executer - you just need a pointer to the te or dispatcher. You could issue multiple orders at once and have the tasksequences all queued and being broken to by the task executer's BreakTo Requirement. However, if you're using individual tasks activities outside of a sequence, then they will each compete when issued in parallel, and so acquire/release and issuing them in the correct order (not in parallel) is then needed.

A simple model that demonstrates this is shown in this process flow:

Using a batch activity, which then releases all 10 tokens, will allow you to collect 10 items then release them to be dropped off. The resource of 10 items being allowed prevents the transport content from overfilling.

Here is the model layout. Since AnswerHub is still not allowing uploads, I will email you this simple model I used.