Jump to content

Wait step with timeout


jdoran

Recommended Posts

Is it possible to implement a wait step that either waits for a specified time, or for an event to be fired (which ever comes first).


I hacked together a model where I execute a process before the wait step, that delays for the time and fires an event. I then simply listen for either event at the wait step.


I don't think this is very neat. Is there a better way?


I can see there are timer elements, but I don't see how you would invoke one simply to act as a countdown.

Link to comment
Share on other sites

What about having a separate process that contains an execute step, which is triggered by a timer...


The execute step would call the process which you want, which is triggered by a firing an event ??


Not pretty but effective, I am sitting in the same boat...

Link to comment
Share on other sites

I dont recall making a variable timer being an easy thing to do. I believe they required their own state variable.


It will make the code harder to read and debug too.


I currently execute side processes with delays that fire events. This is even worse in some ways as it makes multiple tokens that then need to be handled.

Link to comment
Share on other sites

I can catch you on skype to show you for I have various timers performing different things....


One example would be where I have priority based maintenance...i.e...Shutdown...Planned...Breakdown....each running off of their respective timers...As these activities timers can overlap as they form part of their own unique distributions, events are fired based on the priority constraint to allocate the transporter a different state...The logic involves correctly disposing of the tokens in a wait state of the previous constraint process as well as resetting and adjusting the timers....i.e....If I am on breakdown and scheduled maintenance hits, then the schedule maintenance process is executed and Breakdown processes stopped or delayed until a corresponding event is fired....this includes material handling assignments, crew, etc....


Another example would be dynamic generation of "demand" transporters based on a varying monthly rate dictated by variations in supply due to statistical randomly generated constraints... The timer is adjusted based on a change in arrival rate which is calculated and dynamically updated to ensure that there is always just enough demand for current available supply...This forms part of optimized planning for bulk carriers which cost a hell of a lot of money if they are just chilling in the ocean...


But ultimately and perhaps the crown jewel is handling flow transfers from one transporter to another...since i had developed the logic before this super awesome new release of the transporter library, I needed events to check when the load or discharge level had been reached, or the full or empty state of the flowcontainer had been reached on either transporter, or objects fired events which needed to seize loading/discharging and stay, or seize loading/discharging and move away, as well as handle inherent timers on the transporter for breakdowns that will execute different processes depending on the type of breakdown....i.e. move the transporter or stay put... :shock:


It all sounds really complex but its very simple....


Hit me up on skype...

  • Like 1
Link to comment
Share on other sites

  • 1 month later...

1) Add a Timer element. Initially Disabled. Specify the Maximum Events = 1 and the Time Offset as a variable (or the constant time if that is the situation).

2) In the process with the Wait step, right before the Wait, assign the Enabled state of the Timer to True to start it up.

3) In the Wait step, wait for either your primary event, or the Timer event, whichever occurs first.


No need for a second process. Just a combination of a Timer and a Wait step, with the Timer's event being one of the possible events that the Token may be waiting for.

Link to comment
Share on other sites

So each wait step would require a state/property, a timer and two assign blocks. It's simpler than making the re-usable process with passed tokens, and probably more durable.


Thanks. I'll have to go back and update my models, and keep it in mind in the future.

Link to comment
Share on other sites

×
×
  • Create New...