I am facing one problem in Buffer object.
I am storing 510 objects as 3 days inventory in buffer. Each day I have to release 170 objects from buffer. So to stop after 170 I am using exit control of buffer. It is working for 2 days out of 3 i.e. exitlocked becomes true. At 510th entity it is not going in if loop although it satisfies the condition.
var i : integer
B_eShaft6_exit := B_eShaft6_exit+1
i := 170*B_eShaft6_out
if ?.statnumout = i
B_eShaft6_out := B_eShaft6_out+1
B_eShaft6_out is variable and indicates the number of batches buffer has released.
My conclusion is if the buffer is getting empty it is not going in if loop. Attached is video for your reference. Please guide me for this.
Solved! Go to Solution.
quick question while downloading the video: are you using a warmup-phase (i.e. is EventController.StartStat > 0)? In that case, statNumOut is reset during the simulation and your condition would actually not be true.
OK, now I've seen your video and apparently the condition is true but still the IF-block is not executed. So this seems like something for the Siemens guys...
Which Patchversion do you have, and have you tried running your model in Plant 13?
I'm not saying it will work in Plant 13, of course But some errors may not occur in the latest (patch) versions.
Also: does this problem only occur for one buffer? I assume the other ones on the left use the same exit-control?
Is the exit-control triggered only once (--> can it happen that the "@.move" is not successful?)?
What happens when you add the same if-condition one more time to the method, say before your one and just put something like this to see whether that IF-block will be executed or if both do not work:
if ?.statNumOut = i print to_str("Buffer ", ?.name, " will be closed now"); end
Can you actually upload your model instead of a video? If not, can you reproduce the problem in a small dummy/example model?
Others are also working on same logic but when buffer is empty they also work just like this. So i thought it is problem of buffer as all are not working properly.
Sorry i can not share the actual model. I will prepare the small model and share.
Thanks Steffen it is working now.
However, I am not able to find out the logic behind it. How front and rear exit control can make the difference in this case.
|Steffen Bangsow |
freelance simulation specialist
Wow, really? I thought the problem would be that in some cases the @.move is not successful (it returns false) and with the new setting "ExitCtrlOnce" since Plant 12, the MU has not left the buffer, so statNumOut has not changed yet. When it can later actually leave, the exitCtrl is not called again so the if-block is not reached (by the correct MU).
That's why I asked "can it happen that the "@.move" is not successful?"
What you are saying would imply that even though @.move is successful, while the MU is still in the front-activated exitCtrl, the statNumOut has not changed yet. That would be wrong for my understanding. As soon as @.move was (successfully) executed, the MU has left the buffer and statNumOut should have been updated.
Anyway, if we had a "good-practise" thread somewhere here, then "don't use a front-triggered exitctrl to update statistics etc." would be way up there in the Top 10