Search the Community

Hi, I would like to confirm whether behaviour regarding vehicle visit request queues is incorrect (i.e. a bug) or whether I am misunderstanding how they are supposed to work. I have two types of vehicles in an Emergency Medical Services model. One type transports patient entities (i.e. an ambulance) and one doe not do transport but only responds to some incidents (i.e. a primary response vehicle or PRV). In some cases, both vehicles are sent to an incident node, the ambulance by accepting a visit request from a patient entity at the node, and the PRV by being seized directly by the patient entity at the node. In some cases the PRV is far away and does not reach the node by the time the ambulance has completed loading the patient entity. In such cases I have modelled cancelling of the PRV (that would happen in a real system) by the patient entity releasing the PRV. When this happens, I have noticed that the patient entity that had seized the PRV stays in the PRV's visit request queue, even after the release. It is only removed from the visit request queue when the patient entity is destroyed, which may be some time later after a transport and hospital offload delay. From observing the behaviour of other vehicles, it seems as though a vehicle must enter a node having the owner entity in it before the entity is removed from the visit request queue (or, as mentioned above, it is removed when the entity is destroyed). In my case, I would like to remove the patient entity from the PRV's visit request queue when the PRV is released, however I know that this is not possible as Simio does not allow entities to be removed from this queue with the remove step. At the moment I am spending a lot of time trying to work around this problem, which creates a lot of undesirable behaviour - for example when there are three or four patient entities in the PRV's visit request queue. The vehicle object also has limited options in its task selection strategy which makes filtering out of the released entities in the visit request queue difficult to accomplish reliably. Is there any other way of removing unwanted entities from the visit request queue, without visiting that entity's node or destroying it?

I’ve got a follow up question of my own. What is the use-case of the table property? I can define a table property on an object, and then set that property value to a table in my “parent” model in my object instance. In my object’s processes definitions, I can search the table and find all the rows. However, I can’t seem to do anything with the rows found. For example, I’d like to get a field from each row and assign it to a state variable. I tried referencing the result using TableProp[1,1] , but I get an “incorrect number of parameters” error . I can’t set a state matrix to the table property either  So, what can I do with a table property? Thanks, Adam

There are three features built-in that can help. 1) When you have already built an object with a table, you will find a table tool that will Convert To Repeat Group within that object. 2) When you want to create a table in the parent object, the lower part of the Add Table Data button allows you to build a table matching the schema of any repeat group (e.g. that new repeat group you just made in the included object). This creates the data table exactly matching that names and data types in the repeat group. 3) When you want to "pass" that new table as a property value, you can right click on that new repeat group and specify your table name as the reference property.

A repeat group is a way to pass data between objects. It consists of N fields of properties, which can be repeated (similar to a collection of rows, i.e. a table)—hence a repeating group of properties. The reason you can’t reference the table from the submodel is because of the object orientedness of Simio. When you create a submodel, you are actually creating an object definition. You may only ever plan on placing (or instantiating) your object in a “parent” model in your current Simio project (the .spfx file you are working with), but there is nothing stopping you (or anyone else with access to your project file) from instantiating that object in another, different, parent model or even in a completely different project file (by loading your project file as a library, fyi). So, your submodel can’t know about anything in a parent model, unless there are properties that can be set on the object instance that can then refer to data or parameters at the parent model level. That’s what this quote is referencing: You can “pull” data into an object by looking at Location.Parent.Model.ArrayName for example, but you can’t do too much with that, because there is no guarantee that that array even exists for an arbitrary parent model, let alone that the contents of the array are what they “should” be (in terms of data type). In your case, how would each submodel that you place know which table to reference? Even if you set a table property on the object definition, Simio cannot know what columns will be available, even though you will by virtue of building the model. Repeat groups allow you to create a kind of property on your object definition that you can, for each object instantiation, populate with a table. With a prepeat group, your object definition “knows” about what data will be available to it, because you’ve stated “this data is a property of this object, and it must be set each time I instantiate an object of this type.” Still doesn't resolve the difficulty of actually setting all those properties to get your data into the object instances, but maybe helps explain why things are the way they are... -Adam

