a question on queue

Hi, I would like the flowitem to be stored in a queue for a specific time before it can be transfered to the next location.
How can i do that?

My idea would be to control the output of the queue.

I see different scenarios behind your questions. If the queue should work like a processor than you want that each flowitem stays for an amount of time and then leave.

Another scenario could be hat only every 5 seconds a flowitem should leave the queue.

So I give you a general answer and I am sure you will figure out the solution for your scenario.

Control the output of the queue with closeoutput() and openoutput() and senddelayedmessage().
Or you could do it with stopoutput() and resumeoutput() and senddelayedmessage() if you want to count how often you ‘close’ and ‘open’.

Every flowitem stays an amount of time in the queue:

OnReset
closeoutput(current);

OnMessage
openoutput(current);

OnEntry
senddelayedmessage(current,5,current);

OnExit
closeoutput(current);


So the delay time in the senddelayedmessage() is the time the flowitem stays in the queue.

You could also use the minimum dwell time in the rack..

Okay, than you can also use a Processor (because flowitems can ‘overtake’) with a specific capacity (queue capacity) and the ProcessTime is the time he stays there.

Thanks for the solutions, my problem is solved.

problem again. When I use:

OnReset
closeoutput(current);

OnMessage
openoutput(current);

OnEntry
senddelayedmessage(current,5,current);

OnExit
closeoutput(current);

on the queue, it works if no transport is required for the queue.

If transport is needed in the queue, it only works for the 1st item waiting, but after the 1st item waiting time is over, all other item in the queue can be picked up by the transport directly without waiting.

Please see the attached file for reference.

Please advice, thanks.

I noticed the same thing. Without using opertors, it works fine. If using operator, the item will not wait after the first a few of items. Here is some print out.

item0 enter at 16.673384
item0 exit at 21.673385
item1 enter at 30.165741
item1 exit at 35.165743
item2 enter at 35.647432
item3 enter at 40.025096
item2 exit at 40.647433
item3 exit at 40.647437
item4 enter at 54.077713
item4 exit at 54.077715

As you can see, after 3 items, item won't wait any more. I attached a sample model for your convenience. You can try enabling "Use Transport" or disabling "Use Transport" to see the difference.

Is this a supposed behavior of the Flexsim objects or a bug?

Using the Rack object as Nico suggested with a Minimum Dwell Time specified will work with an operator and does not involve custom code. If you want it to look more like a Queue I would suggest choosing the Floor Storage option and changing the number of Bays and Levels to 1.

In the example that Alan provided, if you remove the delayed message and then manually call an openoutput() on the queue you will notice that task sequences (work orders) for the operator to transport are created for ALL items in the queue at that moment. Why? The Sink has an unlimited capacity for receiving flowitems, thus the moment the output of the queue opens, all items will get a brief GO signal. The Use Transport will then be evaluated (task sequences will be created) and the operator will get to the items as soon as he can. Closing the output after the fact will not stop the operator as he is simply following the original orders.

How can I stop the release of flowitems independently?
There is a pick option close to the bottom of the Send To Port pick list called Do Not Release Item. This simply returns a -1 in the code. Then use the releaseitem() command somewhere else and be sure to specify the port that the flowitem should be routed to. If you do not specify a port in this command the Send To Port will be re-evaluated (helpful if you have a conditional statement). In this example we could create a delayed message OnEntry with the item as the message sending (From) object and in the OnMessage trigger write:

releaseitem(msgsendingobject,1);

Alan,

I am a little surprised that you did not know that task sequences overrule input and output control. I teach this in my training classes. So if you like to join my next training class …

I am glad that Kris told me on Skype that he is busy answering this thread and saw me be active in this forum. So he saved me some time.
In my eyes his explanation and idea how to solve it is just great. To be honest better than every of my explanations or ideas would have been. Respect!

Right, I hope KelvinHo is now having hints and ideas how to solve this interesting little problem.

Thanks, Guys.
tom the (A)tom

I have to admitted that I am confused again with this issue. I have encoutered this problem before and am aware of the releaseitem solution. It is just in a glance that with or without using operators, the system is supposed to behave the same. Why does Flexsim create the tasksequences for all the items in the queue instead of one by one? Is there any particular reason for this?

In addtion, thanks for your offer, TOM. I would like to take your training if there is a chance.

