Batch Behavior Q.

Hi,
I would like to know why in this simple model, on the second day the batch is not released when it is complete?
Generally, my purpose is
Wanted
I want to have control over how many times (say counter=2) my batch in the queue is released in one working day(say 6-16).if at the end of working day(16 p.m.), the batch is not complete, simply release it.

Model
A source, queue and sink is placed (pls, c.f. attachment).
Global Variable: a Global Variable is defined (namely "counter"). the counter is responsible for counting how many times the batch is complete. here I want a maximum of two batches to be released for a day.

Time table: A time table for queue is defined that Ondown, it clears the contents of the queue and adds one to the counter and Onresume it puts counter=0 and openinput of queue.

VISUAL TOOL: Operational time is shown as Working day and OFF is schedule down.

Queue: On the Endcollection,I have increased counter and if(counter ==2) closeinput.
On the entry,the code is if(counter ==2) closeinput.
__________________________________________________ _______
It doesn't do what I like on the second day and afterwards. the first day is alright. the second day, it reaches the batch size and doesn't release the batch (at about 2 Day 15hr)?? (what is it waiting for?).

This would be more strange if you choose "Flush Contents between batches".
thanks.

Hi,

just had a short look at your modell. Purely couldn´t spend to much to it. But what I found, that on day 2 you closed the input of the queue and never open it again. So probably you can set it in the timetable or any trigger to open the input of queue again. This will make it an little easier to see what you want.

Greetings

Originally Posted by Sebastian Hemmann

Hi,

just had a short look at your modell. Purely couldn´t spend to much to it. But what I found, that on day 2 you closed the input of the queue and never open it again. So probably you can set it in the timetable or any trigger to open the input of queue again. This will make it an little easier to see what you want.

Greetings

you might be right, but it doesn't change the status of it having a complete batch available and not releasing it?

So I´m not sure at all. Only hint I can give you is, that "stopobject" normaly turns off the object at all. Most information the object gets while being in this state, get lost. That is why sometimes strange things happen, after using this command. In your model most logic works directly in the border to this function.
I tried a little, but didn´t find a working solution till now. For this I have to know more about what really should happen. And I will need more time, what is the bigger problem actually.
Probably it is possible to find a solution in which only the ports are opened/ closed by sended messages, even of timetable.
The batch process should work the same way. Only waits until the content reachs a level, opens output and afterwards closing it again. So you can turn this of an build a little level filling in triggers of queue. Flush contents realises, that the queue has to get empty, until the input port releases new items. This you will not need in your example anyway. Because all items leave queue at the same time.

For me this sound like the issues which occur if Queue are used and a number of items arrive at the same time in the Queue fire several events/triggers. Flexsim takes a number of items and fires the events (kind of batch processing) which can end in strange behavior. I remember several threads about this subject in this forum (Queue, Batch, Source – Queue combination, Control input/output at a Queue, etc.).

Anyway, I had a look into the model.
To be honest, I am not sure if I fully understand what you are trying to do, even if you explain it.
I understand that you want to control the number of batches of the queue for a working day, let’s say only two per day should be released. If at the end of the day the batch is not complete just release all items in the Queue.

In your model I see that at the end of the day you clear the contents of the Queue. In other words you destroy the items and do not release them. Check the input of the Sink, which is 30 (one batch).
So if you want to release the items you need some code here and I would think a loop and releaseitem() would do the job.

Seeing that you use clearcontents(), in my eyes it is possible, that because you destroy the items something goes wrong inside the Queue functionality. Are the statistics updated correct for the Queue in this case? I did not check it in deep, but I could imagine that here is the problem (e.g. with the batch). I had a look into the tree and I see that the Queue is empty, but the variable “currentbatchsize” is 9. Here is for sure a problem.

The way I would probably try to solve the task would be to control the Queue by myself with delayed messages. Close the output of the Queue at the start (OnReset sends a delayed message to closeoutput()). OnEntry check how many items are in the Queue and if the batch size is reached, send a delayed message to openoutput(). Or another way could be to realeaseitem() 30 times, where I would test how the downstream objects behave (maximum content, etc.). OnExit after 30 items left, I would send a delayed message to closeoutput() again. The control of the output might be not necessary if the releaseitem() is used, because the output will always be closed.
If you use a time table and use stop and resume object you should check your control of the output, because I guess internal the commands open and close input/output.
At the end of the day (time table) you could just release all items in the Queue or also need to control the output depending which construct you use (releaseitem() or control output).
What I am trying to prevent is using the batch functionality on the Queue as you can see and make an own control.

I just wrote this out of my head so I did not do any testing. But I hope that this will give you some hints, what you could try to solve the task. If this will not solve the problem, I hope I will find some time to build a model for it, but I do not like to promise it.

As you can see I agree with Sebastian which is on the "same" track as I am. So controling the Queue and not using the batch functionality might be a step in the right direction.

Originally Posted by Sebastian Hemmann

