Reevaluate pull strategy check box?

[nmzenke]

[ FlexSim 16.0.1 ]

As stated here:

https://answers.flexsim.com/articles/19445/flow-page-23.html

"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?

[adrian_haws]

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.

[nmzenke]

@regan.blackett

[nmzenke]

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.

[Matthew_Gillespie]

How to post confidential information on Answers

[adrian_haws]

@Noah Zenker Sounds good, just let us know when you have an example or more information ready.

[Brandon_Peterson · Accepted solution]

@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,

Brandon

[shankar_narayan]

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.

Conventional:

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.

PullStrategy:

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.

[philboboADSK]

@Shankar Narayan,

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