cancel
Showing results for 
Search instead for 
Did you mean: 

Problem facing for Buffer object in in 12.2 version

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

@.move

B_eShaft6_exit := B_eShaft6_exit+1

i := 170*B_eShaft6_out

if ?.statnumout = i

          ?.Exitlocked:= true

          B_eShaft6_out := B_eShaft6_out+1

end

 

 

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.

9 REPLIES

Betreff: Problem facing for Buffer object in in 12.2 version

Hi,

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?

Regards,
Alex 

____________________________________________________________
Alex Dilg, Consultant at SimPlan AG (www.SimPlan.de)
This post was good and/or helpful to you? Please provide some Kudos, thank you!

Betreff: Problem facing for Buffer object in in 12.2 version

No there is no warmup phase

Betreff: Problem facing for Buffer object in in 12.2 version

Thanks for reply. I am using 12.2 now. Looking forward to go to 13.

Betreff: Problem facing for Buffer object in in 12.2 version

I'm not saying it will work in Plant 13, of course Smiley Wink 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?

Regards,
Alex

____________________________________________________________
Alex Dilg, Consultant at SimPlan AG (www.SimPlan.de)
This post was good and/or helpful to you? Please provide some Kudos, thank you!

Betreff: Problem facing for Buffer object in in 12.2 version

HI,

 

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.

Betreff: Problem facing for Buffer object in in 12.2 version

Phenom
Phenom
delete @.move and try exit control rear

Steffen Bangsow
freelance simulation specialist  
web: www.bangsow.eu
mail: steffen@bangsow.net


Betreff: Problem facing for Buffer object in in 12.2 version

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.

Betreff: Problem facing for Buffer object in in 12.2 version

Phenom
Phenom
if you call the front control, the MU is still in the buffer (and statNumOut is still 709). If you use the rear control, the MU is "on the way" to the next station, the attribute statNumOut is 710.

Steffen Bangsow
freelance simulation specialist  
web: www.bangsow.eu
mail: steffen@bangsow.net


Betreff: Problem facing for Buffer object in in 12.2 version

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 Smiley Wink

____________________________________________________________
Alex Dilg, Consultant at SimPlan AG (www.SimPlan.de)
This post was good and/or helpful to you? Please provide some Kudos, thank you!