ATTENTIONThis FlexSim Community Forum is read-only. Please post any new questions, ideas, or discussions to our new community (we call it Answers) at https://answers.flexsim.com/. Our new Question & Answer site brings a modern, mobile-friendly interface and more focus on getting answers quickly. There are a few differences between how our new Q&A community works vs. a classic, threaded-conversation-style forum like the one below, so be sure to read our Answers Best Practices. |
flexsim.com |
#1
|
|||
|
|||
Operators getting stuck in utilize state for ever
I am having this issue in my model. I call in operators using a custom task-sequence and then after the task is done I free them at the processfinish trigger on the multiprocessor. For a while everything seems to be working fine but soon the operators get stuck in utilize state forever. I am not able to debug because thanks to some issue with flexsim in windows 8 I cant go to event log > Deselect (this is where flexsim crashes)>select a particular operator and see what went wrong with it. Is there some other way to understand why this is happening.
This is strange because it runs fine for a while and then gets to this point.. I have attached the model for anyone to see what is going wrong with it..Or let me know if there is a way I can debug it myself |
#2
|
||||
|
||||
Hello arjun,
have you something special on your mind to call freeoperators on port number 1 or 2 of your centerobjects at the multiprocessors? You have connected at your multiprocessors only port number 1. The freeoperator command isn't executed on port number 2. If you don't mind to connect all your taskexecuter, which can be freed, to another dispatcher, then you send your freeoperator commands to that dispatcher. The right taskexecuter is chosen by your item reference and you don't have to decide which port to use to free a taskexecuter. The next step would be to create a global variable of type tree node to the freeing dispatcher. Then you can copy the command where ever you need it. Joerg |
#3
|
|||
|
|||
Hello Joerg
Thanks for your quick response, I really appreciate it. Sorry for the long post that follows but I feel the need to explain you as to what I am trying to model and how it is supposed to work. If you saw my model, you would observed that the operators are all nurses and they answer calls from different beds. The reason I have the other freeoperators command (for centerport 2 which does not exist in this mode) is that in the next iteration of this model I have to add in Doctors (another set of operators that will be connected to port 2) as well. So I wrote the code beforehand and later I will simply connect the center port 2 to another dispatcher (and update the number of operators required for the concerned processes from 0 to 1) that will be connected to 2 operators called Doctors. The way I wanted it to work is this: Beds are grouped into clusters and each cluster shares either 1 or two nurses. Bed 3-9 are connected to Monitor A Dispatcher which is connected to 2 nurses Bed 10-16 to Monitor B Dispatcher which again is connected to two nurses. Bed 17 to 20 and then Bed 21-25 are connected to Treatment and MTA dispatchers respectively each of which has one nurse. If you look at the multiprocessor the processes are in the order: Call nurse > Initial Nurse assessment > Call Doctor > Initial Doctor assessment> Wait time 1 > Nurse Assessment > Doctor Assessment > Wait time 2. The ones in bold are the ones need operators in this model. For the first 2 clusters i.e. Beds connected to Monitor A and B respectively the multiprocessor is supposed to call nurses at the "Call nurse" process utilize them till the end of Initial Nurse assessment and then free them. Since the dispatcher Monitor A is connected to the first center port hence the command if (opnum == 2) return freeoperators(centerobject(current,1),item); is run at the processfinish trigger in order to free the nurses. Now the need of the model is that the same nurse should be called in again at the start of the 6th Process called Nurse Assessment and should be freed at the end of it and hence the command if (opnum == 6) return freeoperators(centerobject(current,1),item); Similarly in the next iteration of the model the Doctors will be called at the Call doctor process and remain utilized till Initial Doctor assessment and will be freed and then called again at the 7th process and freed again. I dont know if it matters for the sake of this question but I will still let you know that the same item (read patient) might be routed back to the multiprocessor at the end of last process. If the patient is coming on the bed for the second or third or nth time the first 5 processes (the ones that are underlined above are supposed to be completed once per patient) will be bypassed ( by setting the process time 0 if loop >0) and the patient would only need to go through process 6 , 7, 8 and will need to call same nurse (the one which he called the very first time he came on the bed) at the start of process 6 called Nurse assessment and bed will free that nurse at the end of the process. Same case will be for Doctors if and when they are added. What I got from your suggestion was that I should attach all the nurses which are currently attached to different dispatchers to another single dispatcher which would then be connected to the center port of all the Beds and I should run the freeoperator command on that Dispatcher only. I did not exactly get what you mean by "The next step would be to create a global variable of type tree node to the freeing dispatcher. Then you can copy the command where ever you need it." as I have not used g;obal variables yet. I kind of get what you want me to do but I am not able to get as to how that will solve my problem. The first question though remains why is this happening at the first place (that after a while the operators go into utilize state forever even when I am running freeoperator command after each of the processes that the operators are called for) |
#4
|
|||
|
|||
SOLUTION FOUND
I am not sure how many people are following my post but if do follow this.. IGNORE THE PREVIOUS POST from me as its too long and you will get lost in it.
The only reason the operators were stuck was that I had written the stoprequestbegin task in the task-sequence itself. Now as long as the operators are free to receive task sequences immediately this works fine. But as soon as the task-sequences pile up for an operator the multiprocessor runs the pick operator trigger > sends the request to dispatcher >since the dispatcher has now piled up the TS the stoprequestbegin task is not run immediately and multiprocessor carries on with its work and plays the next trigger (since it was never stopped) .. Later in the model run when the TS is finally attended by the operator the multiprocessor has already done its job.. the operator still does what it was asked to do..travels to the bed sends message and gets utilized.. but since the multiprocessor has already run its course and is in some other state so the freeoperators command is not executed at all... In nutshell if your TS get piled up then the timing of triggers on the Multiprocessor and the TS gets spoiled resulting in messed up model.. So the stopobject command should always be run outside the task-sequence. i.e dont the operator to stop the processor as he will only do it when he gets time.. Ask the processor to stop itself and then let it be resumed by the operator whenever he gets time to process the TS request.. Feel free to post questions.. I have messed up with my model in several different ways and might be of some help in telling what does not work.. |
The Following User Says Thank You to mearjun For This Useful Post: | ||
Jörg Vogel (12-04-2012) |
Thread | Thread Starter | Forum | Replies | Last Post |
Tasktype Utilize | Martijn van Oostenbrugge | Gripes and Goodies | 0 | 09-29-2011 07:03 AM |
How to determine special state of conveyor? | zhang xin | Q&A | 6 | 11-03-2009 06:13 AM |
Setting Custom State | Francois Perron | Q&A | 1 | 04-06-2009 02:37 AM |
GUI State Graph | Anthony Timmiss | Q&A | 6 | 01-26-2009 02:30 AM |
State Waiting for Operator | Nico Zahn | Q&A | 6 | 01-15-2009 09:00 AM |