Operator Utilized During Fixed Resource Breakdown

Hey All,

I have an issue I’m trying to resolve. I reproduced the problem in a smaller model. See attached. A combiner is set up to breakdown per the MTBF MTTR feature and an operator is on a schedule. The issue is the operator is sometimes “utilized” when the combiner is in the “breakdown” state. The issue only seems to occur when the combiner goes down while an operator is being used. I simply want the operator to be “idle” when the combiner goes into the “breakdown” state. Any simple suggestions?

Thanks,

Ramez

Ramez,

This looks like a tricky problem. I had an idea and modified your little model a bit, but did not solve it in a few minutes. I will still attach my model, to show you what I tried, but I see a lot of issues and further information are needed before making a proper solution.

Here are some of my questions and remarks:
The operator is just set to state idle if the combiner breaks down or do you want the operator be free/idle to also able to do other tasks? This would make it even more complicated.

My idea to solve the task was to use the Down Function and Resume Function of the MTBF/MTTR. I put in the code to identify the utilized operator and set his state to Idle. On Resume I set the state to Utilize. There are several issues. The Event Down Function is only fired once if the combiner goes down. If the operator is in another state but Utilize (e.g. Scheduled Down) he will not set to Idle. Which means, after his state Scheduled Down he will be in Utilize state again and not in Idle state, because the Down Function is not called again. This problem could be solved using other events like in the time table (Down Function and Resume Function similar to my idea in MTBF/MTTR) or use the OnStageChange stuff which will be advanced, but I guess with the normal events it is possible to solve it.
I see additional issues. I think to solve the problem needs a good thinking about the different situation which occurs, etc. Which events happen? Which state the operator should get.

Ramez, I will not try to solve it for now, because I have unfortunately other things to do. But maybe my post is already helpful and gives you some ideas.
Or maybe someone has a better idea for a solution and will post it. Maybe my idea is just a step in the wrong direction and there is an elegant solution.

Wouldn´t it be the easiest way to set the Operator to the breakdown list and not the processor? This way the procesor stops anyway, because of waiting for operator. The state for breakdown operator can be settet, I believe.

If I understand it wright, it had been compromising and with the actually way it´s easier to say, the processor broke down and the worker on the machine repaired it (is included in the repairing process) because otherwise he realy is idle. But only standing still and waiting he wouldn´t do in reality, so he doesn´t in the simulation.

Tom,
Thanks for the help. You’ve given me some things to think about. Unfortunately, however, I do want the operator to be free to perform other tasks while in the “idle” state.

Hemmi,
I appreciate the help, but the attached model is indicative of a problem I’m having in a much bigger model. In the model I’m really trying to fix, I need the operators to go perform other tasks while the equipment is down. In reality, the equipment can go down for up to a couple weeks, hence the importance of freeing the operator.

Thanks again Tom and Hemmi. I’ll keep brainstorming solutions.

rt

maybe, my way is to simple.
I set the transport task of the combiner to a higher priority than the process task and I let the transport task preempt the process task. So the operator breaks away from processing as soon as a transport task is necessary.

To set the operater in the idle state Tom's way seems to be the easiest.

Jörg

I start to build a small model to solve the above task, because I can not get it out of my head.
But now I get back to the old question.
If I use a dispatcher and have operators and use the standard functionality Use operator for process.
How can I identify which operators is assigned to do the process at the specific fixed resource?

I know, that there is the command getutilizedobject() which makes it possible to identify the operator is the is in the state utilize. But if the operator is in the state “Scheduled_Down” or another state, I can not identify him.

I got it working as long as I do not use a time table for the operator, because the operator will be in state utilized. If I use a timetable and the operator is in state Scheduled_Down I have problems to identify him.

I figured out that on the item in the resource in the tree under itemtype the node involved tells which dispatcher is used, but not which operator.

All I need is to figure out which operator is working at which fixed resource. Is this information stored anywhere?

If not, how can I get this information?

Is there a way to figure it out if I would not use the Use operator for process functionality?

My idea was to request the operator by a trigger and free operator by another trigger. I know that I can use the OnProcessFinish trigger to free the operator. But which trigger do I need to use to request the operator (OnEntry if the operator does Setup and Process? And OnSetupFinish if the operator only does the process?). And if I request the operator manually, will Flexsim works internally correct e.g. not starting the process before the operator arrives at the fixed resource?
But I think, if this all will work, I still have problems to identify the operator because the Dispatcher will take care of it, right?

Do I need to make a function, to search through all the operators, to find a free one and make the tasksequence manually? This sounds advanced and I wonder if there would be an easier way.

