Batching, max wait time

Hi, I have looked into the WPF and the 2 processors. In fact, your code was fine in releasing and having the flowitem fulled into the processor. However, at time 525 after the flowitem was pulled into the processor the flowitem was not hold by the processing time and end of processing was not fired. Subsequently, the flowitem went back to the WPF queue. Very strange!!!

Flexsim experts, any input on this??

David,

What you said describes part of that problem. In fact if you look closer, P105007.007 should have been batched together with P105007.005. But is not batched. Partly because of the label Batch flag I suppose.

Chieng

Chieng,

I have further checked. The part 007 is called into WPF21 one after another. But the funny thing is that 007 was not forced to stay for the processing time and the processfinished trigger was not triggered. Therefore the process stage was not increased to the next and hence it is returned back to WPF.

David

At 515 when the item entered WPF P105007.007 was given a return 0 in the SendTo. So this item was already released when you released it with releaseitem() in the WPF OnMessage at 525.

You're right. So P105007.007 SHOULD be batched together with P105007.005. and they ARE batched together. but somehow, P105007.007 skipped proccess time and onProcessFinish trigger..

but somehow, P105007.007 skipped proccess time and onProcessFinish trigger..

...because you released it a second time. The item was allowed to enter WPF21 at 525 because it was in a released state, given by the return 0 in the SendToPort code at 515. Then your OnMessage code released it again while it was already in WPF21, thus causing the strange behavior.

Make sure your code returns -1 in the SendToPort at time 515, then the problem will not occur because your OnMessage at 525 will release the item for the first and only time.

How do you know there's a return 0 in sendTo at 515? The codes at WPF/onMessage says not to continue with the batching codes when "sendto" is not equal to 0. and at that time "sendto"!=0. There is already an existing batch P105009.006 and P105009.002, so P105007.007 shouldn't return 0 at 515.

There is already an existing batch P105009.006 and P105009.002, so P105007.007 shouldn't return 0 at 515.

Your WPF/SendToPort code says return 0 when the "sendto" label is not equal to 0.
return 0 tells Flexsim to release the item to the first available port, subject to any downstream PullRequirements. Even if the item cannot leave immediately, it is in a released state.

At time 515 your "sendto" label is 2, so the code returns 0. I added some prints to the output console to your SendToPort code below.

if(getlabelnum(current,"sendto")!=0)
{
	pf(time());pt(" WPF SendToPort on item ");pt(getname(item));pr();
	pt("	sendto label = ");pf(getlabelnum(current,"sendto"));pr();
	if(comparetext(getname(item),"P105007.007")==1 && time()==515)
	{
		colorwhite(item);
		//return -1;  //do not release item
	}
	return 0; //release to first available port
}
else
	return -1;  //do not release item

The codes at WPF/onMessage says not to continue with the batching codes when "sendto" is not equal to 0.

At time 525 your "sendto" label is 0, and P105007.007 is released as item2 in your code using releaseitem(). I added the following code at line 28 of WPF/OnMessage to print to the output console:
pf(time());pt(" WPF Case1: release ");pt(getname(pilotitem));pt(" and ");pt(getname(item2));pr();

I'm not sure which of the 2 releases you want to avoid based on how you think your logic should work. But you should not release an item that is already released. Maybe getitemstate() might help you, look it up in the command help.


fyi: next time don't name your label "sendto", because that's how many users refer to the SendToPort picklist code... it won't cause errors, just confusion when reading your posts.