Noah Z avatar image
Noah Z asked Ben Wilson edited

Reevaluate pull strategy check box?

As stated here:

"reevaluate pull requirement on all items when each upstream item is released - this parameter is only visible if "pull" is checked. If checked, the object will re-evaluate the pull requirement for all released flowitems upstream every time a new flow item is released. This is much like the Reevaluates sendto on downstream availability check box, in that you may need to explicitly call openinput() if you want to manually trigger the re-evaluation of the pull requirement."

However, when I have the "Pull" requirement checked (see screenshot) I don't see any checkbox. I need this functionality for a model I'm working on. How do I make the queue (or other fixed resource for that matter) reevaluate the Pull logic each time an upstream flowitem is introduced?

FlexSim 16.0.1
queuecombinerpull strategypull requirementreevaluate
no-checkbox.png (51.3 KiB)
· 5
5 |100000

Up to 12 attachments (including images) can be used with a maximum of 23.8 MiB each and 47.7 MiB total.

Adrian Haws avatar image Adrian Haws commented ·

That checkbox is no longer used, and we'll make sure the documentation is taken care of. it was removed because it didn't accomplish what users were expecting it to.

Could you be more specific with what you're trying to do with the pull logic? And if possible it's always helpful for us to see a model.

0 Likes 0 ·
Noah Z avatar image Noah Z Adrian Haws commented ·

Since the checkbox has been removed are the pull requirements automatically reevaluated when there is a new flowitem entering the upstream queue/combiner/etc. now as the default?

I unfortunately can't attach my real model to this discussion but let me try to recreate my issue in a dummy model and post that here with some further clarification on the behavior I'm seeing.

0 Likes 0 ·
Show more comments
Noah Z avatar image Noah Z commented ·
0 Likes 0 ·

1 Answer

Brandon Peterson avatar image
Brandon Peterson answered Ben Wilson edited

@Noah Zenker,

I ran a simple test where I had one source feed three queues that then feed into one processor. I set the sendtoport on the source to "Round Robin" and I set the pullrequirement on the processor to only pull the 2nd item unless the total content of all three queues was more than 2 and the item was in the first queue.

/**Only pull the 2nd item unless there are more than 2 waiting*/
int totcont = content(inobject(current, 1)) + content(inobject(current, 2)) + content(inobject(current, 3));
if(getrank(item) == 2 || totcont > 2)
	return 1;
return 0;

This setup creates a situation where the 3rd created will enter the 3rd queue with one item already in each of the first two queues. According to the logic above, the 3rd item will not be pulled because it is the 1st item in the 3rd queue. If the pullrequirement was automatically reevaluated then the item in the first queue should be pulled at this time because there are more than two items total in all the queues and it is in the 1st queue. It does not get pulled until after the 4th item enters the 1st queue gets pulled to the processor and exits. I placed a break point in the pullrequirement and it is obvious that the the code is not fired for the 1st item until after the processor finishes processing the 4th item.

So I believe that the answer to your question is: No, the pullrequirement is not automatically reevaluated.

In the past the checkbox that you are referring to would change the variable "pullcontinuous" on the fixed resource to 1. I tried manually changing this variable to 1 and ran the test again. Again, the 1st item was not pulled when the 3rd item entered the 3rd queue. However, when the 4th item entered the 1st queue the 1st item was pulled instead of the 4th.

After setting the pullcontinous variable back to 0 I decided to try another approach. On the entrytrigger of each queue I added code to close and then open the input ports of the processor. This caused the pullrequirement to evaluate for each of the items that had entered the queues prior to the entering item. This resulted in the 1st item being pulled into the processor when the 3rd item entered the 3rd queue. I think that this approach will help you with your issue.

I hope this clears things up for you,


· 2
5 |100000

Up to 12 attachments (including images) can be used with a maximum of 23.8 MiB each and 47.7 MiB total.

Shankar Narayan avatar image Shankar Narayan commented ·

Hello @Brandon Peterson

I have a similar problem with Pull Requirement not behaving as expected with Conveyor Entry Transfer objects.In the attached sample model, I have two representations of the concept.


The concept on the bottom uses a conventional technique which uses an item label to route the item to the intended conveyor with the Rack object using a conditional SendToPort logic. This works as intended.


The concept on the top however uses a Pull Strategy with a global item list to pull items based on partition ID and Pull Requirement to pull only matching label value for each of the Entry Transfer. This does not work as expected. I have even implemented your 'Close and Open downstream object port' logic on the Entry Trigger of the Rack Object. Still no luck. Hoping you can shed some light on what is wrong with this Pull Strategy on Entry Transfer and perhaps offer insights to how to get this to work.

Thanks in advance for your advice.

0 Likes 0 ·
Phil BoBo avatar image Phil BoBo ♦♦ Shankar Narayan commented ·

@Shankar Narayan,

You should post new questions as new questions instead of as comments to existing, answered questions.

1 Like 1 ·

Write an Answer

Hint: Notify or tag a user in this post by typing @username.

Up to 12 attachments (including images) can be used with a maximum of 23.8 MiB each and 47.7 MiB total.