Internal Flexsim needs to have this information, because the operator is set to free after the process is finished. I had a look into the C Code, but can not figure out how it is working.

I hope I do not overlook something but I can not find a way to identify the operator.

Any suggestions?

getutilizedobject() looks at the dispatcher's team members' tasks to see if they are TASKTYPE_UTILIZE for the specified item and station. The actual state of the task executer won't affect the returned result. So I don't think you need to code the search and match algorithm yourself. If multiple operators are used the utilizednr parameter lets you choose which one you want a reference for.


To allocate and release process operators yourself, you'd put the code on the PickOperator picklist entry - which gets called for 4 cases (see the multiple teams example):
PICK_OPERATOR_PROCESS: your chance to allocate - but must return -1 to tell flexsim to call again with the PROCESS_RELEASE case
PICK_OPERATOR_SETUP:
PICK_OPERATOR_PROCESS_RELEASE: your chance to release the operator.
PICK_OPERATOR_SETUP_RELEASE:

If you don't use the requestoperators() function then you'll need to stop the object multiple times (with the id 100002 and the state WAITING_FOR_OPERATOR) for the number of operators you are requesting and then use something similar to the standard task sequence like this (from the calloperators function) :

#define OPERATOR_STOP_ID 100002
treenode newts = createemptytasksequence(dispatcher, priority, preempt);
inserttask(newts, TASKTYPE_MILESTONE, NULL, NULL, 3);
inserttask(newts, TASKTYPE_TRAVEL, current, NULL, -1);
inserttask(newts, TASKTYPE_STOPREQUESTFINISH, current, NULL, 0, OPERATOR_STOP_ID);
inserttask(newts, TASKTYPE_UTILIZE, item, current);
dispatchtasksequence(newts);

If you use freeoperators() when the object breaks down, then this task will finish and you'd have to dispatch another when the breakdown finished. If you preempt and recycle this sequence you'll need to change the range of the milestone. You'll also need to re-stop the station. Update: This last sentence didn't feel right and it isn't - see post below.

I neater solution might be to put the delay and process finish events on the operator's task (which alone would need further investigation) and then preempt him when the station breaks - catch the task through his output port, and reissue it when the station is repaired. Not thought that through completely but it might have some legs.

If you need to register the task executer(s) yourself then just get them to call a nodefunction and leave the involved2 in the task blank - the task executer will populate that with a pointer to itself which you can then reference in the function as parnode(1) and store in a variable or label.

Jason,

First of all, thank you for your reply and I can imagine, that it took you quite some time and effort.

I guess, I did not explain in an understandable way what I already did and what already worked. Hopefully I can do it better in the future, but keep in mind, that I am not a native English speaker. Maybe some confusion is based on this fact.

Anyway, I will give you some feedback. I think you explanation is good, even if I already used some of the stuff.

I tried getutilizedobject() and as you explain in your post, you can identify an operator in a utilize state. This is working and works if the operator is in utilize state. My issue is, that the operator follows a time table, therefore he could also be in the state SCHEDULED_DOWN. If the is in this state, I can not identify him.
So if there would be a command like getstateobject() where you can define the state you are looking for as a parameter in the command, this would be the solution. I could search for UTILIZE but also for SCHEDULED_DOWN and any other state.
This would solve my problem.

By the way, I hope the developers read this thread and might get some ideas how to improve the software, commands, etc. if you have tasks like this.


Yes, it is a good idea to use the PickOperator to allocate and release process operators. Better solution than using OnEntry/OnProcess Finsih. That’s a nice hint! And it shows me that I start to forget things in Flexsim. L
But it will unfortunately not solve my problem, because the dispatcher will still decide which operator will do the job and I still did not get this information.


I thought, I knew which tasksequence is used, at requestoperators(), but it is different to yours. But you said, that your tasksequence is similar to the standard one, so that’s explains the differences.
This is what I found in my own Flexsim knowledge base:

REQUEST OPERATOR TASKSEQUENCE


OnPickOperator:
// STOP OBJECT (COULD ALSO BE DONE IN ONENTRY OR PROCESS TIME)
stopobject(current, STATE_WAITING_FOR_OPERATOR);
// REQUEST OPERATOR: Own Tasksequence
// CREATE EMPTY TASKSEQEUNCE
treenode taskexecuter = centerobject(current,1);
treenode ts = createemptytasksequence(taskexecuter,0,0);
// INSERT TASKS
inserttask(ts,TASKTYPE_MILESTONE,NULL,NULL,4);
inserttask(ts,TASKTYPE_TRAVEL,current,NULL);
inserttask(ts,TASKTYPE_STOPREQUESTFINISH,current,N ULL,0,tonum(current));
inserttask(ts,TASKTYPE_SENDMESSAGE,current,NULL,0, 0,0,0);
inserttask(ts,TASKTYPE_UTILIZE,item,current);
// DISPATCH TASKSEQEUNCE
dispatchtasksequence(ts);

