topic Auxilary tasks in FlexSim Forum

Auxilary tasks

luis_rodrigues — Thu, 04 Jul 2024 15:03:10 GMT

[ FlexSim 24.1.0 ]

Hi, I'm working on a model in which the transports have a main task to do, which is loading the queues to que "ML", but they have also some auxilary tasks that take a certain percentage of the total time (24h).

(For example)

The MC1 takes 10,28% of time and later I have made this logic:

I just want someone to confirm is this is correct (I don't remember why I putted 300 😞

mlall-4.fsm

Re: Auxilary tasks

FelixMoehlmann — Fri, 05 Jul 2024 05:59:57 GMT

Every 300/0.1028 seconds a transporter is occupied for 300s, resulting in a usage rate of 300/(300/0.1028) = 0.1028 = 10.28%. So yes, it's correct. Though the 300 is not set in strone. You could of course also do more shorter tasks or fewer longer ones. Always change both the DelayTime label and the time of the second row in tandem to keep the usage rate the same.

Re: Auxilary tasks

luis_rodrigues — Fri, 05 Jul 2024 08:20:14 GMT

Thank you @Felix Möhlmann for your answer.

I have another question, beside those auxiliary tasks I also have tasks like changing the battery of the forklift that takes 0,20% of global time for some random forklifts, how can I do this since in the other tasks I have defined only one forklift for each.

Re: Auxilary tasks

FelixMoehlmann — Fri, 05 Jul 2024 09:16:02 GMT

Looking into the model a bit more I found some issues with the auxiliary flow. You should not be using separate resources to acquire the transporters. Doing so would allow two tokens to give tasks to the transporter at the same time. Since both resource representing the transporter can be acquired at the same time. Use the same resource that contains all transporters and specify which transporter to use in the Query field.

The delay should also be adjusted to take into account the travel time to get to the object in question, so the whole task sequence does actually take up 300s. For this I would only run through the Sub Flow once.

See changes I made to the MC1 process.

mlall-4_1.fsm

You can use the same technique for shared tasks by creating a token for each transporter. Though then I would stagger the start times of the task and not have them all happen at the same time.

Re: Auxilary tasks

Jeanette_Fullmer — Mon, 08 Jul 2024 16:57:59 GMT

Hi @luis-rodrigues, was Felix Möhlmann's answer helpful? If so, please click the "Accept" button at the bottom of their answer. Or if you still have questions, add a comment and we'll continue the conversation.

If we haven't heard back from you within 3 business days we'll auto-accept an answer, but you can always comment back to reopen your question.

Re: Auxilary tasks

luis_rodrigues — Mon, 22 Jul 2024 13:04:03 GMT

Hi @Felix Möhlmann sorry for the delay on aswering, I was on vacation.

I didn't understand the picture you sent. I opened the file you sent and in the mc1 only has this:

What should I do to make this work?

I also didn't understand what you mean with "run through the Sub Flow once" and then "stagger the start times"

Hope you can help me

Re: Auxilary tasks

FelixMoehlmann — Mon, 22 Jul 2024 13:27:31 GMT

The changes in the screenshot are not in the attached model. It shows an example of how you can use a single Source/Flow to have all transporters to the same auxilary task. By staggering I mean not having all transporter to the task at the same time. That is what the "Offset" label accomplishes. After the source then token should enter a delay that holds it for the time given in "Offset". For example, let's assume that the task should be done every 3000s and there are 15 transporters. With the settings as in the screenshot, the first would do the task after 100s, the second at 300s, the third at 500s and so on.

The changes that are part of the model is that the Acquire activity does connect to the resource that represents the entire group of transporters and which one gets acquired is determined by the "TransToAcquire" label. This is to prevent two tokens being able to acquire the same transporter at the same time (once through the main resource and once through a separate resource).

Previously, the sub flow was run once for each created item and the travel time was not part of the overall time taken. Taking the travel time into account is easier when the token only runs through the sub flow once.

Delay task previously: Half the delay time * two runs = Delay time without travel

Delay task now: Delay time - time taken to reach the position

Re: Auxilary tasks

luis_rodrigues — Mon, 22 Jul 2024 15:34:49 GMT

Okay I think I got it, so I should do like this: (example of changing the batteries)

But when I run it doesn't go through the "pull from list"

Re: Auxilary tasks

FelixMoehlmann — Mon, 22 Jul 2024 16:07:08 GMT

Eveything looks correct in the screenshot. If the token gets stuck in the Pull from List then make sure that the created item is being pushed to the list and that the partitions match.

(Does this task even need items or would it be enough for the transporter to drive to some location and delay for a time. You wouldn't need the "Create Object", "Pull from List" and "Destroy Object" activities then)

Re: Auxilary tasks

luis_rodrigues — Mon, 22 Jul 2024 19:45:03 GMT

You are right I don't need to create objects, my bad.

Now I have a question about the state of the transporters.

Can I use this states I've defined earlier instead of the "51"?

mlall-4-1 (1).fsm

Re: Auxilary tasks

FelixMoehlmann — Tue, 23 Jul 2024 06:00:14 GMT

Sure. Since this is a custom state profile you also won't need the structure that sets the state through a message, because the default logic will never change this profile. You can thus use the "Set Object State" option of the custom code activity.

The following would set the custom profile to the "Take Empty" state.

Note that both states (default and custom) will exist in parallel and the statistics panel in the object properties will always show the state of the default profile. In dashboard charts you can choose which profile is used.

Re: Auxilary tasks

luis_rodrigues — Tue, 23 Jul 2024 11:21:06 GMT

Thank you for your answer. So for example on the "MC1" I should do like this:

In the first code I should put the state 5 that is "mc1" and in the second code I should put o that is "other"?

Re: Auxilary tasks

FelixMoehlmann — Tue, 23 Jul 2024 11:32:42 GMT

Yes to the first part, no to the second. You can't actually use the 0th state (at least not with the "setState()" method). Only 1 and up.

Re: Auxilary tasks

luis_rodrigues — Tue, 23 Jul 2024 11:55:19 GMT

@Felix Möhlmann So I should just take off the second code?

Re: Auxilary tasks

FelixMoehlmann — Tue, 23 Jul 2024 13:51:11 GMT

Depends on what you want to achieve. If the state should stay as "MC1" remove the second activity. If not, choose a state other than 0.

Re: Auxilary tasks

luis_rodrigues — Tue, 23 Jul 2024 15:11:19 GMT

@Felix Möhlmann in the state profile from the chart I'm not getting the "state profile 1":

mlall-4-1 (1).fsm

Re: Auxilary tasks

FelixMoehlmann — Tue, 23 Jul 2024 15:42:20 GMT

MultiProcessor States is the name of the profile as you can also see in your screenshot from earlier. It is the first profile under the "state_profiles" node, so when refering to it by rank, as in "setState()", you use a 1. The chart properties show the name instead.

Re: Auxilary tasks

luis_rodrigues — Tue, 23 Jul 2024 16:25:41 GMT

In the "Dealy" feature how can I get the states that I defined?

Re: Auxilary tasks

FelixMoehlmann — Tue, 23 Jul 2024 16:28:59 GMT

You can't. The delay task can only change the default profile. You have the change other profiles separately (before the token enters the Delay task activity).

Re: Auxilary tasks

luis_rodrigues — Tue, 23 Jul 2024 16:32:12 GMT

So for example, in this I make it "state 13" and when it goes to the delay it won't change to "state 50" ?