Jump to content
Simio Forum

Emptying global request queue


Recommended Posts

This should be a simple answer... hopefully.


I remember reading somewhere on the forums something about the global request queue (can't find it again for the life of me), but I can't remember if you can simply just clear it.


Was there a way to do this?

Link to post
Share on other sites
  • 4 months later...

I don't think I solved this one. I think I worked around it by making better logic to ensure that sure I didn't get into dead-locks in the first place.


It is kind of awkward to do a looping find and remove on the AllocationQueue over many transporters before every seize in the model just to try and keep synchronicity between different levels of nested models that can't directly see each other.


The downside with messing with the allocation queue (by either removing or only seizing when conditions are ideal), is that you can't generate any kind of Gantt chart to see what is SPECIFICALLY constrained.


I think I put this in the too hard basket.

Link to post
Share on other sites

Hey dude...


I also don't think you get the seize of the transporter 100%...As strange as this sounds...The transporter seizes itself....it is not seized by the entity...only allocated as a next destination of the entity....dont get confused....(",)


Its also not a normal seize as you would expect...


Mark

Link to post
Share on other sites

I was using entities to seize transporters as they entered servers, I then abstracted these chains of servers into sub-models, and then sub-models of these sub-models such that I could re-arrange and order these chains easily, and so I could have 12 or so of these long chains encapsulated in single objects that sit in the top level model where the transporters and entities start.


When the entity enters one of these servers, it is added into the allocation queue for the transporter (I might be referring to the token... but for all intents and purpose it is the entity as these tokens are created and destroyed), you can verify this by clicking on a transporter and drawing a queue for its AllocationQueue and hovering your mouse over what turns up inside it.


My problem stemmed from all of these asynchronous requests hitting the transporters making them all deadlock due to the ordering of the allocation queue. I ended up making proper expressions to evaluate these queues and also expression to avoid the extra seizes until they absolutely had to be made.

Link to post
Share on other sites

Aah...Okay and I hope some of the Simio support reads this...


I had the EXACT problem...I eventually had to use a combiner where the parent entity would summon/seize the transporter to the output node of the combiner...Only then would the amount of child entities be specified as each transporter was associated with a different weight capacity (number of entities)...


If you have a look at the latest simbit updates you would find an watered down example of this problem in there...


Long and the short of it...I canned the idea, used a transporter with a tank and rewrote the routing and seize logic such that the transporter dictates decision making and routing logic instead of the entities trying to dictate what the transporter does and where it goes via selection rules...


I have an example for you if you like...

Link to post
Share on other sites
×
×
  • Create New...