gdrake

To answer your question specifically with regards to the MultiEchelonSupplyChain example, the OnReplenishOrder process that you see in the process logic of the data table driven example is automatically executed by the Inventory elements when the inventory detects the need to replenish. Go to Definitions -> Elements and click on the Inventory elements and you will see where that process is being referenced. The ShippingReceivingLogic process is being executed when an entity enters any of the BasicNodes placed in the Facility View. For example, click on the DistributionCenter node and in the Add-On Processes -> Entered property you will see the name of that process befiling referenced. The TryFulfillOrder process is executed by the OnCustomerOrder process using an Execute step, which is in term triggered by a customer order arrival. Note that If you are trying to figure out where the name of a process is being referenced, you might go to Project Home in the ribbon UI and go to the Search window. And then search for the name of the process in the model, and it will show you the locations where it is being referenced.

Add a 'NumberArrivals' data column to the data table that is defining the arrival schedule. For example, define your arrival schedule table like this: SomeArrivalTableName ArrivalTime NumberArrivals 8:00 am 5 8:30 am 5 9:00 am 10 9:30 am 8 etc. Then on the Source object, specify the Arrival Mode as 'Arrival Table'. Specify the Arrival Time Property as 'SomeArrivalTableName.ArrivalTime'. Specify the Arrival Events Per Time Slot as 'SomeArrivalTableName.NumberArrivals'. Note that you can also easily add columns in the data table as well for the Arrival Time Deviation and No-Show Probabilities, and then map those columns to the corresponding properties in the Source. For example, if the Arrival No-Show Probability actually differs depending on the day of week or period in the day.

You can dynamically assign the 'HomeNode' state variable of a vehicle or worker object (e.g., ASSIGN: Vehicle1[1].HomeNode = BasicNode1 or ASSIGN: Vehicle.HomeNode = BasicNode1 if the vehicle of interest is associated with the token executing the Assign step). The 'Initial Node (Home)' property is simply the initial value assigned to that node reference state variable of the vehicle or worker. I'll have the property description of that 'Initial Node' property updated to make sure to note the state variable that can be dynamically assigned to change the home node location.

Adam, just a note that for a task sequence, based on your feedback on the Forum we have prioritized an enhancement that will allow you to use either the sequence numbering scheme that we currently support or an 'Immediate Predecessors' field to define task precedence. For your network diagrams, seems like you will be more comfortable going with the Immediate Predecessors field approach and for each task just listing out the predecessor numbers.

Go to the entity instance placed in the model and check the Population -> Initial Number In System property. Sounds like that property probably has a value of '1'. So that 1 entity is being initially created and then your Create step is creating 5 more.

The Operation & Activity constructs are only supported for entities located inside a fixed processing location such as an object modeling a 'Workstation'. While an entity is traveling on a TimePath, you can execute some process (using an Execute step) or a task sequence (using Task Sequences and StartTasks step).

Adam, yep, the sequence numbers that Glen posted above will do that second flow diagram that you mentioned. Task1 = 10 'Task1' must be finished first before any other task may be started because its primary number of '10' is smaller than any other primary number in the sequence. Task2 = 20.1.1 Task3 = 20.1.2 Task4 = 20.2 Once 'Task1' is finished, you can start all of the tasks with primary numbers of '20' in parallel. Task5 = 30.1.1 You can start 'Task5' once 'Task2' is finished, because it is a higher operation number of '30' that is on the same exact task substream. In other words you can do a 30.1.1 after 20.1.1 is finished. Task6 = 30.1 You can start 'Task6' once 'Task2' and 'Task3' are finished. Because then you will have finished all the tasks with sequence numbers starting with '20.1' (finished all tasks with lower primary numbers that are part of the 'XX.1' substream including any nested substreams). Task7 = 40 This task has the highest primary number so can be started once all other tasks have finished. ---- As I said in my first post, the task sequencing number scheme that we provide is very flexible and should be able to handle any flow diagram that you come up with. And the approach is particularly friendly if tasks are being defined using a table data approach. Some time down the road, hopefully we'll get a chance to provide a visual flow chart editor that just auto-enters task sequence numbers in for you. Until then, once you get the hang of how the numbering scheme works with a few examples, hopefully not too difficult to pick up. I think the basic rules of the task sequence numbering scheme are also described in the help documentation.