So I´m not sure at all. Only hint I can give you is, that "stopobject" normaly turns off the object at all. Most information the object gets while being in this state, get lost. That is why sometimes strange things happen, after using this command. In your model most logic works directly in the border to this function.
I tried a little, but didn´t find a working solution till now. For this I have to know more about what really should happen. And I will need more time, what is the bigger problem actually.
Probably it is possible to find a solution in which only the ports are opened/ closed by sended messages, even of timetable.
The batch process should work the same way. Only waits until the content reachs a level, opens output and afterwards closing it again. So you can turn this of an build a little level filling in triggers of queue. Flush contents realises, that the queue has to get empty, until the input port releases new items. This you will not need in your example anyway. Because all items leave queue at the same time.

I would say that what I would like the triggers of Ondown and Onresume to do is just to open and close input port of queue. that's why I tried to use
Ondown: closeinput + clearcontents and Onresume: counter=0 and openinput.

So the problem with Stopobject and Resumeobject do not interfere.It doesn't work unfortunately.

I am not sure if the problem comes from clearcontents because I have tried other commands like while(objectexists(last(current))) {moveobject and destroyobject ...} that work as good as clearcontents. however, the same old problem exists.

Originally Posted by Tom David

For me this sound like the issues which occur if Queue are used and a number of items arrive at the same time in the Queue fire several events/triggers. Flexsim takes a number of items and fires the events (kind of batch processing) which can end in strange behavior. I remember several threads about this subject in this forum (Queue, Batch, Source – Queue combination, Control input/output at a Queue, etc.).

Anyway, I had a look into the model.
To be honest, I am not sure if I fully understand what you are trying to do, even if you explain it.
I understand that you want to control the number of batches of the queue for a working day, let’s say only two per day should be released. If at the end of the day the batch is not complete just release all items in the Queue.

In your model I see that at the end of the day you clear the contents of the Queue. In other words you destroy the items and do not release them. Check the input of the Sink, which is 30 (one batch).
So if you want to release the items you need some code here and I would think a loop and releaseitem() would do the job.

Seeing that you use clearcontents(), in my eyes it is possible, that because you destroy the items something goes wrong inside the Queue functionality. Are the statistics updated correct for the Queue in this case? I did not check it in deep, but I could imagine that here is the problem (e.g. with the batch). I had a look into the tree and I see that the Queue is empty, but the variable “currentbatchsize” is 9. Here is for sure a problem.

The way I would probably try to solve the task would be to control the Queue by myself with delayed messages. Close the output of the Queue at the start (OnReset sends a delayed message to closeoutput()). OnEntry check how many items are in the Queue and if the batch size is reached, send a delayed message to openoutput(). Or another way could be to realeaseitem() 30 times, where I would test how the downstream objects behave (maximum content, etc.). OnExit after 30 items left, I would send a delayed message to closeoutput() again. The control of the output might be not necessary if the releaseitem() is used, because the output will always be closed.
If you use a time table and use stop and resume object you should check your control of the output, because I guess internal the commands open and close input/output.
At the end of the day (time table) you could just release all items in the Queue or also need to control the output depending which construct you use (releaseitem() or control output).
What I am trying to prevent is using the batch functionality on the Queue as you can see and make an own control.

I just wrote this out of my head so I did not do any testing. But I hope that this will give you some hints, what you could try to solve the task. If this will not solve the problem, I hope I will find some time to build a model for it, but I do not like to promise it.

As you can see I agree with Sebastian which is on the "same" track as I am. So controling the Queue and not using the batch functionality might be a step in the right direction.

Thanks a lot.
you're absolutely right in currentbatchsize is not zero. so I simply added this line to the Ondown trigger of timetable: setvarnum(downobject,"currentbatchsize", 0);
and it works as I like.

Before I thought if the content in a queue is set to zero, it has the same meaning as currentbatchsize. now, I find out that this is not the case. clearcontents puts CurContent at zero but doesn't change the currentbatchsize.

just for interested.
I want to control the number of batches of the queue for a working day, let’s say only two per day should be released. If at the end of the day the batch is not complete just release all items in the Queue.

thanks to the contributers such as Tom and Sebastian.

Description:
the model tries to control the number of batches of the queue for a working day, let’s say only two per day should be released. If at the end of the day the batch is not complete just release all items in the Queue.

The comments in the code.
model
http://rapidshare.com/files/412318020/twobatches.fsm

(MD5: 0EC1D60744543C8CAE113D337673AFAE)

______________
there is sth wrong with zip attachment.

@ shafizad

If at the end of the day, a proper third batch isn´t complete, what should happen then? Or isn´t this relevant because of never possible?
In my opinion the only reason for controlling batches would be to reduce them and see what will happen. But if the number of items stay constant, the batchsize has to be changed.

Could u reformulate ur question? I am not sure if I understand what u mean.

There are two cases that could happen.
1- two batches are completely released in the working day ( before the day ends) 2- one batch is released and the next one is in progress.

the (1) problem is addressed by adding the counter at OnEndcollection trigger.
the (2) problem is addressed by Timetable triggers.

Sorry for this long time between my replies.
My question only had been:
When your 2.batch is released but there are still arriving items, what should happen with them when day is over?
1. Sending a "smaller" 3. batch the standard way?
2. Destroy without counting?
3. Sending the "smaller" 3. batch to another way?
4. This can´t happen.
Or anything else, not in my mind?