Using Reevaluate Send To vs Pull

All,

This model was created to demonstrate to another group how to use the Reevaluate Send To feature and how that same situation could be done using pull logic.

The top group of objects uses pull logic to send the different flow items to one of the two processors with the same color bar in front of them. The bottom group uses the reevaluate send to port to do the same problem.

The reevaluate send to is a very handy feature. Basically if you have a part that needs to go to certain down stream objects then your send to port can search for the appropriate object. However, if all of the objects are unavailable then you simply send it to one of them any way. When one of the objects becomes available the reevaluate send to will cause the send to code to refire for that object. This way the object will not continue to wait for the object you originally sent it to but will go to the one that just became available.

In the sample model provided this greatly reduced the amount of code and the number of objects the code needed to be on.

Let me know if there are any questions or comments,
Brandon

Does "Reevaluate Send To and pull mode" always have same behavior?

Qin,

With such a vague question it's hard to answer specifically but I'll give it a try.

Yes it will operate the same way every time if it is used this way.

No it won't if you don't set the situation up right.

Let me clarify; if a flowitem does not have a port to exit after the send to port trigger fires then it should be reevaluated when a port becomes open. However, I can not with confidence say that it is the same when you return a zero in the trigger. The reason for this is simply: why would you want to? You said to go anywhere and now anywhere is available. Maybe someone with the desire to test this can let us know.

The solution I have taken to this problem (mainly becaue there were ports I didn't want the item to go to) was to return a specific port that I 1)was OK with the item going to and 2) already knew was closed.

Another situation that I have run into that I have found using this method usefull for was when I didn't want to release an item yet. Basically I had a queue that I wanted to fill before I released any items and I wanted all of them to be released to the same port when they were released from a queue. The problem is that when you enter a queue you are released right a way and the send to port trigger fires right then. So, how do you pick the right port when you don't know where to send it yet (that is determined when the queue is full)? My solution was to return nrop(current) + 1 (meaning 1 more than there are ports) if the content was not equal to the max content or a label was equal to zero. On exit of the max flow item (it was released because the content was equal to the max content) I set the port label equal to the port it is exiting. Because the max item leaves it causes the send to port field to reevalutae and because the port label had a value I return that value. This way nobody leaves until we are full and everyone leaves out the same port. Upon exit of the last item I set the label back to zero.

I hope this helped,
Brandon

thanks,
In your situation, maybe you can use perform batch option of the queue.

Qin,

Using the batching option is a possibility but there were some non-disclosed factors that made that option more difficult than the one described.

Brandon