Hey everyone, After reading the documentation and various topics here, I still have a few questions concerning Repeat Groups and tables. -Are Repeat Groups in submodels essentially copied tables, meaning the submodel gets passed a clone of the top level's table? I guess I'm confused because of this sentence in the Reference Guide: If data should only exist on the top level, why not just reference it from the submodel? Sounds like the reference is discarded for a copy, which contradicts the first premise? - Or is the Repeat Group a "Table of references"? In which case it still seems overly complicated to me, couldn't we simply pass the name of the table, without having to pass all columns? Alternatively, why not adding the ability to reference a table from a submodel in the form "Location.Parent.Model.TableName"? The reason I'm asking is that I have a model with many submodels, that all need to access a huge data table. If I'm not mistaken, Repeat Groups require you to pass every single column to every single submodel by hand, since selecting multiple submodels and right-clicking to choose "Select referenced property" doesn't work. I ended up creating a state variable that copied the data table, which I can access from the submodels via "Location.Parent.Model.ArrayName". Although the information is then 'pulled', this sentence adds to the confusion: I might be overthinking this, but storing information in an entity that is sent into an object passes information without properties as well? I'd just like to understand Repeat Groups and moreover I'd like to be able to use the Search Step from the submodel, which doesn't work with the array. I might give the find step a shot at this. Sorry for the lengthy post - any insights are appreciated! -Phil

Here is a simple utility that will export, import and delete artifacts of your model. Here is a screen shot of the available capabilities. The code and DLL have can be found on SImio GitHub. Please find at this link: https://github.com/SimioLLC/ExportImportModelAddIn You will also find install instructions in the ReadMe. Here are the changes that have happend over time: Updated 2023-01-31....Added the ability to select multiple tables for export and delete table data functions. Updated 2022-10-05....Updated the exports to sort the data first my name and then export. This ensures that the data exported is in a consistent order. Updated 2021-12-07....Added the ability to select a table and then remove the data from the selected table. If a table name is not selected, all the tables in the model will have their data removed. Updated 2021-09-20....Added Update Model Properties (CSV). With this new method, you can import model properties into your model. If the file contains 3 fields...First is name, then type and last is default value. The only valid types are real, datetime, Boolean and everything else is string. If the model property already exists, it will only update the default value on the property. Note: The example assumes the field separator is a caret '^'. To change this, you need to change the delimiter field. Updated 2021-09-08....Updated the sequence of the exports, deletes and imports happen. When OK is pressed, first the exports are run, then deletes and finally the imports. With this change, I am able to Export Table to DB, Delete Table Data and Import Table from DB from in a single run. I typically do this when re-mapping auto creates elements. Since the table data need to be removed and recreated before mapping of the elements are correctly mapped. Updated 2021-09-06....Upgraded to .NET 4.7.2. Also, fixed the windows form so it displays correctly. When opened, the form should no longer need to be expanded to see all the options. Updated 2018-11-08....Added Export To CSV, Export To DB and Import From DB. Export To DB will create a table in the SQL Server database with the same table name as the table in Simio. The data columns will be of type nvarchar(max) and the default value will be the same as the default value in the Simio table. It is assumed that Simio desktop will still do the data validation, not the database. This feature is used to save the Simio data into a database so it is backed up and can be shared across users. Each time the Export To DB, if the table already exists, it is dropped, and a new table is created. This ensures that the data schemas match between the Simio model and the SQL Server database. Updated 2017-12-05....Fixed index issue with links import. Updated 2017-09-25....Fixed the import of lists. Updated 2017-07-14....Added the ability to auto generate and auto read files. Previously, the files needed to be created prior to running the add-in. Now, they will create by the export. Also, the import will retrieve the same file generated by the export. These options are available when the "Auto Generate and Read Files" option is selected. Updated 2017-07-13....Added the ability to multi-select options. Now, more than one option can be initiated when the OK button is selected. This will streamline the process of exporting, deleting and importing. This tool is very helpful for testing out your model with various configurations to ensure that runs properly under various object and/or data configuration. Updated 2017-07-11....Now supports exporting and importing of model properties, exporting and importing of table properties and delete table data. Updated 2017-06-22....Now supports exporting and importing of data tables using XML. This is simple way to export all the table data from one model and import the same data into a new model (assuming that the same tables schema exists in the new model). Updated 2017-01-27....Now supports exporting of object types using XML. This can be used with the new Configure Scheduling Resources in Simio 9.150 capabilities to define your own object type properties based on an XML document. Updated 2017-01-23....Now supports exporting and importing objects using XML. When using XML, property units are also exported and imported back in. Updated 2016-10-24....Updated files...Added support for repeating properties.