Here is a sequence numbering scheme to do the above task flow chart that you pasted. the task sequence numbering scheme that we support is very flexible and very friendly for defining a task sequence in a data table, and you can do as many nested task substreams as you like, but I agree that it can take a moment for how the numbering scheme works to click. At some point, agree it will be nice if we can provide a visual drawing tool to draw the sequence and the sequence numbers are entered automatically. But hopefully once you understand how to number your first flow diagram above, then won't be too difficult to do any of your other task flow charts that you have. Task1 = 10 Task2 = 20.1 Task3 = 20.2 Task4 = 20.3 The above says do Task1 first, then do Task2 (task substream '1'), Task3 (task substream '2'), and Task4 (task substream '3') in parallel. Task5 = 30.1.1 Task6 = 30.1.2 That says to do Task5 and Task6 when Task2 is finished. Basically, to do a nested task substream, a task numbered 30.1.2 is saying 'nested task substream '2' of task substream '1'). Task7 = 40 (you won't do this task until all tasks are finished - is the last task)

1) Add a state variable to you model that is the switch control variable. For example, add an integer state variable named 'MySwitchControlVar'. 2) Specify the variable that you created as the Switch Control Variable on the Flow Node. 3) On each of the possible outbound links that can be chosen, in the Selection Weight expression for the link enter an expression like 'MySwitchControlVar==1' which would say for that particular outbound link, send flow to that link if the switch control variable has a value of '1'. 4) Add your own state assignment logic to assign that switch control variable a new value whenever you want to 'switch over' to sending flow to a different outbound link from the flow node. There may be a SimBit (a small example) installed with Simio that illustrates the approach. The description text of the Switch Control Variable property also provides some of the same information that I provided above.

Mark, Simio internally tracks the number of active suspensions applied to a process, or to the movement of an object or a flow regulator...and you do see the new value of that counter included in the trace window information whenever a new suspension is added or a suspension is cleared, but that counter is not currently exposed as a function on the affected object or element. I've noted your request.

Mark, just a note that the FlowToItemConverter has 'Purge Contents Triggers', 'Clean-In-Place Triggers', and several add-on process triggers as well.

