question

Shuo Zhang avatar image
0 Likes"
Shuo Zhang asked Isaac Litster commented

Open/close port command failed

Hello!

I put open/close port command to control the content of queue after a createflowitem command in my model (Sink2&Queue2, Sink3&Label, Sink4&Cases, Sink5&Pallets). The model can do what I wanted in the first 3000s but after that it messed up with the close and open port command for some reason. Can you help me to figure out why is that please? And also if there is other ways could control the content of queue under a createflowitem situation?

Thanks in advance!warehouse-simulation-v01.fsm

FlexSim 17.0.3
closeinputopeninputcreateflowitem
· 2
5 |100000

Up to 12 attachments (including images) can be used with a maximum of 23.8 MiB each and 47.7 MiB total.

David Seo avatar image David Seo commented ·

Your model running is good, OK over 6000 secs several times.

It does not show any error message?

0 Likes 0 ·
Shuo Zhang avatar image Shuo Zhang David Seo commented ·

Hi David - Thanks for your response. Yes, the model won't give any error message. But around 5000 secs, the model will be doing something different from what it doing before. The input of Sink3 is closed shown in red(meaning closed not by coding I think). And that stops transporters to deliver item to the line.

0 Likes 0 ·
capture.jpg (99.1 KiB)

1 Answer

·
Logan Gold avatar image
1 Like"
Logan Gold answered Isaac Litster commented

You might need to give some more details before someone can fully answer your question, but it looks like the issue is with the timing of when a Sink closes its input ports versus when the destination of the boxes on the Racks are determined.

For example, it's possible that more than one Transporter will be in transport to a given Sink at one time. So one Transporter might deliver a box to the Sink and the message is sent to one of the nearby Queues to create a number of flowitems in that Queue. And when the condition is met, that Queue will close the Sink's input ports.

However, it's possible a second Transporter could already be on its way to the same Sink when the first Transporter drops off its box. That means the second Transporter will still deliver its box to the Sink even if the Sink's input ports are closed during that delivery time.

In fact, if one of the upstream Racks has already fired its Send To Port logic and picked that Sink before the Sink's input ports are closed, a Transporter will still come pick up the box and deliver it to the Sink even if the input ports are closed during the process. Closing the input ports on the Sink will only affect new boxes that are trying to leave a Rack when they cause the Rack's Send To Port logic to fire.

I'm not too sure what you should do to fix the issue. The tricky thing is trying to control an upstream object using transports with a downstream object's OnEntry trigger. If you executed the logic that is currently in the Queue's OnEntry trigger earlier in the process, but don't create the flowitems in the Queue until the box reaches the Sink, that would give you more control.

You would have to do it after a box's destination Sink is determined on a Rack, but before a transport is requested. So you could use dummy Queues between the Racks and Sinks to perform the necessary logic in their OnEntry triggers and more the "Use Transport" logic from the Racks to the dummy Queues.

You could also try using Process Flow and Lists to handle the logic as well as the transportation. You would need to rework the model a little bit, but I don't think it will take too much effort.

· 4
5 |100000

Up to 12 attachments (including images) can be used with a maximum of 23.8 MiB each and 47.7 MiB total.

Shuo Zhang avatar image Shuo Zhang commented ·

Thanks for the help Logan! But the thing I am really trying to figure out is when the content of Label is less than 800, why the input of Sink3 (current.centerObjects[1]) still can't be opened?

Thanks!

0 Likes 0 ·
picture1.png (1.3 MiB)
Logan Gold avatar image Logan Gold ♦♦ Shuo Zhang commented ·
@Shuo Zhang, Sink3's input ports do open when the content of the Label Queue is less than 800. My testing shows this works at time 2712.55 and time 3712.55.

In the picture you added, the content of the Queue is still at 1433 at time 3077.87. If you were to run the model to time 3712.55, you would see the Queue go from a content of 800 to 799 and the OnExit trigger would cause the Sink's input ports to open.

0 Likes 0 ·
Shuo Zhang avatar image Shuo Zhang Logan Gold ♦♦ commented ·

@Logan Gold Sorry I should have used a clearer picture. You are right, the current content of Label Queue is still more than 800. The input of Sink3 is supposed to be closed at the moment. But I think it should be closed by the close port command, so the arrow should be still green while with a red line beneath it like what happens to other sinks in the following pictures. But in this case it shows a red arrow instead.

Based on a previous post Green and red input port symbol, the red arrow actually means the port is considered closed by Flexsim for some reason. And I guess that is the reason my open input command will eventually fail when the content of Label Queue do less than 800. So I am thinking if we could figure out why Flexsim consider the input port of Sink2 to be closed in this case, we could pretty much solve my problem.

Thanks!

0 Likes 0 ·
1.jpg (119.0 KiB)
2.jpg (146.5 KiB)
5.jpg (190.5 KiB)
Show more comments

Write an Answer

Hint: Notify or tag a user in this post by typing @username.

Up to 12 attachments (including images) can be used with a maximum of 23.8 MiB each and 47.7 MiB total.