ATTENTION:
..........
Take care of stop and resume object and on the state to get right statistics.
The operator also needs to set free.

OnMessage:
// MESSAGE FROM THE TASKSEQUENCE
// RESUME OBJECT
resumeobject(current);
// SET STATE OF OBJECT
setstate(current,STATE_PROCESSING);

OnProcessFinish:
// FREE OPERATOR
freeoperators(centerobject(current, 1),item);

I did not know about the ID 100002 stuff. This is interesting and I really learned something new here. Great! I put your comments and code in my knowledge base. Thanks for it.

If I have a look into my code and your suggestion and I thought there could be a solution. Using a task setnodenum or sendmessage to set a label on the fixed resource to the operator’s id. But again, I do now know how to reference to the operator. When I create the task sequence it is not clear which operator will get the tasksequence. Again the old problem or is there a way to figure out the id of the operator if the tasksequence is executed and not when it is created?


Sounds like your hint with the operator calling a nodefunction is the way to go.
I give it a try and it works. That was what I was looking for. Thank you so much!

I still think it would be a nice feature, if Flexsim would store the information which operators are used/allocated at a fixed resource somewhere. Or having a command which is able to figure this out like getutilizedobject() but not limited to only the state utilized. But I like the first solution (getting access to the information directly) much better.


Anyway, Jason thanks again for your support, which I really appreciate. And I am sure that Ramez will also appreciate it, because it helps me to build a model which hopefully helps him. I will post the model if I have it finished it and I hope I have now everything I need to do this. But it looks good now. I just need some time to finish the model.

Hi Tom,

Sorry I misunderstood some of your post.

I thought I'd better check the business of re-stopping the station when you pre-empt the operator since I thought 'this surely is standard functionality', and it is. Preempting an active UTILIZE task where the involved2 is set to the station will automatically stop the station. Like you say, I also seem to have forgotten some things I haven't used for a while. Now to to keep the operator free when the machine breaks, I'd catch the preempted task sequence through the output port of the operator since it only works with PREEMPT_ONLY. If you use PREEMPT AND ABORT it will not stop the station (as far as I can tell). Otherwise if the task sequence is still in his tasksequence queue, he'll just pick it up again.

I also had a look into this before you posted your questions as I realized there seemed to be no easy or automatic option for this, but it makes sense that we might want to release a process operator while the station is being fixed. I started building a test model too but so far haven't completed it. If I do I will also post it here.

Jason,

Thanks again for your post and your help.

I finished my model and I guess I struggle a bit about what you just explained in your last post. The handling of the tasksequences and the preempt were the reasons why it took me some time to finish my model.
I checked my model and in my eyes it is working, but I do not guarantee that. So who ever will use the model or the code should check if the model is working as expected.

This model was really tricky and I guess it is really advance stuff. I hope it is of any help for Ramez.

Here is the link to the model: Sample_FreeOperatorDuringFixedResourceBreakdown_TD

Jason, I am looking forward to see your solution, because I hope there will be an easier way than the way I went.

Hello,

as far as I understood the problem of a preempted utilize task is, that the task is queued up in the dispatcher and there exists no reference to the operator, which has originally executed the task.

If I build a pair of an operator and his very own dispatcher, every preempted task will be queued up in his own dispatcher. There I can query all the stored tasksequences, e.g. for an specific item or a station. The nice effect is, that the operator recives one of of the stored tasksequences of his own dispatcher before any other dispatcher can send a tasksequence.
Any other dispatcher is linked with the operator directly.

Jörg

I interpreted the problem statement as 'how to free a process operator when the station breaks down' - I don't think the solution needs to assume that the same operator would complete the task, and so can use the standard dispatcher technique to find an available operator (which may turn out to be the same one). When I get a chance I'll put another version together (unless someone beats me to it) - Tom I noticed a few triggers in your model that, between them, seem to contain redundancy, so we will hopefully be able to simplify it.

Thanks for the help. What y’all came up with is very impressive! (I think I understand everything, but it may be a little over my head J) I’m looking at Tom’s model now. It seems like it could work. Thanks Tom! I’ll try incorporating it into my model.

Jörg, Good tip about the dispatcher. However, I’m not sure this would help this model. Like Jason said, the operator simply needs to become available to perform other tasks.

If Tom’s model doesn’t work, I may have to cut my losses and re-examine the problem statement. There may be assumptions I can make that simply the problem.

