ATTENTION

This FlexSim Community Forum is read-only. Please post any new questions, ideas, or discussions to our new community (we call it Answers) at https://answers.flexsim.com/. Our new Question & Answer site brings a modern, mobile-friendly interface and more focus on getting answers quickly. There are a few differences between how our new Q&A community works vs. a classic, threaded-conversation-style forum like the one below, so be sure to read our Answers Best Practices.


flexsim.com

Go Back   FlexSim Community Forum > FlexSim Software > Q&A
Downloads

Q&A Using Flexsim and building models

  #1  
Old 08-09-2007
Jeff Nordgren's Avatar
Jeff Nordgren Jeff Nordgren is offline
Technical Support Manager
 
Join Date: Jul 2007
Location: Orem, UT
Posts: 65
Downloads: 79
Uploads: 0
Thanks: 40
Thanked 21 Times in 17 Posts
Rep Power: 233
Jeff Nordgren is just really niceJeff Nordgren is just really niceJeff Nordgren is just really niceJeff Nordgren is just really nice
Default Queue Sorting

Quote:
Hello,

I noticed this issue in a much bigger model and replicated it in a very small scale with the following sample model (Sorting_Problem_Capture). If you run the sample model, the following events will happen:
  • I create 5 flowitems (one every second) and assign them a label named "rank_no". The first flowitem has a "rank_no" of 5, the second one is assigned 4 etc...
  • I accumulate them in a queue (by using "closeoutput" command at "OnReset" logic for the queue) and sort them in a descending order within the queue as they come in.
  • When the 5th flowitem arrives in the queue, the command "openoutput" is executed and the flowitems go to a processor.
  • I expect to see the flowitem with "rank_no = 1" to be processed first, but that is not the case. "rank_no = 2" is processed first, then "rank_no = 1". The rest are correctly sorted.
This is important within the large-scale model I am working on. Can you please let me know why this is the case and how it can be fixed. Please try not to change the flow logic within the sample model drastically.

Thanks in advance and best regards, Goksin
The problem with your model seems to be a problem in a lot of models. What you are doing on the queue is opening the output port of the queue in the OnEntry trigger. You should NEVER, repeat NEVER open or close input/output ports in the OnEntry or OnExit triggers! Goksin, I'm not trying to be hard on you, just trying to make a point for all those who will read this post in the future. The way to accomplish this is to send yourself (same object) a delayed message in zero time and then in the OnMessage trigger, do your opening/closing of ports. I've attached a model (Sorting_Problem_Capture_FS1) to show this is all it takes. This is basically the only change I made to your model. And as you can see by running the model, it fixes the problem.
Attached Files
File Type: zip Sorting_Problem_Capture.zip (42.5 KB, 408 views)
File Type: zip Sorting_Problem_Capture_FS1.zip (42.9 KB, 408 views)
__________________
Jeff
Flexsim Support
  #2  
Old 08-10-2007
AlanZhang's Avatar
AlanZhang AlanZhang is offline
Flexsim Super Moderator
 
Join Date: Aug 2007
Location: CA
Posts: 289
Downloads: 64
Uploads: 0
Thanks: 88
Thanked 91 Times in 47 Posts
Rep Power: 225
AlanZhang is a jewel in the roughAlanZhang is a jewel in the roughAlanZhang is a jewel in the rough
Default

Quote:
Originally Posted by Jeff Nordgren View Post
... You should NEVER, repeat NEVER open or close input/output ports in the OnEntry or OnExit triggers! ...
Could you please further explain this issue? Is there any particular reason for this? Is it Ok if we close/open ports of some other objects (not current) in these two triggers?

Thanks.
Alan
  #3  
Old 08-11-2007
Jeff Nordgren's Avatar
Jeff Nordgren Jeff Nordgren is offline
Technical Support Manager
 
Join Date: Jul 2007
Location: Orem, UT
Posts: 65
Downloads: 79
Uploads: 0
Thanks: 40
Thanked 21 Times in 17 Posts
Rep Power: 233
Jeff Nordgren is just really niceJeff Nordgren is just really niceJeff Nordgren is just really niceJeff Nordgren is just really nice
Default

