strange behavior of ts prioity?

Hi, I attached a model. In which, why the robot could not unload all items to the processor?

if I turn off the priority in the queue2, it will be normal.

My english is so bad. and I cannot express it clearly.
but if you look into the model, you will know.
thanks

Another model, Even more strange.

The transporter should carry items from the queue2 to the rack. But why it carry one from the rack to the queue?

I doesn't do any programmimg.

Any idea?
thanks

Hi,

the problem is the max wait time in the field perform batching.
It build an new set of tasksequences for the batch that already have their tasksequences. An easy solution I haven't find so far, besides destroying the double tasksequences or something other dramatical.

Maybe some of the more experienced user could help?

Jörg

Below is an explanation for model 4.zip

Because the robot has a capacity greater than 1, the Break To Requirement will split task sequences according to the logic specified. In your case you chose “Same Itemtype”, so the robot will take only NEW task sequences that involve the same itemtype. When a task sequence is split, the remainder is added to the top of the robot’s task sequence queue (inbox). After loading the 4th item, the Break To Requirement will not be executed because the robot has reached its capacity. The robot will then finish the task sequence for the last (4th) item FIRST. Upon unloading the 4th item, the robot will check its inbox for another task sequence to work on. At this point the remainder of the TS for the 3rd item is on top, however because the robot just finished a TS, its Queue Strategy will be fired which will ultimately choose the next TS. The default rule is to sort by the TS priority, and because you have given the queue a higher priority than the rack, task sequences to fill the rack will be chosen from the inbox instead of completing the remainder TSs. Once the rack is full again, the only TSs available to choose will be the remainder TSs for the 3rd, 2nd and 1st items loaded from the rack.

As you found, when the rack is given the same or greater priority than the queue, the robot behaves as you would like. If for some reason you would like to keep the queue with a higher priority than the rack, you could set the robot’s Queue Strategy to the “No Queue Strategy - Straight FIFO” option. However, note that this simply ignores priority and allows the robot to choose the TS at the top of its inbox. As a third option, you could modify the QueueStrategy “Sort by TaskSequence Priority” option such that it incorporates the current task value on the TS. For instance, a remainder TS (of a default TS) will have a curtask of 4, while a new TS will have a curtask of 1.

Example:
return (getcurtask(tasksequence)>1)*100 + getpriority(tasksequence);
or
return getcurtask(tasksequence) * (getpriority(tasksequence)+1);

The highest return value will be chosen.

Thank you, kris.
Your solution is excellcent.

And I also figured out a solution. In order to tell the robot to choose uncompleted broken TSs, I set the TSs' priority to 10 in the onload trigger. It does work.


By the way, if I want a TE to return to only it's original uncompleted broken TSs when the breakto ts is finished, is there a standard way to do this? Or, is Kris's solution is the best?

thanks

Just as Jörg said, in model a.zip, when Max Wait Time of the queue
reached, it will create additional TSs not considering that it had created them before. It's very strange.

Now, I test another simple model b.zip
(The model has just 3 objects, a source, a queue, and a rack)
. This time I doesn't use TE. When Max Wait Time of the queue reached, the flowitem seems to be sent twice. How to overcome this? Thanks.

I am not sure if I understand the problem. In my eyes it is working just as it is modeled.
Two items arrive at time 0 at the Source. They are batched in the Queue and given as a batch to the rack. Two items arrive in the rack. The Sendto Statement is fired twice, because two items are leaving. In my eyes this is correct, or am I wrong?
Why to overcome it? Just take care that both items are send to the same port, right?
There are also some threads about doing stuff at time 0 (zero). I remember also a thread with a Source and a Queue and doing stuff at time 0 (zero). This could leave to strange behavior because of having different events at time 0 (zero) and for sure if trying to control objects.
I am sure that these threads can be found by using the Search functionality in the forum. But this seems not to be the issue here.
Good success …

Thanks, Tom.
When time reaches 5, the flowitems in the rack will change there positions, do you notice it?

According your suggestion, I set the source's time to nonzero, then it behaves normally. Thank you.