I know, the problem is that I want to do it just throught data tables. That example uses a fixed number of state variables That must be modified each time I ned to add or remove machines to the sequence, this is not scalable.

Here are 3 updates to the spreadsheet import: 1) There is a new sheet called "Verticies1" to the attached workbook. Using this sheet, you can add multiple vertices to a link. 2) If a link already exists in a model, the import will now deletes and re-adds the link using the new information from the spreadsheet. Previously, links were not updated, only added. 3) If you set a coordinate in the "Objects1" sheet to blank (or not a number), the value will be 0 if the object is being added. If the object is being updated, the coordinates for the object will be ignored and not updated on the object. Everything you should need is attach to this post. UPDATED: 2012-06-11.....Fix was made so a top level Repeating Group Property can be updated through the spreadsheet. There is not a mechanism to update the children(except for AssignmentsOnEntering and SecondaryResources repeating groups used by the RPsixample model...See post below). 2016-01-27...Remove attachments...Use attachments in Alan Sagan's post. 2016-10-24....See first post for latest files.

Hmmm, actually he didnt update the model, it works fine. What is the correct way to remove elements from a station? I can perhabs use transfer right? Can I destroy them?

If you happened to uninstall Simio without returning your roamed license, you need to in reinstall the same version in order to return the roamed license. If you just uninstalled Simio 4.79 or higher, you have another option. In the attached zip file (ReturnRoam.zip), there are 2 executables. Unzip these executable into the C:\ProgramData\Simio folder. Then, run the "ReturnROAM.exe". When prompted, select the license (simio-d = Design, simio-e = Team, simio=n = Enterprise) and the year.month that the sprint was released (e.g. Sprint 87 was released in 2013.04). Then press "Return ROAM". The executable will return the roam license. If successful, the following dialog will be displayed. If it is successful with returning the roam license, it will remove the roamed license parameters from the Simio.Settings file. ReturnROAM.zip

I call it cheating because you can't scale it properly. Attached is how I would rectify that (Check out the Parent_Model). Using an entity instead of a server is valid, as it posses functionality we can't get out of the server (heading etc.). While I agree with you about the technicality of the term sub-model, I disagree in your interpretation of its function. Any model that contains a logical flow and is made up of custom logic, that I use within another model, I just call sub-model (for better or worse). The rest I just consider to be part of the provided toolkit. "Sub-models" are incredibly useful, until you need to start to modify things inside them from the Parent model, or need to change their height within the sub-model (sub-models do not scale dimension wise at all, while retaining usefulness). 3DRotatingServer.spfx

We have expanded our API with Simio Version 5....Now we have the ability to add links to networks. This should drastically reduce the time needed to create a network. We also have the ability to modify the size of object through the API. The new files for version 5 are attached to this post. NOTE: If you are downloading just the assembly, there are couple of extra steps: 1) Extract "ImportObjectsAndLinksFromSpreadsheetAddIn.dll" from the "ImportObjectsAndLinksFromSpreadsheetDLL_V5.zip" into a temp folder (e.g. c:\temp). 2) Right-click the assembly and select properties. Then choose to "unblock" button and press apply. (only needed for Windows 7 and later). 3) Copy the assembly into "C:\Users\\Documents\SimioUserExtensions" 2016-01-27...Remove attachments...Use attachments in Alan Sagan's post.