Quote:
I was wondering if you've had a chance to study the section regarding a FixedResource in the Flexsim Manual. It's a great way to understand the common functionality of fixed resources. How they work "under the hood" sort of speak.

One point that's probably not mentioned in there is the change we made to the Queue after publishing that section back with version 2.6 I think. Typically there is an event associated with each and every flowitem that enters a fixed resource subclass object whether there is a process time or not. In other words, a flowitem enters an FR, the input ports are closed, an event is created and put into the future event list, when the event fires the inputs are reopened. We decided to increase the execution speed by removing this "unnecessary" event in the case of a Queue, and just execute the code associated with the Send To Port field as part of the flowitem move event. We soon found this caused "stack overflow" errors when many flowitems enter a Queue at the same time, so we compromised and force an extra event with every 50th flowitem to enter within the same event.

If you have any questions after reading Help>Users Manual>Flexsim Object Library>Fixed Resource, let us know and we'll try to answer them.

Cliff
Here are some comments from Cliff that may help clarify this issue.
__________________
Jeff
Flexsim Support
  #4  
Old 08-14-2007
AlanZhang's Avatar
AlanZhang AlanZhang is offline
Flexsim Super Moderator
 
Join Date: Aug 2007
Location: CA
Posts: 289
Downloads: 64
Uploads: 0
Thanks: 88
Thanked 91 Times in 47 Posts
Rep Power: 225
AlanZhang is a jewel in the roughAlanZhang is a jewel in the roughAlanZhang is a jewel in the rough
Default

I was reading the section of "FixedResource" in the manual. It is really helpful to clarify issues when you see something wrong in the model. A clear image of the FixedResource logic is a must if you want to dynamically control the flows using code.

Something is not so clear in the flow chart.

1.
What is the initial state of those ports? The chart only has steps of opening ports, but not closing ports. When those ports are closed in the logic? Cliff mentioned in the above post: "...In other words, a flowitem enters an FR, the input ports are closed, an event is created and put into the future event list, when the event fires the inputs are reopened...". Does this mean the input ports of an FR are closed once a flowitem enters it? What about the output ports of the upstream objects?

2.
How many FixedResource are involved in the flow chart? 3 or 2?

3.
Where is the point that the event is created mentioned in the Cliff's comments.

4.
What determines when an upstream item gets released?

Hope by discussing, more people will have better understanding of how Flexsim objects works.

Thanks.
Alan
  #5  
Old 08-14-2007
Jeff Nordgren's Avatar
Jeff Nordgren Jeff Nordgren is offline
Technical Support Manager
 
Join Date: Jul 2007
Location: Orem, UT
Posts: 65
Downloads: 79
Uploads: 0
Thanks: 40
Thanked 21 Times in 17 Posts
Rep Power: 233
Jeff Nordgren is just really niceJeff Nordgren is just really niceJeff Nordgren is just really niceJeff Nordgren is just really nice
Default

Alan,

The documentation in the users manual is fairly comprehensive and detailed. I hope I can clear up your questions.

1. The initial state of all ports is open unless closed by the modeler. The documentation covers the opening of ports because the output port is always open unless closed by the modeler. Not all FRs are exactly the same. The queue is a good example of that. For our conversations sake, we will say that the FR we are talking about is a processor. The input ports are closed when a flowitem enters so no other flowitem can enter. This, of course is only true if the capacity of the processor is 1. The input port stays closed until the flowitem leaves through the output port. At that point the processor is ready to receive another flowitem and the input ports are opened. The output port of the upstream object remain open. But if there is a flowitem in the upstream object that is ready to leave, the status of the upstream object will be "blocked".

2. The chart itself references only one object. It may make references to some condition on an upstream object but the flow chart itself is of one object.

3. I think I probably covered this one in item 1.

4. A flowitem will be released from an object when it has a flowitem that is ready to leave and a downstream object that is ready to receive it.

I hope that covers it?
__________________
Jeff
Flexsim Support
The Following 2 Users Say Thank You to Jeff Nordgren For This Useful Post:
Cliff King (05-20-2008)
  #6  
Old 08-15-2007
AlanZhang's Avatar
AlanZhang AlanZhang is offline
Flexsim Super Moderator
 
