Process Flow Acquiring Busy 3D Model Operator

Question

question

Stan Davis asked Nov 2, '16 Matthew Gillespie edited Apr 12, '18

Process Flow Acquiring Busy 3D Model Operator

process-flow-acquiring-travel-loaded-3d-operator.gif process-flow-acquiring-busy-operator-02nov16.fsm

Scenario: I am attempting to model a testing process where two resources are consumed at the same time. For this process, an electronic assembly is placed on a test fixture and connected to a test console. No other items can be placed on the test fixture and during testing, no other items can consume the test console. Failure rates will eventually be modeled for both the test fixture and test console. After testing on the Test Fixture, the electronic assembly is then sent to a Burn In Console for processing and then subsequently sent back to the Test Fixture for additional testing.

Model Construction:

Using BasicFRs for the Test Fixture and Burn In Console and a BasicTE for the Test Console.
"Basic Processor" Process flows are called during OnEntry events for the Test Fixture (TestFixturePF) and the Burn In Console (BurnInConsolePF).
The process flows acquire operators and, if needed, a test console prior to processing.
Operation times and required resources are determined by querying a global table in subflows that are called by the Process Flows.
Routing is controlled in the 3D model using custom code in the "Send To Port" that evaluates the next required resource.

Problem: When testing with multiple flow items, I have discovered the Test Fixture's Process Flow will acquire an operator whose state is "busy" or "travel loaded" in the 3D model (see attached pic). I am assuming that since I am directly referencing the Operator in the "acquire resource" activity, the state of the Operator is being evaluated at the time of the request. Why is this not the case??

That real challenge here is trying to understand how coupled/decoupled a Process Flow and the 3D model are under various scenarios.

-- Thanks Stan

Software Version:

FlexSim 16.2.0

process flow acquire resource

process-flow-acquiring-travel-loaded-3d-operator.gif (123.5 KiB)

process-flow-acquiring-busy-operator-02nov16.fsm (64.8 KiB)

· 1

3d print F commented · Apr 12, 2018 at 08:32 PM

@Stan Davis How did you solve at the end? I would like to start a similar project

0 ·

Answer 1 · 2016-11-02T18:12:32Z

Sam Stubbs answered Nov 2, '16 Stan Davis commented Nov 2, '16

Based on your description, I think that perhaps you're looking at this in the wrong angle. You're basically trying to control the whole system's flow, by using an instanced Process Flow of the TestFixture. Rather than do that, I would approach your problem differently. I would create a General Process Flow, and control the whole logic of the system itself with process flow. (Get rid of all port connections and logic on the fixed resources, etc.) Then just create and control the flow of items, the acquiring of the operator and the task sequences (both transportation and the test fixture stuff) all within a single General Process Flow. That would give you full control over how and when the Operator is utilized (using the Acquire resource.) Because as it stands now, your 3D model is assigning Task Sequences to your operator, and then your Acquire activity is getting him as a reference, and just directly giving him tasks that way. (The Acquire resource activity is really to be used to limit other Process Flow activities from acquiring the same resource/object. It's not really looking at the already assigned Task Sequences given to him by the other Fixed Resource objects.)

Alternatively, you COULD technically assign all of the Travel, Setup, etc etc tasks into a single task sequence instead, and then assign THAT to him using the create Task Sequence activity. But this would only assign that Task Sequence to him, and he'd still just complete the Task Sequences in whatever order is on his list. So you'd have to use priorities etc etc to control the "how" and "when" those Task Sequences would be executed. I feel that this would be a much more complicated route to take with your model however.

Again, based on how you described your model, and the control you're looking for, I would HIGHLY recommend converting the logic of the system to a singular General Process Flow. Which would give you full control over how objects are moved/transported processed, and in which order. And within this single Process Flow you COULD use the Acquire Resource to limit how and when tasks are executed by your operator (or operators if you add more to the system.)

I hope I was able to add some clarity to the situation. Did this help any?

· 1

Stan Davis commented · Nov 02, 2016 at 06:56 PM

I appreciate the time on the phone. Thanks for helping me understand what is going in with my current model and the best potential solutions going forward. Thanks again.

0 ·

Answer 2 · 2016-11-02T17:09:51Z

Matt Long answered Nov 2, '16 Stan Davis commented Nov 2, '16

When you are using a Resource in Process Flow to acquire and release operators, it does not look at the operators state at all. It's up to you as the modeler to determine when a Resource is available or not. If you have multiple processes acquiring a resource, then you should use a shared Resource between them such that the Resource is not being utilized by two processes at the same time.

This is similar to the way Fixed Resource objects work. Process Flow is happy to move flowitems into a Processor or Queue at any time whether or not the Processor/Queue is busy or has space for the flowitem. You are given ultimate flexibility within process flow to control those objects.

You can look at it as having 3 different ways of modeling.

1. You can model everything in 3D and allow the objects to use their logic to move flowitems and call operators etc.

2. You can integrate process flow into the 3D by having the 3D objects kick off tokens in a process flow to perform additional logic. Or alternatively, you can use Event-Triggered Sources and Wait for Events to listen to events happening on the 3D objects and then perform whatever steps are necessary in the process flow.

3. You can control all of your model's logic within process flow and use the 3D to graphically show what's going on. Using travel tasks and conveyors you can easily take into account travel times based upon distances etc.

Of course you can use any combination of the above methods to do your modeling. Hopefully this helps.

· 3

Stan Davis commented · Nov 02, 2016 at 06:09 PM

Per the question and the attachment, it can be seen I am using the integrated approach with event-triggered sources and I am using a shared resource. If the acquire does not look at the referenced object's 3D state, the what is the point of referencing the object in the first place and/or how does one determine its state in this scenario? Then what is to prevent the 3D model from acquiring the 3D resource that was 'acquired' in a Process Flow? It appears you need to control operators completely within the 3D model or within a process flow(s), but not both. Any specific responses are appreciated. Thanks.

0 ·

Matt Long Stan Davis commented · Nov 02, 2016 at 06:27 PM

There are a few things you can do. For one, you could acquire the resource then check to see if the resource is currently in the middle of a task sequence. If it is, move the token to a Wait for Event that is waiting for the OnResourceAvailable trigger to fire on the operator, at which point you could decide if you should jump in and start utilizing the resource.

As for keeping the 3D mobel from using a resource that the process flow is using, it's important to understand how the task sequence activities work. If you use travel, load, unload etc tasks on their own, then each activity is issuing a new task sequence with one task in it. This allows other task sequences to "butt in" and tell the operator to do some other work that may not be what you want. You can use the Create Task Sequence activity to prevent that. It will create a task sequence, and then each task activity will append their tasks to the task sequence, ensuring that no one butts in line.

Now if have points in which there are breaks and the operator no longer has tasks to do, but you want to make sure the 3D doesn't pull your operator away until the process flow is done with it, then this can be accomplished through the Custom Task activity. Under the Task Type property, select the last item in the list which is Wait For Task. This will tell the task sequence to not finish once it completes all of its tasks, but to instead wait until it receives another task. This will cause the operator to wait indefinitely until you give them another travel or other task.

1 ·

Stan Davis Matt Long commented · Nov 02, 2016 at 06:49 PM

That's what I needed to know. Very helpful. Thank you!

0 ·

question