that depends on how you built your model and your transports. You can always use something like
wait for 86400; -- wait for one day
in a method.
if you have a Buffer from where the transporter picks up the parts, you could do something like
Don't know if that can work in your model.
Thanks again for your reply. I have been meddling with this for quite a while.
I have 2 different situations.
In the first one, I have a buffer with 1000 capacity from which only 100 is to be released to next singleproc on daily basis i.e. after sending the first 100 parts, the buffer has to wait to for 86400.
In the second case, I have a buffer with 1000 capacity from which only 100 is to be loaded on to a transporter which delivers these parts to the next station and comes back for the next 100 parts. I want this transporter to wait (86400) before it comes to pick the next set of 100 parts.
In both cases I want a gap of a day between each delivery.
Method in the attached image is used as an entrance control for the buffer.
Please help. If you could explain with a small demo model, that would be really helpful.
Have managed to create a small model that works to release the parts from the buffer every 24 hours by controling the exit of the buffer, not tested but this should also work for the transporter solution as well.
It works by locking the exit and then waiting until the correct time, the first time can be pre configured within the variable (set the initial value to what you want the first batch to be released at, in this case 5 hours). After waiting it will unlock the exit to allow for part flow and then change the next out time to be in a days time and then set the target value for the number of parts to be released before waiting for this to be achived before locking the exit and calling it self to run again.
You will notice that with where it caculates the next out time, this is set up to run every 24 hours from when the first part is released from the buffer and not from the last part being released. To change this you got to move the line to after the waituntil statment but of course assuming you cant dump the 100 parts in an instant then the time will slowly creep backwards at each stage.
If your process for the 100 parts means it could take over a day to take the parts from the buffer then the abs statment within the wait statment should make it instantly release the parts with its current configuration, if you wish to then release 24 hours from this point and not from the original time then change 'TimeOut += 86400' to 'TimeOut := EventController.SimTime + 86400' and this should do that for you.
I've created a small example model that will release up to 100 parts from the buffer, then lock the exit. Every 24 hours, the exit is opened and the counter reset to zero.
I added user-defined attributes to the buffer:
You can create your own buffer-class in the class-library like this, in case you need more than one buffer with this functionality.
Well if it looks to be an interesting problem then I will try to solve it, is always good to see more than 1 solution as the person who asked the question might like 1 approach more than the other.
Ah yes, did not think about if the statics got reset, was more thinking about the most lightweight approach that could be done. If the statics got reset during the 100 parts being released then it would cause it to realase all of the previous parts and 100 extra in addition to what has already left.
Was originally thinking of doing it similar to your approach until i thought of a different way to do so, if I was to add a new count attribute (or variable as its what SharadKokkarne appears to use) then I would still personally use the waituntil statment in my approach as it keeps all of the control code in 1 location and not spreads it across multiple methods making it harder to maintain. In the process you lose the ability to handle tasks easier (like schedualing the method to run in a days time) but you can also then make it a bit more adaptable at the same time and easier to follow.