dsturrock

Logs are currently limited to interactive runs. If you want to keep observational information across replications, then you should probably use one of the Write* steps to write custom data to a file.

How do you define "huge"? Simio's ability to copy is limited only by your system memory. Did you receive an "out of memory" error? You can also save your project and then load it as a library from the Project Home ribbon. You can then use the items on the ribbon illustrated above to subclass, copy, or clone objects from that library.

Click on the output node of Server (or any TransferNode) and learn about the properties in the Routing Logic category. You can use help and SimBits or look at some of the free on-line training videos.

First, you really should get the latest. A lot has changed since version 6. I'd look at SimBits: Moveable Operator and Worker Used For Multiple Tasks

For now you can review the 7.123 release notes and help. Additional examples will be included with 7.124 available next week.

Yes. Many people miss the fact that you can click on the Project item in the Navigation panel. This exposes a great deal of extra project-level capabilities like copying objects and maintaining symbols.

Yes, on the ModelEntity, under the Population category you will find the property Maximum Number In System. This exists because a common error is to allow entity creation to go wild (via an uncontrolled creation loop or an unbalanced system, for example). Since Simio has no limits, if this is allowed to happen you would run out of memory and possibly lose your model. So instead we allow you to set this number to anything that is reasonable in your model.

If you are creating a manual schedule you have full control and can change the capacity of any resource at any time. If you are using Simio schedules you can put a property in the value field and change that via the experiment window. I am not sure, but I believe that you can use a Simio schedule and also manually change the capacity value and that manual change will stay until the next automatic change.

Your assumption is correct.

The best control is provided by adding process logic to the Evaluating Seize Request logic on any resource. But unfortunately the flexibility of processes is unavailable in Express Edition. You might also accomplish what you want by assigning the priority of the entity according to it's desired seize priority. For example, entities at server1 have priority 1, server 2 have priority 2, ... Then on each Worker you can set its Ranking Rule to Smallest (or Largest) Value First on Entity.Priority.

Another problem is on the left side of the expression. When you are examining items in a list or collection, the keyword "Candidate" indicates that it is an item in the list. That must be followed by an object type to tell Simio what context to use with that item. For example: Candidate.Node.AssociatedStationOverload references the AssociatedStationOverload function on the candidate which is a Node Candidate.Node.AssociatedObject.MyServer.CurrentWaitingTime references a state named CurrentWaitingTime that is defined on a custom object definition called MyServer, which is the object associated with the candidate which is a Node.

Look to the release notes and help of the last couple sprints for more information on resource reservations. BTW, more related features are still on the way. Regarding your process time there are many ways to handle it based on your situation. --If you have a single entity arriving that represents a batch, then the easiest approach is a processing time something like 25 + (BatchSize * 5) to get 30 for the 1st one and 5 for every additional one. --If each batch comes as a series of similar entities that is different from the rest (perhaps just an order number) then you might use the Workstations built-in setup time where if the order number is different, there is a 25 minute setup time, otherwise its 0. But in either case the processing time is 5.

1) If you are not already using a Workstation (instead of a Server) you probably should because it has the 3 stage processing that you appear to need. Or use the new task features added to Server around sprint 120/121. 2) The problem you are having is because between the "work" phase and the "move" phase there is a delay. Even if this is a zero-time delay, the Worker momentarily goes idle, and it gives any other waiting entity a chance to seize the worker before this entity can get it back. One of our SimBits has a "hack" type solution to this, but a much better solution is available using the resource reservation features added to sprints 121/122. This new feature lets an entity release a resource, but prevents any other entity from seizing that resource for a specified time period. 3) There are often multiple ways of approaching a problem. The simple answer is to use the one you understand the best or the one that is clearest to explain to others. In general, I personally try to stay inside the object properties (no processes) as much as I can because it is easier for most users to understand (e.g. more self-documenting). But if I need to add process logic for any reason, then I am inclined to put everything in the processes so I can see all my logic together in one place. But that is just my personal preference.

