Close port

Hi,

In my model , I generate 3 box types of diferent colors. Each box type is connected with the conveyor by different ports. For instance:
red box - port 1
green box - port 2
blue box - port 3
When a green box arrive to the conveyor, I want to block the port 2 (in order to not entry more green boxes to the conveyor, until the green box leave the conveyor). The same for the other types.

Thank's.

I uploaded de model.

Set the max content of the conveyor to 1.

Originally Posted by Anthony Timmiss

Set the max content of the conveyor to 1.

Hi,

That is not a good solution .

I would need to know how to block a port.

In addition, the conveyor can be boxes of different colors.

Try using the entry and exit triggers of the conveyor to close and open the input port if the box is coloured green.

Originally Posted by Anthony Timmiss

Try using the entry and exit triggers of the conveyor to close and open the input port if the box is coloured green.

Have you seen the model I uploaded?

In the model that I uploaded, I used the triggers of the conveyor but I don't get what I want.

The problem I see is that you trying to control the input ports with the command closeip(). I always teach in my training classes, that you not should use this commands on the standard library objects, because the objects normally have their own logic to control the ports. That’s why there are commands for close and open the objects (closeinput(), openinput(), etc.).
So in this sense it is a tricky problem to solve.
My solution would be to use three queue (each for every item type) and control the output of the queues.
If there are reasons only to have one queue, I guess it is tricky to solve with the standard queue. You could make your own queue starting from a BasicFR. That’s another way to solve it, I guess.

Another solution could be to use an Input Pull strategy on the Flow tab where you need to make your own pull requirement. I did not try it yet, but you could do something like store the information which item type is already on the conveyor (e.g. labels) and use the labels to define which items can still be pulled. I guess the downside here might be that you need to reevaluate the pull requirement (speed reasons).

These are my first ideas, but maybe someone has better ones.

I change your little model because I wanted to figure out if I was right with my last post and the Pull Requirement. I got it working, but I was wrong with the Reeavaluate and the Pull requirement. It was still not working (which is clear, if I think about it), so it a bit tricky (here I was right).
Anyway, I solved it by forcing and event with delayed message and use a “trick” in the OnMessage trigger (stopobject() and resumeobject()).
And I learned something new, that I can use stopobject() and resumeobject() to reevaluate stuff on objects. But I guess still have the speed issue in focus if you using such stuff.
I am not sure if this is a good solution, but at least it seems to work. :-)
See the attached model where code is in OnReset, OnMessage, OnEntry, OnExit and Pull Requirement.

I still like the idea with three queues much more, but like said, I wanted to try the Pull Requirement.

Apologies, I hadn't looked at the model (I have now). It sounded more simple than it actually is. I would use 3 queues as suggested by Tom if I was trying to solve this problem and create a global table to count each type in and out of the conveyor. You would then be able to use this data in the future if you wanted to control the flow of the other item types.

It sure seems like you guys are making this question a lot more complicated than it is.

Attached is a model where all the logic is in the pull requirement. It is a custom code pull requirement to "Pull only itemtypes that are not in the conveyor".

The only bit of complication is that OnExit it sends a delayed message in 0 time to call openinput() to refire the pull logic after each item has left the conveyor.

Originally Posted by Phil BoBo

It sure seems like you guys are making this question a lot more complicated than it is.

Attached is a model where all the logic is in the pull requirement. It is a custom code pull requirement to "Pull only itemtypes that are not in the conveyor".

The only bit of complication is that OnExit it sends a delayed message in 0 time to call openinput() to refire the pull logic after each item has left the conveyor.

thanks Anthony, Tom and Phil for your help and interest in my model.

I served much of your examples. Now continue building my model.

Phil,

I guess this is what the forum is all about. Share ideas and discuss solutions.
Yes, your solution is very nice and clean. I am happy to see that I was right that there is a tricky bit to refire the pull logic after each items has left the conveyor. I like your solution by using openinput(). In a way, I did the same, but indirect, by using stopobject() and resumeobject(). I checked it in my model to use openinput() and it works too. Thanks for this idea and information.
And thanks to Juan Alberto who brought up this little interesting assignment.

Phil's solution is very simple and shows how powerful the Pull Requirment can be. During my training I believe that not enough time was spent looking at this option, its certainly something I have not used much with Flexsim. In other packages, pulling parts from queues is the only way as the queues don't usually have the ability to push items out as they do in Flexsim.

I have altered Phil's example slightly so that only the green boxes are restricted.

Originally Posted by Tom David

The problem I see is that you trying to control the input ports with the command closeip(). I always teach in my training classes, that you not should use this commands on the standard library objects, because the objects normally have their own logic to control the ports. That’s why there are commands for close and open the objects (closeinput(), openinput(), etc.).
So in this sense it is a tricky problem to solve.
My solution would be to use three queue (each for every item type) and control the output of the queues.
If there are reasons only to have one queue, I guess it is tricky to solve with the standard queue. You could make your own queue starting from a BasicFR. That’s another way to solve it, I guess.

Another solution could be to use an Input Pull strategy on the Flow tab where you need to make your own pull requirement. I did not try it yet, but you could do something like store the information which item type is already on the conveyor (e.g. labels) and use the labels to define which items can still be pulled. I guess the downside here might be that you need to reevaluate the pull requirement (speed reasons).

These are my first ideas, but maybe someone has better ones.

Hi,

How could you do the same to block the entry of items, but now using networknodes?

in the model there are 3 types of flowitems:

measure <6 -> go to node 2 (NN2).
measure> = 6 & & measure <11 -> go to node 3 (NN3).
measure> 11 -> go to node 4 (NN4).

For instance:

If one item its meassure <6 ( will go to node 2), arrive to processor, and there is another item in the node 2, the processor block to that item and let the other items.

This for three case.

Thank's.

In a way, I am a little bit surprised about your questions, because you already got the hints in this thread.
Anyway, have a look into my attached model. But I am pretty sure, that you do not want the Processor to block, but maybe the Queue. But this is only a thought.

Originally Posted by Tom David

In a way, I am a little bit surprised about your questions, because you already got the hints in this thread.
Anyway, have a look into my attached model. But I am pretty sure, that you do not want the Processor to block, but maybe the Queue. But this is only a thought.

Sorry Tom, you're right, I want to block the queue.

I will do some tests.

Thank's.