Auxilary tasks

[luis_rodrigues]

[ 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

[moehlmann_fe · Accepted solution]

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.

[luis_rodrigues]

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.

[moehlmann_fe]

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.

[Jeanette_Fullmer]

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.

[luis_rodrigues]

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

[moehlmann_fe]

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

[luis_rodrigues]

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"

[moehlmann_fe]

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)

[luis_rodrigues]

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

[moehlmann_fe]

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.

[luis_rodrigues]

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"?

[moehlmann_fe]

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.

[luis_rodrigues]

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

[moehlmann_fe]

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.

[luis_rodrigues]

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

mlall-4-1 (1).fsm

[moehlmann_fe]

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.

[luis_rodrigues]

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

[moehlmann_fe]

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).

[luis_rodrigues]

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