Thanks again!

rt

I uploaded this once already and deleted it because I found a bug. I hope I've covered it this time. I'm not sure this solution any simpler overall - I think that depends on your point of view and experience.

I've added some Extras which are not needed in order to work:
1) changed the timetable code to send the operator to the 'home' network node near the OffShift text when he is scheduled down
2) added code to the Operator (message and OnAvailable triggers) to send him to the Available text when idle
3) set the operator to alternate on and off shift every 15 minutes starting at 8:15


There are 3 regular 'triggers' which call two nodefunctions.
1) MTBF Down Function
2) MTBF Resume Function
3) Processor 'PickOperator'

I've put the nodefunctions in the labels area of the processor:
1) 'startbreakdown' - called by MTBF DownFunction if there is a UTILIZE task
2) 'calloperator' - called by the 'PickOperator' code and the MTBF ResumeFunction if the state is WaitingForOperator.

The current UTILIZE task is stored in a special label called currentTS, which gets created with the correct datatype if it doesn't exist. These three labels could be relocated to the variables area with the appropriate code changes.

If you could assume the breakdowns only occured during the Processing state I think it could be made simpler.

As Tom also indicated - please test it thoroughly to convince yourself it does what you need before adopting this technique. If you find problems post them here and I'll see if I can solve them.

Jason,
Jörg,

Coming back to your posts and if the same operator should finish the process.
I thought about it and this can be done in my model by changing the code in the Resume function of the MTBF/MTTR. Changing the pointer to the Dispatcher into a pointer to the Operator directly which is now possible, because I have the information about the Operator in the label on the Combiner. This should work, even if I did not test it.

But I like Jörg’s idea to use a number of Dispatcher instead of only one. I can see scenarios where this might be really useful. The only downside I see is that in the PickOperator the code needs to be changed from centerobject(current,1) to all Dispatcher. This might be not a big deal, but is some extra effort.

Jason,

I like to come back to your post about redundancy in some triggers of my model.

This is in a way right, but if you have a closer look, you might notice that the code has different pointers. I hope we speak about the same code. I know that you could still use a UserCommand or a NodeFunction with some parameters.
But I did not do this, because I try to keep my SampleModels “simple”. The idea of the models is to help people to understand how to solve a specific problem. Hopefully the models do this in an easy and understandable way. If I would use advance techniques I think it would less understandable even if it would sometimes a more elegant way. And I see UserCommands and for sure Nodefunctions going in the direction of advance stuff.
Sometimes it is difficult to keep the models simple, because the task is tricky and you might need to use some advance stuff.

That’s why I don’t like the solution with calling a nodefunction to identify the operator. This is in my eyes advanced stuff and it would be nice to get access to this information in an easier way, like I said in an earlier post. Maybe the developers have a good idea how to make this easier.

By the way, I also see the whole preempt stuff also in a way as advanced. Okay, here is no way around, if you want to do advance stuff, like Ramze needs to do. I am glad, that Flexsim is here so flexible and makes it possible to do such stuff. But flexible means in some cases that it is a bit more effort and more advanced to do such things. At least this is how I see the world.

Jason, I will have a look into your model and will give you feedback later about it. I am looking forward to see your solution.

Tom,
I think my version has a vulnerability in using the state to decide if the operator should be called when resuming from a failure. There probably needs to be another flag to be set to indicate that the processor is processing.

As far as the 'redundancy' goes, I meant that I thought the Flexsim standard behaviour could handle more of the tasks for stopping and resuming the station.

I agree about trying to keep things simple, and the concepts in my version are harder for most - partly due to a lack of commands to easily access couplings etc., and a nice interface for adding functions onto objects. Having said that the forum should help newcomers and experienced users alike, so I think there's a place for both levels.

I guess what this problem really needs is a checkbox or something that says 'release process operator when not processing'.

Jason,

I had a look into your model and I like to give you some feedback.

What I always find interesting, but which is not important for the functionality, is that it seems that nobody but me (which is not true) organize the tree and give the objects names which speak for themselves. I found out for myself that this helps to understand the model and makes debugging easier. If I see names like VisualTool13, VisualTool14 and VisualTool16 I get confused.

I know that I put a lot of comments in the code and sometimes it seems too much it helps others and me to understand the model. For sure if I have a look into the model weeks later.
That all my models have a description might be another thing I prefer to do. But again, if I sometime look at models I build a year ago, I am so happy to have the description.

Yes, it is some effort and time consuming, but my experience is, that it pays off in the end. It makes the model more understandable and easier to debug.

