Stop token in delay task sequence activity when operator is stopped?

Question

question

Adam C asked May 19 2020 at 9:43 PM Adam C commented May 20 2020 at 5:33 PM

Stop token in delay task sequence activity when operator is stopped?

DelayActivity-StopToken.fsmThis is a simplified concept model, but I have an operator being used for transport and process tasks built in Process Flow. He gets scheduled breaks via a time table. The time table calls stopobject() on the operator, but the activity timer (delay task sequence) does not pause. Functionally, the work continues to "do itself" while the operator is down.

How would I stop progress (the activity timer) until the break is over? I have tried referencing the tokens as contents or subnodes of the activity, but cannot get the references working in order to call Token.stop.

Software Version:

FlexSim 20.0.5

process flow tokens flexsim 20.0.5 delay activity stop tokens

delayactivity-stoptoken.fsm (44.0 KiB)

______

Cookie preferences

Your privacy is important to us and so is an optimal experience. To help us customize information and build applications, we collect data about your use of this site.

May we collect and use your data?

Learn more about the Third Party Services we use and our Privacy Statement.

Strictly necessary – required for our site to work and to provide services to you

These cookies allow us to record your preferences or login information, respond to your requests or fulfill items in your shopping cart.

YES

Improve your experience – allows us to show you what is relevant to you

These cookies enable us to provide enhanced functionality and personalization. They may be set by us or by third party providers whose services we use to deliver information and experiences tailored to you. If you do not allow these cookies, some or all of these services may not be available for you.

YES

NO

Customize your advertising – permits us to offer targeted advertising to you

These cookies collect data about you based on your activities and interests in order to show you relevant ads and to track effectiveness. By collecting this data, the ads you see will be more tailored to your interests. If you do not allow these cookies, you will experience less targeted advertising.

YES

NO

Are you sure you want a less customized experience?

We can access your data only if you select "yes" for the categories on the previous screen. This lets us tailor our marketing so that it's more relevant for you. You can change your settings at any time by visiting our privacy statement

Your experience. Your choice.

We care about your privacy. The data we collect helps us understand how you use our products, what information you might be interested in, and what we can improve to make your engagement with Autodesk more rewarding.

May we collect and use your data to tailor your experience?

Explore the benefits of a customized experience by managing your privacy settings for this site or visit our Privacy Statement to learn more about your options.

Answer 1 · 2020-05-20T04:02:33Z

Matt Long answered May 20 2020 at 4:02 AM Adam C commented May 20 2020 at 5:33 PM

You'll need to use preemption activities to remove the token from the delay task when the object is stopped, wait until the object resumes and then move the token back into the delay task. The preemption activities will store where in the delay time the token was at when it was saved and then starts the delay time back up in the restore context. I've updated your model to show how that would work.

delayactivity-stoptoken.fsm

1589947252779.png (14.5 KiB)

delayactivity-stoptoken.fsm (50.1 KiB)

· 5

Matthew Gillespie ♦♦ commented · May 20 2020 at 2:19 PM

@Matt Long @Adam C You can also use the Token.stop() and Token.resume() flexscript methods to do the same thing without actually having to move the token out of the delay activity.

0 ·

Adam C commented · May 20 2020 at 2:38 PM

It works nicely! In my actual model, this is scaled up where there are many operators, station types, and stations of each type using common process flow "brains" for each. The Operator OnStop triggers for each station (since each station uses the logic), making 10x+ more tokens for evaluation due to duplication. Is there a way to limit this? I can check and throw away duplicates after creation, but I'd rather not make the duplicates at all.

0 ·

Matt Long Adam C commented · May 20 2020 at 3:54 PM

I should note that doing it this way with tasks will cause the delay time to restart. If you want the delay time to resume with the original time remaining, you'll want to either use a Delay activity and set the state of the operator, or when the operator is stopped, you can store off the remaining time so that when you put the token back into the delay task, it uses the updated delay time.

0 ·

Matt Long Adam C commented · May 20 2020 at 4:01 PM

I'm not sure I fully see what you're doing with creating duplicate tokens. If this process flow is suppose to be the brains of each operator, you can use a Task Executer Process Flow and attach the process flow to the operators. That will create an instance of the flow for each operator. Process Flow Instances

You can also use sub flows to keep from duplicating a bunch of activities. Refer to the user manual for more on Sub Flows.

If this doesn't answer your question, feel free to post a new question.

0 ·

Adam C Matt Long commented · May 20 2020 at 5:33 PM

The process flow has 15 attached objects (instances), which are the stations. It's because I was using the operator group OnStop as the triggering event. Each instance fired the trigger, so it made 15x the needed tokens.

The simple solution was to add the stations to the time table for breaks and use current OnStop.

0 ·

question