dsturrock

Because of spammers, we don't allow files to be posted to this public forum. You should really move this discussion to the Simio Insiders part of the forum. I have the same SimBit redone using a FreeSpace approach - I'll try to email it to you.

Perhaps try the SimBit: VisitAllServersInAnyOrder

In the navigation window, click on ModelEntity (or any other object that you want to modify) and you can add states to that object definition. Otherwise you are adding the states to the model itself.

I looked at this example and your other posting, so I have a general idea of what you are trying to do. I hestiate to spend too much time on a specific solution because I know that both of these were just examples of your real problem. The key is that the BatchQuantity is determined by (or in the context of) the parent entity. The easiest way to approach this problem is to set a state on the parent entity for its batch size. Here is one way to do that... have the Source object that creates the parents record that value and then create the members. BatchingLogic.spfx

If you look at the SimBits for Flow you should find what you need.

Not that I am aware of. But if someone wants to write a chapter or more, I help find a place to publish it.

Use the Standard Library Source object. Select and arrival Model of Arrival Table. Look at the help on that topic for more information. I believe there is a SimBit illustrating what you want to do.

Assignments are carried out sequentially, top to bottom in the list.

In general, tables consist of Properties and properties cannot change during a run. If you have Enterprise Edition you can also add States to a table and assign those states directly as you appear to want. If you do not have Enterprise you can add a column of type State. That column needs a state name. The difference is one extra level of indirection. In both cases you could Assign for example MyTable.MyStateCol = MyTable.MyStateCol + 1. In Enterprise, you would see the value in the table be incremented. In the second approach you would see the state that is identified in that table cell be incremented.

I don't know your objective, but having a timer on every entity seems like an inefficient approach. How about instead having each entity added to a Storage when it enters an area of interest (like a Combiner) and remove it from that storage when it leaves that area of interest. Then at any point in time you could Search through that Storage queue and do what you like with whatever you find there (pick the first, pick the "best", remove them all, ...).

You are probably already aware that Server1.InputBuffer.Contents.NumberWaiting gives you the number of all entities waiting. If that is not what you want, then you will probably need to take the state approach described above. Two other ways would be to periodically search the queue (slow if done frequently) or to use Storages (somewhat obscure).

I'm not sure if I understand exactly what you want to do, but generically it sounds like you just want to have more insight into system status. The simplest thing that might work IF you described the entire system is to look at Entity1.Population.NumberInSystem for each entity type and make decisions on when to send new entities directly to the sink or elsewhere. You could even put an expression like Entity1.Population.NumberInSystem<100 into the EntitiesPerArrival field to simply not create entities when the system is too backed up. Another choice for more control is to add states to the model for each thing you want to track and then make decisions based on that state. For example you might create an integer state named Type1NumberWaiting and increment/decrement that state with an Assign each time it starts/stops waiting. Then when you create new entities you could evaluate Type1NumberWaiting to determine what action you should take.

The later posts are both correct. You must realize that stochastic simulation does not give an exact answer but rather gives you an estimate of the answer. Hence it would be inadequate to say If you have run this with default settings a better interpretation would be: If you create a response for this item, you can also see that information (and lots more) graphically in the Response Results tab. If the range is too large, you can generally reduce the range (create a tighter prediction) by running additional replications.

First of all, I won’t argue with you at all – I would also like to see Simio have more intuitive behavior in our Standard Library objects. But perhaps my explanation below will make it a little bit more intuitive. But the good news is that, unlike other products that limit the behavior to one of a few predefined choices: 1) In Simio your choices are unlimited - it is not too difficult to make it behave exactly as you want. The OnCapacityChanged add-on process (or related processes like On Shift and Off Shift) can use the Interrupt, Suspend, and Resume Steps as illustrated in several SimBits. 2) If you want some behavior to be your default behavior, just create a custom object with that behavior. If you think about the built-in behavior as follows it might help… PARADIGM: A resource of capacity > 1 still represents a single resource, but just has the ability to process multiple concurrent entities. But it still only has a single state (Idle, Busy, Failed, …), e.g. if it is failed, the entire resource is failed (all capacity units), and if it is off-shift (e.g. capacity=0) all units are off-shift. REDUCING CAPACITY: When capacity available is reduced below the current number of busy units, there are many possible valid behaviors depending on your system. The default behavior of our standard library is simply to finish working on the current entity, and then take the unit off-line. But you can use the tools mentioned above to change that default. For example, you might implement some behavior that says “if I am within 10 minutes of completion, go ahead and complete it, otherwise record its remaining time, add 5 minutes of restart time, then put it at the beginning of the waiting entities”. OFF-SHIFT: When a resource is taken off-shift (capacity=0) all units are off-shift. Current Standard Library behavior causes all processes to be suspended (Suspend/Resume Steps) while it is off-shift. This essentially means that everything is “frozen” in place. The entities are not removed from the resource, but rather just suspended so no progress is made during the off-shift period. When the off-shift period is complete (e.g. capacity > 0) then all the entities resume exactly where they left off. Unfortunately that last phrase is what causes the unexpected behavior when you suspend at one capacity and then resume at another lower capacity. You are essentially combining the two above paragraphs. You suspend all activity while off-shift, then after you resume, you will behave as though you had just reduced the units in service, which under the default behavior says keep working on the entities in process until they are completed. In your case, it sounds like you would want to add content to the On Shift process so that if capacity is set to less than the number busy, that you would want to Interrupt the remaining entities and send them back to the entry queue. And then perhaps build that behavior into a custom Server object and use that object routinely.

