Processor return pulled operator to list after process finish

Question

question

Adam C asked Dec 1, '21 Joerg Vogel commented Dec 1, '21

Processor return pulled operator to list after process finish

The pull from TE list is useful for getting an operator, but does not return the operator to the list after completing the process. There is also no evident referenced to a pulled operator, with which to return it (on process finish, for example). Is there any such simple method to return the operator to its list on process finish?

I could make it work with process flow / customizing the pull code to store a reference to the operator on a label / operator on resource available trigger, but I am hoping there is a pick list or check box option to handle this. Is there a non-custom way to return the pulled operator when finished? It seems like if there is a built in way to pull one, there would be a built in way to push it back once it is no longer needed.

Software Version:

FlexSim 20.2.3

processor push to list pull from list task executer list

5 |100000

Attachments: Up to 12 attachments (including images) can be used with a maximum of 23.8 MiB each and 47.7 MiB total.

Answer 1 · 2021-12-01T20:12:12Z

Joerg Vogel answered Dec 1, '21 Joerg Vogel commented Dec 1, '21

Default structure is a pair of acquire / release activities to manage resources. Acquire activity acts similar to a list. And release activity push operator to be available again in acquire activity. If you detour from this and work with an own global lists then you depend on custom code to achieve a similar action.

· 2

5 |100000

Attachments: Up to 12 attachments (including images) can be used with a maximum of 23.8 MiB each and 47.7 MiB total.

Adam C commented · Dec 01, 2021 at 09:32 PM

It would be a nice add to be able to do this directly on the fixed resource, since the operator can be pulled that way. It is easy enough to do in process flow, but I was hoping something this simple could be self-contained on the FR without need for any process flow.

0 ·

Joerg Vogel Adam C commented · Dec 01, 2021 at 11:20 PM

@Adam C , it is actually not pullIng an operator. It is more a job you dispatch. This job is collected and a dispatcher transfers it to a task executer. You can dispatch different kinds of jobs. A timetable can create a job to let travel a taskexecuter to a location. You can have a processor which needs an operator to do a setup or assists at processing products. Then this processor creates jobs for this kind of support. These tasks can you interpret as doing a break. A Taskexecuter has got a trigger called On Available, which has got a picklist property to let him go to a location or object. Sometimes you have to imagine what a productive task can be seen as something different.

For example you misuse a processor to let an operator doing his break. The process time is the duration of a Break lesser the travel time. The processor needs an operator for operation. You activate an option to call an operator. You can tell by preempt and priority parameter how a connected operator behaves. If you let him preempt his current job, then he is going into his break right away. If you say the call has got a higher priority than ongoing standard jobs, he will finish his ongoing job and then he is going into his break. Now I describe how you can control the time of this kind of event. A processor will only call an operator for support, if there is an item to process. You simply close the input of the. Processor. If the processor receives a delayed message, the On Message trigger fires and a property is opening the input. An item enters and this causes the call for an operator. On Process Finish you close the input again. You let the currently processed item enter the processor again. You can control breaks by the amount of delay in your message your going to send.

You can do the same in Process Flow.

0 ·

question