Join Date: Aug 2007
Location: CA
Posts: 289
Downloads: 64
Uploads: 0
Thanks: 88
Thanked 91 Times in 47 Posts
Rep Power: 225
AlanZhang is a jewel in the roughAlanZhang is a jewel in the roughAlanZhang is a jewel in the rough
Default

Jeff,

Thanks for your answer. One small thing remains. I assume that in the chart, the first opening of ports means input ports, while the second means output ports. So if the output ports are always open, why need to open it after "Call Sendto function"?

Alan
  #7  
Old 08-15-2007
Jeff Nordgren's Avatar
Jeff Nordgren Jeff Nordgren is offline
Technical Support Manager
 
Join Date: Jul 2007
Location: Orem, UT
Posts: 65
Downloads: 79
Uploads: 0
Thanks: 40
Thanked 21 Times in 17 Posts
Rep Power: 233
Jeff Nordgren is just really niceJeff Nordgren is just really niceJeff Nordgren is just really niceJeff Nordgren is just really nice
Default

Alan,

If you look at the shaded section of the chart on the left, it tells you that the first one is input ports and the second one is output ports. I guess I was answering the question from the modelers view and not the programmers view. From the programmers view (internally) the output ports do need to be opened. But from a modeler view, having no control over the internal stuff, the output port is always open unless the modeler closes it. In the normal flow of things the output port (modelers view) is always open unless you close it. So I guess it just depends on what view you choose to look at it.
__________________
Jeff
Flexsim Support
  #8  
Old 08-16-2007
AlanZhang's Avatar
AlanZhang AlanZhang is offline
Flexsim Super Moderator
 
Join Date: Aug 2007
Location: CA
Posts: 289
Downloads: 64
Uploads: 0
Thanks: 88
Thanked 91 Times in 47 Posts
Rep Power: 225
AlanZhang is a jewel in the roughAlanZhang is a jewel in the roughAlanZhang is a jewel in the rough
Default

Jeff,

Again, thank you very much! You've been very responsive and helpful.

Best Regards,
Alan
The Following User Says Thank You to AlanZhang For This Useful Post:
Jeff Nordgren (05-16-2008)
  #9  
Old 05-16-2008
Goksin Yilmaz's Avatar
Goksin Yilmaz Goksin Yilmaz is offline
Flexsim User
 
Join Date: Aug 2007
Location: ON, Canada
Posts: 21
Downloads: 11
Uploads: 0
Thanks: 23
Thanked 13 Times in 6 Posts
Rep Power: 213
Goksin Yilmaz is a jewel in the roughGoksin Yilmaz is a jewel in the roughGoksin Yilmaz is a jewel in the rough
Default Problem with closing input port of a queue at entry

Jeff,

I have been trying to follow your guideline of
Quote:
"You should NEVER, repeat NEVER open or close input/output ports in the OnEntry or OnExit triggers."
Today I had an interesting problem which I would like to share with you. I also attach a simple, sample model at the end of this message.

What I want in this simplified model is:
  • Queue3 is a buffer location with capacity of 1, to act as a gate-control for a processor.
  • The input port of Queue3 is closed from the very start.
  • After a certain event (at simulation time 5 of the sample model), a message is sent to open the input port of Queue3.
  • As soon as one flowitem enters Queue3, the input port should be closed (which is done through a message to itself.)
However in the model, a second flowitem manages to sneak into Queue3. After thinking about it, I can (kind-of) understand why this happens with a queue (I tried changing Queue3 to a processor with zero process time and it worked as I expected.)

Can this be explained with the quote from Cliff you posted before:
Quote:
Typically there is an event associated with each and every flowitem that enters a fixed resource subclass object whether there is a process time or not. In other words, a flowitem enters an FR, the input ports are closed, an event is created and put into the future event list, when the event fires the inputs are reopened. We decided to increase the execution speed by removing this "unnecessary" event in the case of a Queue, and just execute the code associated with the Send To Port field as part of the flowitem move event.
I will appreciate any guidance about this. For example:
  • Are there any other objects where a similar problem can happen?
  • When the receiving object is a queue and there is the probability of multiple flowitems waiting for the same queue, should we take an exception to your guideline?
Thanks in advance.
Attached Files
File Type: zip Close_Input_Problem.zip (46.1 KB, 350 views)
  #10  