Perhaps the Outbound Link Preference of Available or the Blocked Destination Rule of Select Available Only will solve the "select only idle server" problem.

Define an event named ShowFile. Place a button that triggers that event. Create a process that is triggered by the ShowFile event. In that process you would have a custom step which would have some user code that displays the appropriate file. See the help and perhaps the API forum for directions on how to create a custom step. The code and dll for that custom step would be a welcome submission to the Shared Items user forum.

I think you are correct on all counts. I will have someone look into item 3 - it may be a bug.

Here is an example from our training course that illustrates a similar problem. In this case it is a librarian who waits until 10 books are dropped off, then picks up ALL waiting books up to his capacity. But I expect you can use this to modify for your situation.Workshop08c-Librarian.spfx

The 20,000 entities message, like the "maximum number in system" message is just a warning, not a limit. It is there to let you know of a potential problem that could cause an out-of-memory crash. If it is expected behavior and your computer memory can handle it, then simply check the "Don't show me this again" message and press "Continue running" and you will never see it again in that model. Regarding model speed - how many entities are you searching, how complex is the search, and how often are you repeating it? Frequent complex searches across lots of entities will certainly slow execution. Are there other ways to approach your problem? Perhaps use arrays and Find instead of Search? You also mention "reading". Reading from a file (or worse Excel or a DB) during a run can be painfully slow. If possible, replace that with data in a table that is "read" from memory rather than a slow disk access and possibly a context shift.

We are looking at this problem and will report back as soon as we find the problem. In the mean time, if you have any real or small sample models that illustrate the problem, please post or email to me. Thanks.

The second problem is easy. Simply change the Execute step option highlighted above to its default "WaitUntilProcessCompleted". For the first problem, what I said is still accurate. You can easily enable homing when idle, or you can tell it to wait somewhere when idle, but you can't automatically do both. To allow you will need to provide a path so the vehicle can actually get back to transfer node 1. And you will have to add some similar logic to send the vehicle there when it is appropriate for it to go there. All of this discussion is to allow you to model exactly the behavior you have described. But as you share more details of your objective, it looks more and more like this could be easily approximated just using automatic library behavior without all this complexity. For example, the time to "pull up the man from the deep well" might just be modeled as a loading time. Every model is an approximation and a big part of effective modeling is know the correct level at which to approximate. If you would like some advice on how I would model this, please post or email me the full details of the situation you want to model and your objectives (e.g. why are you modeling it and what do you want to learn).

"R" starts rotation in 3D view, "Esc" stops it. It may have been after your release that this was added to the View Ribbon as well: Note also that they gray navigation hints can be toggled on and off with the "H" key. You've missed a lot in the last 10 releases - you should consider upgrading. http://www.simio.com/resources/release-notes/

You had several different problems here. First of all, your sequence was incorrect - it included the output of server 1 and your entity never moves there by a sequence (it just emerges there after visiting server 1) Second you need to seize a vehicle, move it, then release it. No requests are processed while a resource is seized. Third, the entity was waiting for the move to complete before it started moving. I assume that the point of this was to have them concurrently move toward each other. To make that happen 2 things must be overcome. 1) All add-on processes wait for completion before the executing entity proceeds with other actions, 2) The Move Step by definition holds the token until the Move is complete. Both of these are overcome by creating a second process which is Executed with the Token Wait Action set to none (no wait) Finally, the return to home option on the vehicle conflicts with your intent for the vehicle to move somewhere and wait for the entity. it can't both wait while idle and return to home when idle.

I understand why this is confusing. I think the main confusion arises because your station has a capacity greater than 1. The Simio paradigm is that a resource with capacity > 1 is still a single resource with a single Resource State, but just has the ability to process more than one entity at a time. So if any unit of the resource is in use the resource state is busy, if all units are idle the resource state is idle. With the above paradigm in mind, the ResourceState statistics are not describing individual entity interactions, but rather are describing the transition of the entire resource (all units combined) between those states. The resource enters the Processing (busy) state when 1 or more units become busy. It leaves that state and enters the Starved (Idle) state when all units become idle. The average time in spent in that (1 or more units) busy state was 55.5133 minutes per transition. This accounted for 6994 minutes total or 69.39% of the time. The resource transitioned between the busy and idle states 126 times. By contrast, the Processing (station) statistics are telling you about the entities that enter and leave the processes. There were an average of 1.28 entities in the processing station. The average entity was "held" (processing) in the Processing station for 25.99 minutes. 501 entities were processed. You didn't ask about Capacity utilization, but that also can be tricky to interpret when capacity > 1, especially if the capacity varies over time (which yours apparently does not). Perhaps the easiest to understand is UnitsUtilized. This tells you that of the 10 units available an average of 1.289 and a maximum of 8 were in use. UnitsScheduled is the same type of statistic, but records how the number of units scheduled to be available varies over time. The Scheduled Utilization is the most common statistic telling you basically the ratio of the above numbers. It is a little more complicated than that, but that is beyond this topic.

Excerpt from help: