Referencing the current operator in a processor's code

Question

question

Kathryn McNeal asked Oct 10, '16 Adrian Haws edited Oct 15, '16

Referencing the current operator in a processor's code

What is the syntax to reference the current operator that is serving a processor within the processor's code? We are building a model where each operator has a "Proficiency" label, and are trying to figure out how to access the operator's label in the process time code for the processor.

Software Version:

Choose One

labels operator code

Answer 1 · 2016-10-11T00:53:02Z

Jeff Nordgren answered Oct 11, '16 Adrian Haws edited Oct 15, '16

@Kathryn McNeal

Kathryn,

Attached is a sample model of how I would do that.

I created two User Commands. One called "CallOperator" that is called from the OnEntry trigger of each processor. The Other is "SaveTE" which is called from the OnMessage trigger of each processor.

When a flowitem enters a processor, the CallOperator User Command is called. This command stops the processor, waits for an operator to arrive, starts the processor again, sends a message to the processor (will NULL as the second parameter which defaults to the calling object, which will be the TE). Then in the OnMessage trigger, the SaveTE User Command is called that will save the TE working on that processor to a label "TEid". This will all be done before the process time trigger so you should have access to the TE via the label.

Take a look at the model and see if something like this would work for you. The reason I use the User Commands is so that the code is easily replicated in each processor without having to write processor specific code.

If you have any questions, please let us know.

kathryn-sample1-jn1fsm.fsm

kathryn-sample1-jn1fsm.fsm (21.3 KiB)

· 4

Jon Abbott commented · Oct 14, 2016 at 09:27 PM

@Jeff Nordgren

Jeff, thanks for this example model. This appears to be close to what we need, but unfortunately I'm having some issues with it:

I tried running the model and it works well for the first 927 seconds but then the behavior changes. At that point, operators no longer move around, and Processor2 is able to process items without the need for an operator. I'm using FlexSim 16.2.1.
I looked at all of the processor properties and noticed that the "use Operator(s) for Process" checkboxes aren't enabled. If I do enable them, the output queue at 1,000 seconds becomes much lower (68 vs 218).
When I create a State Gantt for the processors, it shows "waiting for operator" almost always, even when the processor has an operator present.
When applying an MTBF/MTTR to one processor in the example model, it lowers the output of all processors, not just the processor with the MTBF/MTTR.

In our existing model, we have processors that are set to use an operator for setup and processing. After adding the task sequence code from this example, the output is less stable (potentially due to some of the issues above). Do you know if there are any changes that can be made to our model or the task sequence code so that they can work together? We greatly appreciate all of your help.

0 ·

Matt Long Jon Abbott commented · Oct 14, 2016 at 09:44 PM

Here's an updated model. This uses the code from the Task Sequence example in the Pick Operator picklist of the Processor. The issue was due to operators not being properly freed. I removed the code from the OnEntry and OnProcessFinish and allow the Processor to do it's default call operator logic at the place in which it calls the operator.

2966-kathryn-sample1-jn1fsm.fsm

1 ·

2966-kathryn-sample1-jn1fsm.fsm (22.7 KiB)

Jon Abbott Matt Long commented · Oct 14, 2016 at 10:40 PM

Thank you Matt! Your updated model looks like it addresses the issues above.

This is unrelated, but in my testing I did notice a strange behavior if an MTBF/MTTR is set so that a processor is never available. Here are the steps to reproduce it:

Create an MTBF/MTTR with first failure time 0, up time 0 and down time 100.
Assign it to Processor3 so that it is never available.
Run the model.
Note how after 100 seconds, Processor3 receives an item from Queue1 and requests an operator, but doesn't release him due to being perpetually down.

From the event log, it looks like it ends the downtime, opens the input and output ports, receives an item from Queue1, picks an operator and begins another downtime all at time 100. Shouldn't the port open steps (and consequently the receive item and pick operator steps) be skipped if the uptime is 0? I realize this is an edge case so it may not be an issue in practice.

0 ·

Show more comments

Answer 2 · 2016-10-10T22:23:36Z

Regan Blackett answered Oct 10, '16 Kathryn McNeal commented Oct 10, '16

If you are using a single known operator to work with the machine everytime, you can reference it pretty easily by connecting the oprator to the processor using a center port connection and using the expression centerobject(current, x) where x is the center port number through which the operator and processor are connected.

The problem you may end up having with this using the standard Processor, however is that if you are using a team of operators and the assigned operator isn't the same each time the processor goes to process is that the above expression won't work, because the event that assigns an operator doesn't happen until after the Process Time field is evaluated.

The alternative then is use a Process Flow approach to be able to Acquire an operator in such a way that we know which operator the processor has before figuring out how long to delay. I've included a sample model that uses Process Flow to get what I hope you want; using an Instance Template object from the Process Flow Menu in the Toolbox called "Process Flow > Fixed Resource > Processor with Operator" this creates a reusable object and Process Flow set of logic that mimics the standard processor behavior when using an operator with a Process Flow logical backbone.

Note in the Object library that addition of a new Object; this is created automatically when using one of th eProcess Flow template objects:

Give the model a look and let us know if this is what you had in mind.

instance-processor-proficiency-label.fsm

2016-10-10-1624.png (44.7 KiB)

instance-processor-proficiency-label.fsm (35.2 KiB)

· 1

Kathryn McNeal commented · Oct 10, 2016 at 11:08 PM

This seems like it would require a fairly large overhaul of our existing model. I'm still trying to figure out if there is a way to reference the operator. One thought I had is that perhaps the dispatcher or operator could send a message to the operator upon being called to the processor that could send the operator's name to the processor and be stored as a label. Is this possible? I don't have much experience with sending messages in FlexSim yet.

0 ·

Answer 3 · 2016-10-11T14:02:35Z

Matt Long answered Oct 11, '16

You could have the operator who receives the task sequence to work on the machine set a label on the processor. You may need to look at all the different types of task sequences the operator receives, but the following code works just fine for the standard Call Operators task sequence. I placed this code in the operator's OnReceiveTaskSequence, but keep in mind that this code will be called for EVERY task sequence he receives, regardless of when he receives it, which may not be desired.

if (gettasktype(ts, 4) == TASKTYPE_UTILIZE) {
	treenode processor = gettaskinvolved(ts, 4, 2); 
	setlabel(processor, "operator", current); 
}

question