Using Queue in a decision tool

Greeting,

In Chapter 8 of the textbook, one example require the usage of queue as a decision portal to inflow. The situation is if flowitems time in the queue exceed a certain time, they should be directed to an exit (sink). I tried using the on enter trigger to set arrival time for the flow item - current time, but I can't find the correct command for that. Any idea would be appreciated.
Thanks

Hi Simulmaster,

try senddelayedmessage, check OnMessage if the item isn't released or is still in the queue and release then the item to the port of the sink.

Jörg

Hi Jorg,

Thanks for the reply. I don't see how the time get evaluated inside the queue. Don't know if the question I'm asking is is clear enough to understand. attached is a simple model of what I'm trying to do.
Thanks

Hi SimulMaster,

first of all there must be some waitting flowitems in the queue. To achieve this you have to specify the output ports under the flow tab. If you choose first available then all flowitems leave immediately through port 1 or 2. All flowitems should go to the next queue (output port = 1).
Now there are some waitting flowitems in the queue. If you send a delayed message to same queue on the OnEntry-Trigger and you put in the message a reference to the current flowitem as a parameter, then you can release the item in the OnMessage-Trigger. Messages contain only numbers not pointers. Please change the pointer >>item<< to a number: tonum(item).
In the OnMessage check if the flowitem is still in the queue. If it is still there, release the flowitem. The command >>releaseitem(obj)<< expects a pointer. Convert the number of your message parameter to a node >>tonode(num)<<.
if you don't check the location of the flowitem and you release every flowitem, some will be released twice through the same queue and you maybe jeopardize your simulation.

Jörg

Hi SimulMaster,

another approach is to check the waitting time under the Flow tab, Output > Send To Port.
Here you can check if the current waiting time is greater than your max. waiting time then you send the flowitem to the port 2 else to port 1.
You can store the entrytime in a label on your flowitem or you evaluate the node number stats_lastmovetime(item) with the command getnodenum(obj).

The difference of current time and the entry time is the waiting time.

Jörg

Edit: I made a mistake, this approach doesn't work.

Is there a way to tag the time a flowitem enter a queue, and determine based on the stay time in the queue to output port to send it to. for instance if an itemflow enter a queue and gets processed before 10 minutes, use port 1, otherwise it should be automatically directed to port 2 after the 10 minutes time is up. in other simulation you can tag the time an item enter an object and use that to subtract from the current system time to determine if a certain time frame has passed. I don't seem to find that in Flexsim, I know there is a way to do it, I just don't know how

In Flexsim you get the actually time with using comand: time()
But how I would try to solve your question would be to send a delayed message when Item arrives with delay of 10 minutes and if item still is in queue give it the way to queue 2.

Maybe my example model does what you want?

Originally Posted by Sebastian Hemmann

In Flexsim you get the actually time with using comand: time()
But how I would try to solve your question would be to send a delayed message when Item arrives with delay of 10 minutes and if item still is in queue give it the way to queue 2.

Maybe my example model does what you want?

Thanks Sebastian, that clarified what I was trying to comprehend, I'm surprised that Flexsim doesn't have a function within either the trigger or some attribute that could be set to achieve what you've done with your custom programming.
Thanks again

Hi SimulMaster,

I think the part you speeking about could be somthing like a Maximum Dwell Time in Rack or an option in Picklist of "Send to Port" field. Because as Flexsim is event orientated no other Trigger would be usefull for it. But at the end there will never been all thinkable solutions in any picklists and so it´s nice to have the posibility to build it up with some coding.
With knowing the right vocabulary it even is no problem. Only finding the right vocabulary sometimes isn´t easy. Out of my opinion this is just a problem of complex User Manuals;-) So it´s not allways necessary to make every option fast available because this will rise complexity.

After having a look into the thread it looks very much like the solution Jörg spoke about.