question

We were able to troubleshoot this problem over the phone, so here is the answer for anybody else looking.

The Problem:

The issue is the Processor is using a Pull Strategy to pull items from a list. If there isn't anything on the list when the Processor goes to pull something, a back order is created. If there is a back order when the Processor is stopped, and an item is then added to the list, then the back order is fulfilled and the item is pushed to the Processor - despite the Processor being stopped. The item won't be processed, but the Processor does start the setup and processing events, which sets the state of the Processor to processing for the duration of the down time. And there could be other issues just like if you were to use a Move Object activity in Process Flow to move an item to a stopped object.

If you look at the uploaded example model (StoppedObject_PullFromList_Example.fsm), the issue is shown in the top example with Processor1. The left block of activities in the Process Flow is what creates the boxes in Queue1. Queue1 then pushes the boxes onto ItemList1, and Processor1 pulls items off of the list in its Pull Strategy.

Solution:

One way I have found to fix this is to set up an Expression Field in the list that keeps track of if the Processor is available or if it is down. Then, you can use the Query in the Pull from List to only pull items when the Processor is available. You will also need to set up a Back Order Reevaluation Event on the list to look at the Processor's (the Puller) OnResume event. Without the reevaluation event, any items that are pushed onto the list during the Processor's down time won't immediately get pulled off of the list when the Processor finishes its down time. Normally, back orders are reevaluated when something gets pushed to the list, but using the OnResume as a reevaluation event means the items can start processing as soon as the Processor finishes its down time.

In the example model, the bottom example (with Processor2) shows an example with this solution. This time, Queue3 and Processor2 utilize ItemList2, and the right block of activities in the Process Flow is creating the boxes in Queue3. You will also find an Expression Field in ItemList2 named "isPullerAvailable". It is set to be a Dynamic field, and it uses this line of code:

getvarnum(puller, "nrofstops") == 0

This is a modified example taken from the following Answers post:

https://answers.flexsim.com/questions/81126/checking-object-status-flex-script.html

You will also find this query in Processor2's Pull Strategy that utilizes the isPullerAvailable field:

WHERE isPullerAvailable = 1

So items will only get pulled off the list if the Processor has not been stopped.

As a note, it doesn't matter how you're stopping the Processor or how items get pushed onto the list for this issue to appear. You can stop the Processor with an MTBF/MTTR or with Process Flow. And you can push items onto the List using Process Flow. In any case, the issue will still appear.