Speak about debugging a model. I find it interesting that Jason uses a distribution in the Source. I prefer in some cases and that’s what I did in my model solution for this thread using fixed times. Using fixed times makes it easier possible to tell what will happen in the model at which point in time.
This made it possible in my model to find that I had a bug in the process time calculation after a breakdown. That’s also why I changed my code in an above thread. I am pretty sure, that I did not have found this bug, if I would have not known that the Operator needs 2 seconds to arrive at the machine and the remaining process time is 20 seconds. When he arrived and started the process the ProcessFinish Event was in 22 seconds and not in 20 seconds. My calculation was wrong here because I added his travel time.
So what I am trying to say is that I use fixed time for my model to make the verification and validation easier in my eyes. After I have the feeling everything is working, I might change to times which follow a distribution just to have more different situation in my model for testing, which I might not have covered manually (with the fixed times).

Sorry for going a bit off topic but I thought here is a nice place to give you some of my ideas I have if I build Sample Models. As you know, I build these models for support reasons or if I like to figure out which concept I should use in my project model.

Anyway, I come back to Jason model now. Jason, I hope, I did not offend you with my above thoughts. But I am sure you know how to take feedback. I see feedback as room for improvement and the feedback I don’t like, I just forget. J

The model looks really interesting and it uses some “advanced” stuff. I see that some of the stuff is an elegant way but maybe makes bits a bit more complicated to understand. But if you get it, it is just another good way to go.

I like the idea of using a coupling node as a reference to the current tasksquence. I did not use coupling a lot in the past but this is a nice example on using it. Great!

I have questions here. You use nodepoint() to set the pointer. The manual advises to use nodejoin() instead because it has automatic pointer management. If I understand it right, you use nodepoint(), because you want to set the pointer manually and do not need an automatic pointer on the other side, right?

This coupling is also be a way to figure out where is the tasksequence in the moment in other words to figure out which taskexecuter is used.

Jason, you gave me now a second way to figure out which taskexecuter is used. I like both ways. Hopefully this helps the developer to think about a nice and easy solution to put into Flexsim.

Identify the operator with the coupling node is what you using in the NodeFunction startbreakdown. Again a nice idea to check if the ownerobject is a taskexecuter, has the tasksequence and only stop him if in Utilize task. I think I understand your main idea now much better, even if you explain it in your post.

I tested your model for the issue with the process time I had in my model (with fixed times ), but it seems to work in your model. I know that my issue was based on my calculation, but I still wanted to check it. But Flexsim can better calculate than me, which is good.

It is really nice to see another solution for this task. I will not try to judge which way is easier or better. I think there is no easier or better way. It is just as you said in your post it depends on what a user prefers.
Ramez has now the invidious job to decide which way he likes to go.

Jason, thanks for sharing your model and I learned a lot. Good job!


I just saw your previous post.
I agree that here is some room to improve Flexsim. I like the idea of having a checkbox to release operator. But it would also nice to have access to the used taskexecuter to be more flexible.
And yes, you are right, the forum is a place for all level of users. That’s why I like our discussion about this task. There are so many things to learn in Flexsim.

Thanks for the feedback Tom.

I believe the nodepoint functionality is acceptable for use in version5 - I've done some small testing and found it is NULL/0 when an object is destroyed so I think it's being managed automatically now (Anthony and Phil feel free to slap me if I'm wrong!). The task sequences get recycled I think (I don't know where to) and so that's why I test if they have a valid ownerobject. Also note that because they move around we have to use findownerobject() instead of ownerobject(). Previously we'd have needed a coupling to store a link to another node, which in this case would then create a node within the task sequence at the task level which would I expect cause problems, or destroy the data on the node if joined directly, so nodepoint now allows us to get around that.

As for the distribution on the source - it's a good idea to have a first step where everything is deterministic. Noted and not forgotten! Then the really important part for using the distribution is of course that repeat streams is then switched on so that problems you detect can be repeated and debugged.

I had a quick look at adding an operator for the repair process - since I knew this would require me to add a processing flag which I'd check on the MTBFResumeFunction. It looks like that isn't as straight forward as I expected either, as the standard template for using operators isn't consistent with the method I've used for detecting the Resume - in fact it bypasses the resumefunction by default. So it looks like there's some further editing of that DownFunction required. Oh well..!

hi, i read the thread and all models,a good thread, i learn a lot from this thread, i think some advance stuff is necessary,i learn flexsim just one year,i think i can understand jason's model.in the begin i think flexsim have a lot of secret, just because i do not know some advance stuff ,but i come here ,i Unlock many secrets. and i think if you learn more advance stuff , you will use flexsim more well and understand more correctly.so i want to learn more advance stuff .thank you tom ,you share a lot of experience in here,i also learn a lot from you.