Old 05-16-2008
Jeff Nordgren's Avatar
Jeff Nordgren Jeff Nordgren is offline
Technical Support Manager
 
Join Date: Jul 2007
Location: Orem, UT
Posts: 65
Downloads: 79
Uploads: 0
Thanks: 40
Thanked 21 Times in 17 Posts
Rep Power: 233
Jeff Nordgren is just really niceJeff Nordgren is just really niceJeff Nordgren is just really niceJeff Nordgren is just really nice
Default

Goksin,

You may have found a minor "exception" to my rule. The queue is a little bit of a different animal. However the same rule can be applied if you use the "NoDelay" on the message you send in the OnEntry trigger of the queue. So if you change the Delay time to "NoDelay" instead of 0, it should work as you would expect it to.
__________________
Jeff
Flexsim Support
  #11  
Old 05-19-2008
Brandon Peterson's Avatar
Brandon Peterson Brandon Peterson is offline
The Flexsim Consultant
 
Join Date: Jul 2007
Location: Salt Lake City, Utah
Posts: 382
Downloads: 29
Uploads: 6
Thanks: 192
Thanked 516 Times in 235 Posts
Rep Power: 490
Brandon Peterson has a brilliant futureBrandon Peterson has a brilliant futureBrandon Peterson has a brilliant futureBrandon Peterson has a brilliant futureBrandon Peterson has a brilliant futureBrandon Peterson has a brilliant futureBrandon Peterson has a brilliant futureBrandon Peterson has a brilliant futureBrandon Peterson has a brilliant futureBrandon Peterson has a brilliant futureBrandon Peterson has a brilliant future
Default

The following rule is not as hard and fast as it seems:
"You should NEVER, repeat NEVER open or close input/output ports in the OnEntry or OnExit triggers."

I think is more appropriately a guidline that should not be crossed without extreme caution.

I have found that in most instances I can close input and output ports on entry and exit without any problems. I have not had as much luck with opening ports. With this in mind I still would not recommend that a user do this without first trying to do it another way.

The case Goksin mentions where he is using a queue as a gate and he has another flowitem sneaking in before he can close the input port with a message is a case where that should be done on the entry trigger. However, if he tries to also include code that opens the output ports he could run into some serious problems.

The bottom line is that if you are going to break the rule you need to make sure that you test, validate, and debug your model at the highest level and after that you will still need to keep that situation in the back of your mind as a potential cause for later problems. And always remember that nobody will be very happy with you if you conciously break the rule and then ask for help later because breaking the rule has caused you problems.

If you're going to break the rules, break them responsibly!
Brandon
__________________
thats not normal.
The Following User Says Thank You to Brandon Peterson For This Useful Post:
Goksin Yilmaz (05-19-2008)
  #12  
Old 05-20-2008
Cliff King's Avatar
Cliff King Cliff King is offline
Vice President Technical Services
 
Join Date: Jul 2007
Location: Utah
Posts: 272
Downloads: 158
Uploads: 14
Thanks: 102
Thanked 304 Times in 110 Posts
Rep Power: 412
Cliff King has much to be proud ofCliff King has much to be proud ofCliff King has much to be proud ofCliff King has much to be proud ofCliff King has much to be proud ofCliff King has much to be proud ofCliff King has much to be proud ofCliff King has much to be proud ofCliff King has much to be proud of
Default

When is there ever a problem with closing a port in the entry/exit trigger? I can only think of problems with opening them...
  #13  
Old 05-22-2008
Jeff Nordgren's Avatar
Jeff Nordgren Jeff Nordgren is offline
Technical Support Manager
 
Join Date: Jul 2007
Location: Orem, UT
Posts: 65
Downloads: 79
Uploads: 0
Thanks: 40
Thanked 21 Times in 17 Posts
Rep Power: 233
Jeff Nordgren is just really niceJeff Nordgren is just really niceJeff Nordgren is just really niceJeff Nordgren is just really nice
Default

Quote:
Originally Posted by Brandon Peterson View Post
If you're going to break the rules, break them responsibly!
Please don't break and drive!
__________________
Jeff
Flexsim Support



All times are GMT -6.
Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2020, vBulletin Solutions Inc.
Copyright 1993-2018 FlexSim Software Products, Inc.