The Extended Flow Library discussed in this thread is now obsolete. Most of its objects are now integrated into the Simio Flow Library or included in the new Candidate Library: http://www.simio.com/forums/viewtopic.php?f=36&t=1740 The built-in Flow library includes very powerful features and capability, but is currently limited in scope to just a few basic objects. While we are enhancing that built-in library based on your feedback, we have provided an extended set of flow-related objects. This library includes objects such as Solidifier, Liquefier, Filler, Extractor and Stockpile. A Solidifier can be used to convert a specified quantity of flow into discrete entities. A Liquefier converts a discrete entity into an outbound flow. The Filler is similar to a Combiner that combines input flow of a specified volume with a discrete entity and the combined entity departs the Filler. The Extractor is the flow equivalent of the Separator. It will separate a batch member entity from the parent entity, with the flow transfer of the batch member entity then discrete transfer of the parent entity once flow is complete. The Stockpile object is similar to a Tank with different animation graphics. ExtendedFlowLibrary.zip As we receive customer feedback on both the Flow Library and the Extended Flow Library we will probably build more of this type of capability directly into the Flow Library. But in the interim, hopefully this extended library will help in your modeling. Like all Simio-provided libraries, this library is open so you can look at how it was built, learn from it, and subclass your own objects to improve them. But unlike our built-in libraries, this is not fully supported (although we can provide some help) and we may not continue enhancing it, particularly if we decide to build this capability into the base Simio products. We are anxious to receive your feedback on this library.

The Combiner object in the standard library assumes that you have a parent entity representing a box or container and members representing the parts that are combined into the parent. In some cases you don't want to have a parent, you just have a number of entities that you want to temporarily join together and process as one. The attached project contains an object of type Node that represents a very simple Combiner and a TestModel to illustrate how it works. The node simply asks for a Batch Size and then holds the incoming entities until that batch size is reached. It creates a "normal" batch so it can be used with the Separator as long as you treat all outbound entities as the same. CombinerNode.spfx Requires Sprint 5.80 or later.

I haven't done routing using tables, but I have definitely done server based decisions where each server had a row in the table. And things from server properties to parameters used within the server logic were also in the same row. The search step in conjunction with logic that tells you what the parent object you are in is.... works wonders. It is a staple form of modelling for me now. It is far easier to control parameter values from a table, than via the UI. As to the usage of the API... as you might guess... the API is not advanced enough to create or even edit models. All of the model development is done via the GUI, and a single experiment is created (with relevant properties to drive it), as experiments can't be created via the API either. The API is then solely invoked to change the parameters in the experiment, and run the experiment. The CSVs written out from the experiment are then sucked into the program, and processed and displayed in graphs or available to be spat out into pre-made excel sheets. This reduces the requirement of running a model from needing knowledge of excel + simio (quite a bit of knowledge is required here), to solely needing to run the one custom app and understanding what all the parameters you change do (API can't pull out definition descriptions). The custom app obviously uses the Simio API, but at no time requires the user to open the Simio GUI or touch the model directly. It won't mean much, but attached are a few screenshots of what kind of data we put in and get out using the custom tool. As you can see, you can add multiple scenarios in, and do the same kind of scenario comparison, and even look at what is happening Gannt chart wise.

I would abandon using Simio's built-in elements and do this all in a process with repeat groups plus delay steps and custom token states as you describe in Option 1. You could use the search step to spawn a new token for each row in the repeat group which would provide scalability, which then gets a delay time randomized according to an input distribution for that row of the repeat group. At the end of the delay time it would trigger a failure. These tokens effectively become your timers instead of using timer elements. The failure could suspend this 'timer' process such that the other delays stop counting during a timer. This token would then loop back on itself, having a different delay again. However, my conclusion (but not implemented yet) was that I would use the 'non-scalable' approach. The reason for this is that adding more than 2-3 failure distributions is getting overly complex/detailed and isn't likely to add value and could even possibly subtract from it! Not only that but I've found that when I combine different types of events (in reality, not modelled) they almost always result in some fairly good erlang/exponential/log-normal distributions. These only need to be split out to remove multiple peaks rather than getting to the exact causes. Not only that, but I've often found that failure data (not models) is recorded very poorly, and often mis-reported. For example a 'slow operation' is instead recorded as a failure. Alternatively, short failures are not recorded at all because the operators are busy fixing the problem. Because of this going into the level of detail you've described is going beyond the quality of the data. If you actualy trust your failure data, by all means go to town with the scalable approach. If you were part of my firm, I would give you feedback along the lines of "never trust failure data" However, a colleague of mine does feel differently so this is not a hard and fast rule -- just my experience.

We monitor this forum frequently for inappropriate content and immediately remove any found. But if you find any before we do, please email us at support@simio.com and it will be removed immediately. We apologize if you find anything offensive.