Restore Context and assigning a new delay time

Question

question

Jason Botha asked Oct 12, '16 Michael O'Connell commented Feb 1, '17

Restore Context and assigning a new delay time

So i am building a manufacturing process where i want to stop the production during a lunch break and then have the process continue from where it left off. This is where preemption works perfectly. (i am using the parent child relationship which makes it super easy as well)

Anyway, i have the added complexity of wanting to change the delay time during the lunch break, but the delay doesn't seem to pick this change up. The delay activity is based on a label that i update during the lunch break. However when the restore context activity is hit, the token goes back to the delay but keeps the original label time and not the updated time.

I know this is because the save context activity store the tokens information before i change the label but i was wondering if there is a way to let the delay re-evaluate the time it needs to delay the token for while taking the new delay label into account?

I have attached the small model i built to test this concept.

Thanks

Software Version:

FlexSim 16.2.0

preemption

preemption-test-model.fsm (16.3 KiB)

5 |100000

Attachments: Up to 12 attachments (including images) can be used with a maximum of 23.8 MiB each and 47.7 MiB total.

Answer 1 · 2016-10-12T16:45:55Z

Matthew Gillespie answered Oct 12, '16 Michael O'Connell commented Feb 1, '17

When you save the context it saves what activity it's in and info about what the token was doing, the remaining process time for the delay in this case. When you restore the context it sets the delay time to the saved remaining process time and no longer uses the original label. Here are 2 ways to achieve what you want to do:

Release the Token

Rather than restore the context, release the token back to the activity stored by saving the context. This way the token reenters the activity and the label is reevaluated. Here's an example.

Save Context Checkpoint

Rather than saving the context of the token inside the delay. Have the token go through the save context right before it hits the delay. That way the save context becomes a "checkpoint" right before the delay where the token is restored to. The delay time will be reevaluated since it will reenter the activity. Here's an example.

preemption-release.fsm (16.6 KiB)

preemption-checkpoint.fsm (16.4 KiB)

· 5

5 |100000

Attachments: Up to 12 attachments (including images) can be used with a maximum of 23.8 MiB each and 47.7 MiB total.

Jason Botha commented · Oct 13, 2016 at 07:30 AM

Hey Matthew,

Thanks for the answer.

0 ·

Jason Botha commented · Oct 13, 2016 at 07:45 AM

Mathew,

Is there a way for me to access the following information:

node-data-access.png

Then i can calculate how much time i have already spent processing the token before i removed it from the delay.

0 ·

node-data-access.png (35.7 KiB)

Matthew Gillespie ♦♦ Jason Botha commented · Oct 13, 2016 at 09:46 PM

Jason,

Querying that data would be exposing the internal data structure of the save context. This data is not meant to be user accessible and we strongly discourage you from trying to use it. The reason being that there is no guarantee the data structure will remain the same in the future.

What you should do is set a label to the current time when the token starts the delay and then when you preempt it you can calculate how long the token was in the delay for.

0 ·

Jason Botha Matthew Gillespie ♦♦ commented · Oct 14, 2016 at 05:10 AM

Hey Mathew,

Thanks that's a much better idea.

Have a good day further

0 ·

Show more comments

question