Worker returns to Server1 because a new entity has arrived at server1 and seized the worker before the first entity could get to server3 to seize it. There are actually some new features in the latest release (sprint 122) which make it easier to reserve a worker for later and prevent other objects from seizing it. From your description it sounds as though you only expected to have one entity processing at a time within the 3 servers. If that is true, then you must adjust your logic to make that so. Possibly use the OnEvent arrival model on source1 and only create a new entity each time one exits server3.

It sounds like a very interesting problem. There are a lot of moving parts to this. I like to start problems like this by evaluating the real system to determine where the decisions are being made. For example: --If the crews are smart and individually decide where and how they work, then I would lean toward making the crews "smart" with process logic on the crew objects. --If a manager makes all the decisions for the crews, then I might instead have a process at the model level representing the manager. --If the crew decisions are basically an outcome of the ships competing for resources, then that might indicate a more traditional approach of ships contending for resources. Once you select the object where the "smarts" will reside, that might also indicate a modeling approach.

Although you gave them the same names, the A defined inside the object is a different object than the A defined in the main model. You need to pass information into an object by using properties. I deleted your objects inside Model and changed the definition of model to pass in an object (entity type) that is internally known as "A".PassEntityTypeIntoSubmodel.spfx

Technically "Occurrences' is the number of times it changed to that particular state. So if it does 5 back-to-back transfers with no state change (like idle) in between, then that would be counted as a single occurrence. If you wanted to count each specific trip, then you might need to add a state on the vehicle or node.

I'm not sure exactly what you want, but it seems like it might already be part of the default vehicle statistics:Number carried: 5727 Number of trips: 2799 Average number per trip: 2.05 (division of the above) Average number on vehicle: 0.3636 (time weighted average)

Without the model its hard to guess the problem. But this sounds like an ideal application of a time-indexed table. You could reference the table value directly in the Rate Scale Factor.

There are several ways to do this. If you simply need a single piece of information, then you can store that in an entity state and simply reference that entity state. That's the "easy" way. But the "elegant" (e.g. correct) way to do it is to reference that table value directly. In Simio all the tables must reside in the top level object. But in fact a repeat group is quite similar to a table. So you can define a repeat group that is part of the object, and then pass in the parent object's table name as a referenced property. Here is an example:PassDownTable.spfx

The new Task feature does that too (except for adding it to the sequence). Look at the SimBit: Multi Task Server Submodel (from project Server Using Task Sequence). Or maybe this SimBit will help you think of other approaches: Visit All Servers In Any Order

I suggest that you check out the Task Sequence features added to Sprint 119. Sometimes timing is everything.

The property that you are attempting to change is Initial Capacity. For ANY property starting with the word Initial, that means the property is looked at exactly once - when the model is initialized. So what ever value you put in there, it will only be used to initialize the server capacity. The best way to do what you want is to use a schedule for the capacity changes, not a time-indexed table. But if you do want to use a Time-indexed table, then you will probably want to take advantage of the On Interval Process option to specify a process when you will Assign the value of Server1.CurrentCapacity each time the active table row is changed.

Simio doesn't specifically have a ticker tape display, but you can "simulate" it in several ways, depending on your objectives: --You could use a Floating Label or Floor Label to display the value of a string state, and then update what you want displayed as needed. --You could create entities that move smoothly across the screen with their animation consisting of a Floating Label or Floor Label. The following illustrates the first approach. TickerTapeDisplay.spfx

The primary movement constraint that Simio supplies for you is the various types of Links. Simio provides the option to prevent entities from running into each other. There are a number of SimBits to help understand the options, including Path Selection Rule. If you use bidirectional paths, it is often easy to get into deadlocking situations. Ways to avoid this include limit path capacity to 1, or perhaps having zones with limited capacity. Or instead consider a pair of opposing unidirectional paths.