A question about request transport in a rack object

It seems the rack object uses different methods to request transport than the queue object. The attached model shows such a difference.

In the model, Rack1 and Queue1 each has 100 items arriving at time 0 with priority 0. Rack2 and Queue2 each has 50 items arriving at time 50 with priority 10. So the desired behavior would be operators first transfer items in Rack1 and Queue1, then after time 50, operators will switch to Rack2 and Queue2 since items there have priorities. Although Queue objects have desired behavior, that is not the case for Rack objects. After time 50, Operator1 will still transfer items in Rack1 instead of Rack2. Checking the tasksequencequeue of Operator1, I find that the total number of task sequences is limited to 9.

Interesting thing is that if I change the number of arrival at time 0 to be 10 and number of arrivals at time 50 to be 5 for Rack objects, the desired behavior is observed.

Can anyone has an explanation about this? Is there anyway to get the desired behavior for a rack object?

Thanks.
Alan

Alan,


The problem in your model is the queue that is placed behind both the racks. Your rack 1 can send 10 products to the queue. So 10 tasksequences are placed in the transporter. When he brings 1 over, the queue can receive the next one and opens it's input ports, starting with the first one, and that is the rack 1. So this way only rack 1 is served until it is empty.

On the other hand if you use a sink, the tasksequences for all products are generated and placed in the transporter. If the products enter rack 2 then all these tasksequences will be generated as well and placed correctly (at the top of the list) in the tasksequencequeue. That means that the transporter is handling them correctly.

I hope this explains what you see.

Kind regards,

Steven

Steven,

Thanks for your answer. You are right. If I connect racks to the sink directly, the operator will switch to Rack2 correctly. So the number of tasks the operator can hold is limited to the capacity of downstream object (i.e., the queue). This is a little bit weired, because the operator has no connection with the downstream object. And priorities should work the same way no matter what downstream object is.

I also tested some other objects. For a processor, if I changed its capacity, the number of tasks of the operator changes. But for a conveyor, the number of tasks of the operator will not change no matter what number of the maximum content of the conveyor is.

Is there any good way to use priority if my downstream object is a queue, processor or conveyor with capacity constraints? Probably using Pull can achieve the same goal. But that would bring unnecessary complexity.

Best regards,
Alan

More questions:

1.
Which object generates tasksequence for operators? Upstream object or downstream object?

2.
Is there a way to limit the length of tasksequencequeue of an operator, say to 1?

Thanks.

Alan

Alan,

1. The upstream objects creates the task executers task sequence. Or in other words, by default, it is the object that you check the "Use Transport" box in the Flow tab of the object.

2. No. Unless the task executer passes the task sequence to another task executer, it will automatically queue up task sequences in its task sequence queue. But I don't believe there is a way to "disable" or limit the task executers queue size.

Jeff,

Thanks for your answers. After reading the FixedResource section of the manual, I am still confusing about how exactly flowitems are sent from an upstream object a downstream object using an operator.

It seems for each objects in a queue or a rack, the sendtoport, pullfromport, and pullrequirement functions will be called once these flowitems are shown in the upstream object. My questions are:

1.
Is there a way to cause Flexsim reevaluate these functions if the pullrequirement returns 0. I tried using "Continuously Evaluate Pull Requirement". Seems not working.

2.
Is there a way to release a flowitem in the upstream object at a desired time? For example, I want to release flowitems in a rack object one by one, thus the length of the tasksequence of the connected operator is only 1.

Thanks.

Alan

Alan,

Maybe some more info. If a upstream object want to send a product it checks if the object that you specified in the sendtoport can receive the flowitem. If it can receive it a tasksequence is generated and send to the transporter. The downstream object also keeps track of how much of it's capacity is already claimed and if it can receive more it will open it's ports again.

Concerning the conveyor, it can only receive 1 item at a time, so only if the flowitem is placed on the conveyor and has moved it's length the conveyor is opened again. On that trigger the upstreams object can send on the next flowitem and can create a tasksequence for it.

Concerning the rack, if you look at the dwell time rule, the last option is not to release the flowitem. If you use that option you can create your own release schedule by using senddelayedmessage and the command "releaseitem". This command also calls the sendtoport and requesttransport from triggers. But maybe you can use the dwelltime rule already in it's standard form to release the products at certain moments in time.

About having only 1 tasksequence in the transporter, the transporter is a dumb object in the sense that it doesn't determine what it's tasks are. The fixed resource objects generate the tasks for the transporter. So if you want to control the tasksequence list, you have to control the fixed resources.
There is 1 other remarks, if you use a dispatcher, the dispatcher queues up the tasks and only releases them 1 by 1, so the transporter has only an active tasksequence. Also if you set the capacity of the transporter to 1 it will never take more than 1 product even if there are more tasksequences in it's queue.

I hope this sheds a little more light on the matter.

Steven

Steven,

Thank you so much for your answers. Your explanation helps a lot.

I guess in order to let operator to pick objects in the Rack2 as a priority, a tasksequence for Rack2 has to be created. Thus, setting the priority of the tasksequence is not enough. I have to change the rank of the input port of the downstream queue object to set Rack2 be the first input port (or set priority of input ports using Pull logic). Thus, once the downstream object opens its input port, it will open Rack2 input first, thus creating a tasksequence for Rack2.

However, if the downstream object is a rack (with a capacity say 20) instead of queue, and the rack is NOT connected to a sink, the operator will not pick items from Rack2 even if the correct priority and rank of input ports are set. This is because at the beginning of the simulation 20 tasksequences will be generated for operator. The downstream rack object will no longer open its input port to allow a new tasksequence generated.

Any thoughts about how to solve this problem?

Thanks.
Alan

Alan,

The rack and queue are actually quite similar, so if you have a queue that is not connected to a sink with a capacity of 20 it behaves the same as a rack with a capacity of 20.

But for your problem, the following solution might work:
On the dwell time rule enter the code

if( content(current) == 1) return 10; //or what ever amount of seconds you want
return -1;

This will have the effect that only the first object is released and all other objects are hold within the rack.

then on the onexit trigger:
if( content(current) > 1) releaseitem(rank(current, 2)); //Because the first one is the one currently going out
This will have the effect that the next one is released when the first one is really going out.

That way there is never more than 1 tasksequence waiting in the transporter and when the products from rack 2 come in play, they occupy the rest of the capacity of the downstream queue or rack immidiately and those tasksequences are generated and the transporter will handle them first.

Regards,

Steven

Steven,

This is such a smart solution! Doing this way I do not even need to care about the rank of input ports of the downstream object. Thanks a lot.

Alan