I just spent a while debugging a model that worked perfectly fine until I added shifts on certain machines. This caused the Exit Control to trigger, decrementing a value for the amount of products of a certain type that need to be processed on that machine (a CNC machine that cuts plates and that I represented by a dismantleStation). Since this happened when the buffer after the dismantleStation was full and could not accept any more MUs, the value was wrongly decremented.
I can easily fix this by only decrementing the value only when the move method is succesful, but I am wondering:
- Why does this cause the Exit Control to trigger again?
- Is there any way to prevent this behaviour from occuring?
Many thanks in advance.
Yes, I had that box checked, so I'm a little bit unclear as to why it triggers multiple times. If I have time I will try to make a small model to reproduce this situation, unless someone can answer me before that...
Did you find a solution? I have the very same problem now, a exit control in a parallellstation is triggered multiple times for the same MU, when a shift starts.
How do you check if the .move is successful? How does it help you in the workaround?
I met the same problem too, I think it maybe caused by that the mu in satation "A" did not enter the next station because the next station is blocked in the end of a shift, when a new ShiftCalendar start it will trigger the exit method again. the ways of resolution may like this ,in station ""A" define a Variable that record the mu which try exit the...Variable record ) ,if yes then we can quit the exit method use the code "return"
It's probably like you say. What I don't understand is why it happens with the parallellproc, I don't have the same problem with singleprocs. I had a similar workaround like the one you mentioned, but the issue was that in the production the different products circulate between different machines (kind of lika a job-shop), so one product should be able to be in the same machine several times in a row. This makes the condition for when to return quite tricky, so I was hoping there was some easier way to check it.
However, this is not really a problem anymore since I have changed the parallellproc to singleprocs instead. I have not run into any similar problems yet.
Since <some MU>.move returns a boolean value, the best workaround for me was to check whether it actually moved on to its successor with if @.move and take appropriate action when it hadn't.