This situation points out the inefficiency and danger of using closeoutput() in an OnExit trigger. It is also a lesson on Order of Execution for a pushed flowitem (see diagram).

In both cases all flowitems in the queue are released when openoutput() is called because the Sink is able to receive all of them in an instant. The system behavior would have remained the same if the downstream object was a Conveyor or an object with a max capacity of 1 because only the transport request for the NEXT item would have been created. Also, the closeoutput in the OnExit would have the opportunity to be executed before another item transport request is dispatched.

By checking the Use Transport box we are not changing the routing logic - but we are adding the Request Transport From evaluation (a delay waiting for transport) before the OnExit which affects our timing-sensitive control method. The Queue only knows that the Sink can receive all of the flowitems so why wouldn't it create tasksequences to transport all? You might have a team of operators waiting to do the work. The Queue has no idea that in the OnExit of the first item (only after the operator gets there) we want to hold back all of the other items from leaving. It is too late in the Order of Execution to enforce this as the task sequences have already been dispatched. It is often difficult in reality and Flexsim to track down released work orders and cancel them.

Note that we could have called closeoutput just before the return in the Request Transport From code.

...I still like the Rack solution.

Thanks all, I decided to use rack to solve the problem.

The rack is definitely the best option for visualization! Just for noticification, another solution is just to use a Processor, which can process the amount of the queue simultaneously .

Hi, Kris,

Thanks for the detailed description. The execution order when using transportor option is very clear.

Originally Posted by Kris Geisberger

...The Queue only knows that the Sink can receive all of the flowitems so why wouldn't it create tasksequences to transport all? ... The Queue has no idea that in the OnExit of the first item (only after the operator gets there) we want to hold back all of the other items from leaving...

All the above are also true when not using transportor. But we do not release all of the items in the case of not using transportor. So I guess there may be a reason (efficiency?) that Flexsim creates the tasks of all flowitems in the queue instead of one by one, although I think it may not matter.

However, I learned a lesson here. I will never use closeoutput(), closeinput() etc. to dynamically control flows, although sometimes it is attractive. As you said, it is dangeous and will not work if transportors are used.

Originally Posted by AlanZhang

... But we do not release all of the items in the case of not using transportor. So I guess there may be a reason (efficiency?) that Flexsim creates the tasks of all flowitems in the queue instead of one by one, although I think it may not matter.

The reason is in the order of execution diagram, please look again. The closeoutput method we tried counted on an assumption that there is no time delay between the SendToPort and OnExit. If there is a delay between SendToPort and OnExit for a given flowitem, that would give the next flowitem in the queue the opportunity to be released to the Sink. It would have the opportunity because the OnExit for the first item contains the closeoutput that stops the SendToPort of the next item.

Unfortunately, there are 2 possible delays that could occur according to the diagram.

1. The first 'possible delay' immediately after the SendToPort in the diagram is only a potential if the receiving object has a limited content... Sinks never have this problem, but all other objects might say "No" to an incoming flowitem depending on its current content. For a Sink our assumption was fine... WAIT, if the input of the Sink (or whatever receiving object) was ever closed, a delay would occur and our assumption would fail.

2. The second delay only occurs if a transport is requested... if so, a delay is guaranteed to occur. Regardless of the type of receiving object, the approach failed.

...BUT, IF no transport is required, AND we use a Sink, AND we never close the input of the Sink, both assumptions hold true and the method works.

Originally Posted by AlanZhang

...I will never use closeoutput(), closeinput() etc. to dynamically control flows, although sometimes it is attractive.

...'never' might be too harsh. We did not discussed or use closeinput() in this example.
Yes, it is true that a closeinput() called on an object will not stop the task executer from unloading a item to this object, when the task executer has already received a task sequence to transport an item or many to this object.

I think the real lessons here are:

1. Know and chose objects carefully. In this case an approach using a Queue+code was more difficult and fragile than using a Rack without custom code.

2. Be careful when implementing a transport in an area where you are controlling the flow using closeoutput() or closeinput().

Even I have a similar problem...... can you guys help me...

I have a Rack that has 100 items. An operators picks items from the rack and places it in a queue which is the output port for the rack. I want the operators to stop after picking 50 items..

So I did something like this..

On the exit trigger of the Rack

if ( content( current) == 50)
{ closeoutput(current)
}

But it dint work.. what is the alternate solution for this ??