You might build a model like this: Source -> ItemToFlowConverter -> the flow line Where the Source object is the Standard Library Source for creating discrete entity arrivals. So, use a Source to create discrete entities (of possibly varying entity types) from table data. Then have each discrete entity go into an ItemToFlowConverter to be converted into a specified quantity of flow, by specifying the 'Flow Quantity Per Item' property however you like (sounds like that will possibly be a value also coming from table data that was used to define the entity's type). The FlowSource is currently easiest to use as an infinite flow supply of some flow type. You can of course open and close the 'Output' flow regulator (e.g., Assign Output@MyFlowSourceName.FlowRegulator.CurrentMaximumFlowRate = 0 to close the output valve of the flow source). However, if you have a situation with discrete arrivals of flow quantities where each arrival has some entity type and some volume or weight quantity, I think using a Source -> ItemToFlowConverter combination is probably the best way to go.

Multi-capacity preemption with the Standard Library Server is a tricky topic. When using capacity schedules, the Server as currently designed works most naturally if the on-shift capacity is a constant. For example, the capacity goes from 1 to 0 and then back to 1, or from 10 to 0 and then back to 10 and so forth. When the Server's capacity goes to 0, it goes into an 'Offshift' state and the processing logic of all entities that have been allocated Server capacity and are located in the Server's 'Processing' station get suspended. That seems fine, though we could also add an option at some point which allows any current entities to finish processing while the Server is in an 'OffShiftProcessing' state (i.e., the Server works overtime to finish any current WIP), but we have not put that sort of behavior option in yet. But that is certainly doable and has been an idea considered before. When the Server goes back into the on-shift 'Processing' state (which means it is processing at least one entity), then all entities in the Server's 'Processing' station resume their processing delay times. The Server comes back on-shift with a capacity less than the number of entities already in-process The current behavior is as mentioned above. The Server just simply resumes all processing. We've discussed before in previous years trying to do something more fancy here, but trying to only partially resume processing would be much more complicated logic. Let's say 10 entities are processing but the capacity is only 1. Which of the WIP entities is the lucky one that is selected to resume processing? Then the 9 entities that are not the chosen one, presumably they would have to be Interrupted and then release the Server capacity that they hold? Because they then have to wait to re-Seize the Server capacity until the single entity finishes processing and releases capacity (thus allowing the next entity to re-seize)? But those 9 entities may be expected to wait in the Server's Processing station? And if so, then you might have to somehow make sure that no new entities who have yet to ever start processing (e.g., entities waiting in the Server's Input Buffer or waiting outside the Server at its 'Input' node if there is no input buffer) can seize the server before the interrupted guys? So you may have to put in some layered allocation rule scheme whereby new entities waiting in the input buffer are a lower priority to seize Server capacity than entities already in the Processing station waiting to re-seize Server capacity)? Or maybe you just Interrupt everybody and stick them in the Input Buffer of the Server and let the specified ranking rule/dynamic selection rule specified on the Server sort them all out? And if it turns out that the next entity who gets the Server capacity was not even WIP on the server when it went off-shift but was a guy who arrived during the off-shift period, then so be it. And so forth. It can be a bit complicated. We've always punted in the past on this topic because of the issues involved, though one of the reasons that we did add the Interrupt step was to give users a chance to customize a Server if they needed to go down this sort of road (as Dave Sturrock mentioned in his last post). The user can then customize the processing behavior of the Server to do what they think works best for them. Another work-around that we have sometimes told users to use multiple Servers each with capacity 1. Not a course for everyone, but for some problems that sort of modeling approach has worked out fine. But that is somewhat of a long-winded explanation of why, although it may be thought of as a 'bug', we've taken a 'works as intended' stance thus far. Though I don't think taking another look at this topic sometime again is a bad idea. I totally understand how a user might naturally expect or want something different.

Regarding #3, it is correct that by default when a Server goes from off-shift to on-shift that all entities which have already been allocated Server capacity will simply continue processing (even if the scheduled capacity is less than the entities already using the Server. The server's scheduled utilization will be greater than 100 during the time period when it is working over scheduled capacity). Similarly, suppose you have a Server with scheduled capacity of 5 that has 5 entities currently processing on the Server, and the scheduled capacity is decreased from 5 to 4, that capacity decrease does not by default suspend the processing of one of the entities on the server. All 5 entities continue processing and the server's scheduled utilization will be greater than 100 during the time period until at least one of the entities finishes and releases the server. If it is important for you in a model to never have a server being utilized above scheduled capacity while on-shift, then you might add some Interrupt step-related process logic to your model that essentially kicks entities off the server whenever capacity is decreased. The interruption logic will make the entities release the server capacity, store the remaining processing time, and transfer the entities from the processing station back into the input buffer to have to re-seize. You would have control over selection of which entities are desired to get kicked off and of course if having to re-seize the Server then the server's allocation ranking and selection rules would be applicable. The SimBit 'InterruptingServerWithMultipleCapacity.spfx' might be looked at to see an example of interrupting entities on a server, saving the remaining processing time, and then transferring the entities back into the Input Buffer of the Server to have to re-seize capacity in order to continue processing.

In that new model that you attached, in the 'GoToStation' process logic and the Transfer step, of course you will need to specify the exact entity 'B' whose station you are trying to transfer into. To do that, you may have to set some kind of variable pointing to that B entity. But you will need to use absolute reference to it. Now in this very simple model, I can cheat because I know that there is only one 'B' entity in the system. So if you, for example, specify the Station Name property in that Transfer step as 'B1[1].estacao' then you will see the model work just fine. That is saying to transfer into the entity in the population of 'B1' type entities at population member index 1. Of course there is only one of those guys in the system so sure that is the right guy. However, if you had multiple entities of type 'B1' in the system, then you would want to of course reference the specific B1 type entity sitting at that node presumably to be matched up with the A entity. In that case, you'll need to setup some kind of reference to get to the right 'B1' type entity. Whether that is setting a variable reference, or putting that B1 entity into a storage that the A entity can then search or whatever.