Operator's unload logic

Hi, if anyone...

This is the situation:

- operator capacity 10 units
- source: always have more than 10 units ready to transport (buffer)
- destination: 2 equal queues to receive the flowitem
- Logic: The operator must unload the 10 flowitems in one destination until the destination is full (100 units) then he do the same with the other destination queue.
-problem: the operator leaves only one unit per destination traveling between destinations until drop the 10 units every time.

...Cuestion: There is a simple command like drop-all-units at time in "OnUnload trigger"?

is just to see if there is a quick way to do that.


Thanks.

René G.

Hi Rene,

think what you describe happens because your pickoption from Sendto logic is "first available". There is something like a unload all items for this destination in the pickoption of OnUnload Trigger of operator. But this shows you why operator walks to both queues only to unload one item. Because when loading Items both queues are available and so both queues set destinations.

The thing you should change is, to make all not used queues unavailable when giving operator it´s Tasksequence. So you will have to write some logic what queue should be first and what second and close the inputports of the otherone.

But at all this only will help as long as operator never has to transport boxes with mixed aims. If this will happen ever, you will have to build the whole model with creating your own tasksequences and this will rise programmig effort;-)

I don´t see another solution. Maybe anybody else got a hint!?

Hi Rene,

Attached is a model that may solve your problem. The logic to decide which destination queue to go is programmed in the input buffer's task sequence. I also defined a label in the first destination queue to count the total number of box sending to the queue.

Regards,
Bill

It works now!

i had tried to create a task sequence as advised sebastian but Bill you helped me a lot by example... thank you both.

I'll start to practice with more task sequence's programming.

René.