How to control a sub line queue from overloading after main line has objects sent to rejects and main line triggers sub line source

Question

question

Justin Brozzo asked Aug 3, '16 Sam Stubbs edited Aug 3, '16

How to control a sub line queue from overloading after main line has objects sent to rejects and main line triggers sub line source

pflexsimnewpractice-identifiers.fsm @Matthew Gillespie @Sam Stubbs

So, I have a main line that has a sub line that is triggered when objects pass through certain processors. My goal is to control the sub line queue from overloading when the main line objects are sent to rejects.

What I am looking for:

1. When a reject is sent from the main line to the main line reject sink, I am looking to trigger the already connected main line source with the same item type that was sent to rejects...

2. Then, I am looking for the sub line to check if there is already the right number of matching objects created in the sub line and create one if one is needed or not create one if there is already one that it can match that it can use.

I am really open to the easiest way this can be done, or open to ideas if you think there would be a better way to control this, without using queue max content.

Thanks!

Here is a link to my previous question:

https://answers.flexsim.com/questions/25732/how-to-create-a-object-identifier-number-without-u.html#answer-25737

Here is the model we were using earlier and I would like to use as a mock model:

Software Version:

FlexSim 16.1.0

queue content

pflexsimnewpractice-identifiers.fsm (19.6 KiB)

Answer 1 · 2016-08-03T17:35:26Z

Sam Stubbs answered Aug 3, '16 Sam Stubbs edited Aug 3, '16

So I was able to accomplish this by first making a Reject Queue before the rejects go on to the sink. (By default the Reject Queue will have it's output closed OnReset, and closes again after an item exits, OnExit)

In the code on the OnCreation Trigger on the mainline, I added an if statement that checks the content of the Reject Queue, if there are any objects in the reject queue it will remake that object instead of assigning the random itemtype. Then it sets a label on the item created designating it as a "remake" and opens the Reject Queue, allowing the item to go to the sink.

Once the item passes the first processor. I added another if statement around the code on the OnExit trigger, checking if the item coming through is NOT a remake. If the item is NOT a remake, then it will execute its trigger to open the second line port, creating the other half of the object.

I've reattached your model with the updates I made. You can look at the code and see how I did it.

justinexample-1.fsm

justinexample-1.fsm (20.7 KiB)

question