How to get two Operators working on one travel node without overlapping

[kevin.megee]

[ FlexSim 18.1.2 ]

In the attached model, I'm trying to get Operator(s) 1 and 2 to both work on processor one, without overlapping each other. I've tried adding other nodes but they both travel to a single node.

operator-process.fsm

[tanner_p]

Operators are automatically going to travel to the closest node they can in relation to their assigned travel location. In this case, where they're both being utilized by the same object, they will naturally overlap.

I'm not sure there's a simple way to adjust their location in the 3D, but either way, I'm pretty sure it won't affect the outcome of the simulation.

That said, I'm assuming you'd like them to stand next to each other for visual purposes? If that's the case, we can come up with some kind of trigger or use Process Flow to achieve stronger visuals. Let us know what you're thinking. Thanks!

[kevin.megee]

@Tanner Poulton

Thanks for the quick response. Yes, having the operators stand side by side is more for the visual aspect of my model. It will help show that there are two operators "working" on their tasks. I'm not quite as familiar with using the process flow to create models (I'm trying to teach myself) but I'm willing to try that, or the use of triggers to achieve my goal. Thanks again!

[tanner_p]

@Kevin Megee,

This example uses Process Flow to move the second operator to a shape that acts as a station for the 2nd operator (when there is one). I'll go through step-by-step how I created this.

Step 1) Token is created when an operator arrives at NN17.

Step 2) Label on NN17 designated to count operators is incremented by 1 per token.

Step 3) The code seen below is used to adjust the location of the operator to the location of the shape, which is serving as the 2nd operator's "work station."

Step 4) Wait for the processor to finish processing...

Step 5) Lastly, the count of operators held in a label of NN17 is reset to 0 and then the 3D takes over the operators again.

Let me know if this works for you. Hopefully it helps. I've attached an updated model that you can review, too.

18860-operator-process-1.fsm

[tanner_p]

I just realized this isn't quite repeatable yet. Let me work with it and send you an updated version.

[tanner_p · Accepted solution]

18860-operator-process-1-2.fsm

Here's an updated that works for more than the first time. I had to go a different route. Most of what's going on is in Process Flow. The token is created there when the Processor looks for an operator (as shown below)

Once the token is created, the Decide activity in Process Flow will determine whether it's a Setup request or a Processing request. If it's a setup request, the "trigger" label on the token will be 1 and the token will acquire 1 operator, have that operator travel over for setup, then release the operator.

Likewise, for processing, the token will acquire 2 operators, have one travel to the Processor and the other travel to the hidden shape (discussed in previous comment), then release the 2 operators.

Sorry for the confusion. Hopefully this makes some sense, but if you need help or an explanation, feel free to comment back.