is it possible to track the fwBlockList?
I'm using my "own" PullCtrl within a buffer, to control which object should be processed (FIFO).
tBlock:table; n: integer
“buffer.unblock(tBlock [1,n])” --(n=1 , fwBlockList.ydim>1) ,
the first object should be unblocked an then move to the buffer, but in some cases the second entry disappears and the correspondent object remains on its position.
it might be that the exit control of a previous station move the wrong part to the wrong station.
The method 'unblock' which you use, just inserts a new out event for the part.
If you use an exit control in the station where the part is located you have to have the following:
(demandingStation:object) is do if demandingStation /= void then @.move(demandStation); end; . . . end;
Otherwise it might happen that the part is unblocked by station A and then moved to station B.
Also make sure that you always move the active part (@) in your exit control.
Of course all this assumes that you have an exit control.
In case you don't have one, the model would be helpful to debug what's going on.
w/o a model ( either yours or own redesigned model ) it becomes more or less a guessing, what led to your described scenario.
In these kind of cases and in any cases where there are doubts about the model behaviour I strongly recommend to use the eventdebugger ( s.button in eventcontroller dialog below ).
With the eventdebugger ( no programming ! ) you can easily step through the eventlist and monitor every single computed event.
Once used, the model behaviour should become transparent.
sorry the model is very complex and large, so I can't attach it.
Debugging wasn't successful.
My part (ord:1759) can't move to its destination (self developed modul) by method, because of less capacity, enlists in the fwBlocklist and waits on its "new" out event, triggered by destinations pullctrl.
The pullctrl always unblocks the first entry. But "suddenly" the second entry (ord:1759) disappears without triggering a new out event for correspondent part (ord:1759).
Neither the eventcontroller nor the log file gives an indication of what happens and why.
By now I found a solution for the problem, but no answer to the question.
You you have some waituntil connected with moving parts (esp. with using of @) upstream of this station? This sounds like a supended method wich moves the part (no event - I guess moved by method).
freelance simulation specialist
I allways try to avoid using waituntil-constructs, because of "unmanageable" suspended methods in large models.
I know, why the part doesn't move to its destination, but I can't find out what makes the pullctrl choose the wrong part, respectively choose the right one ( degugging the method) but "take" the second one.