Preempting for machine breakdown

When I was explaining about preempting to a course attendee I made a little model to explain what happens. I didn't use any network, but as an operator uses the defaultnavigator that wouldn't be a problem. To my surprise, the operator does not always walk to the processors to repair it. Sometimes it does, sometimes it just stays where it is and repairs the machine or just moves just a bit. Can anybody explain this behavior?

Martijn

The events of the navigator are not being destroyed correctly when the travel task is aborted. It seems the following line is missing from the aborttravel method of the Navigator class:

destroyeventsofobject(holder, -1, 0, NULL, reqnode);

as this appears to fix the behavior.
Can someone from the dev. team confirm this is the correct fix to the problem? Maybe there's another solution.

Yeah, it looks like Jason's right. We did make a double-check to see if the travel was preempted in the actual execution of the event, but apparently the check isn't good enough in this situation.

Anyway, we'll fix this in the next release.

Hi Jason,

Can you or anybody else explain more on this line of code? Where exactly should I put this line? Where is the aborttravle method of the Navigator class? Thanks.

Hi Alan,

Basically there is an arrival event scheduled for the Navigator relating to a travel request node which is used internally to manage travel tasks. By passing the reqnode, the destroyeventsofobject function only destroys the events for that travel request.

I'd avoid changing anything in the library unless absolutely necessary - any changes need to be saved as a new session and need to be fully compiled. Plus saved sesssions are not updated when a new release of Flexsim is installed so I think having multiple sessions as a user is pretty much discouraged these days. For interest the method is in the cppfunctions node of the Navigator object in the main library of the tree.

Also, it sounds like it will be fixed in 4.5, so if you can wait, that might be the best idea, as I'm still not sure that single line is the best fix. Anthony may be able to tell us if the correct fix was more involved.

If anyone needs a fix in the meantime without creating a new session, it might be possible to destroy the left-over events manually by passing the correct parameters into destroyeventsofobject, but this would need to be tested.