currently I am working similar to this model having operators and queues. I am trying to create a new dispatcher logic based on shortest distance. But in my logic the shortest distance should be between processor 1 (in diagram) and the operators unlike the conventional way(ie.shortest distance between source/queue and operators).can anyone please suggest how to code this new logic
Here is an example model (operatorshortestdistancetoitemdestination-example.fsm) of what you are asking for.
I set the Dispatcher's Pass To logic to be "Pass to the object closest to the destination if available". As you mention, the destination described here is the pickup location - or Queue1 in the example. So I opened the code for this option and changed line 10 (I also changed line 3, but that is just a comment/description) so that the Dispatcher will use the dropoff location as the destination when comparing distances.
When using an Operator for transport, the default task sequence used by Fixed Resources (including Queues) has two Travel tasks mixed in with some other tasks (load, unload, etc.). The first Travel task is what tells the Operator to travel to the pickup location. The second (and last) Travel task tells the Operator to travel to the dropoff location (after picking up the flowitem of course).
So normally, Line 10 looks at the first task in a task sequence and iterates through all the tasks to find the first Travel task. I changed it so it would begin looking at the last task in the task sequence and work its way backward so it will find the second Travel task. Making this change means the destination we are measuring distances with is Processor1 in our example model.
The example model should show the closest Operator to Processor1 will be the Operator to handle the task sequence if they are available. If the closest Operator is not available, it will go to the next closest Operator. If all Operators are not available, it will go to the first available Operator.
I think I'm missing some details here because I believe I can tell you exactly what would happen in your model as you have it set up in the graphic you sent. If you successfully implement the logic you describe, Operator2 would be the first operator to take a flowitem to the processor. Operator2 would also be the next operator to carry a flowitem to the processor. In fact, Operator2 would be the only operator that would ever be used. Why? Because when Operator2 drops off the flowitem at the processor, they would remain in their last position, close to the processor. Then when the processor calls for another flowitem, guess who is closest to the processor, that's right, Operator2, and would always be the closest to the processor.
So I think I'm missing something about why you would want to implement such logic in the first place. Are the operators called by numerous other tasks that would take them out of their current positions? If you have a working model or working sample model of what scenario would use this type of logic in the dispatcher, that would help me, at least, understand what you are trying to accomplish. Would that be possible to send in a model with an expanded explanation of what needs to happen.
6 People are following this question.
FlexSim can help you understand and improve any system or process. Transform your existing data into accurate predictions.
FlexSim is a fully 3D simulation software environment. FlexSim can be used to simulate any process in any industry.
FlexSim®, FlexSim Healthcare™, Problem Solved.®, the FlexSim logo, the FlexSim X-mark, and the FlexSim Healthcare logo with stylized Caduceus mark are trademarks of FlexSim Software Products, Inc. All rights reserved.
