When working with complex hierarchical models in FlexSim, referencing objects deep inside a structure can quickly become difficult to manage. When not using multiple centre port connections (which gets messy)  users often rely on manually created labels and pointers, but that in turn can  introduce extra work and inconsistency—especially when deciding whether a label should reference a single object or an array. This post describes a small set of user commands, packaged as an auto-installing user library, that automatically builds and maintains hierarchical object references based on each object’s role. The goal is simple: allow users to reference objects using intuitive chains like: current.printerCell.rewinder.turret without manually creating or maintaining those labels. What this does This system automatically: creates label pointers based on object roles (functionname) builds those references up the hierarchy optionally propagates system-level references downward handles single vs multiple objects automatically rebuilds everything on reset so it stays consistent How it is set up The functionality is delivered as: an auto-installing user library containing the commands a template container that includes: a reset trigger that calls: containerReset(current) predefined labels: functionname systemContainer Users can drop this container into their model and begin assigning functionname labels to objects. The rest is handled automatically at reset. Core concept Each object declares its role using a label such as: functionname = "rewinder" From this, the system builds references dynamically using only the tree hierarchy. A key point is that this is not limited to containers. Any object, including standard FlexSim fixed resources such as processors, sources, queues, and sinks, can and should also be given a functionname when you want it to participate in the reference structure. That means this system maps not just structure, but function. How it works 1. Reset seeds the reference map On reset, each relevant container calls: containerReset(current) This starts the process of rebuilding all references from the current tree structure. 2. Objects register themselves upward If an object has a non-empty functionname, it adds a reference to itself on the next relevant level above it. So if a rewinder contains a turret, the rewinder can gain: rewinder.turret 3. Non-functional levels are skipped If an intermediate object has no functionname, the logic recurses through it rather than making it part of the reference chain. That means purely structural levels can exist in the tree without cluttering the reference path. So a structure like: printerCell   └─ layoutContainer        └─ rewinder             └─ turret can still produce: printerCell.rewinder.turret even though layoutContainer exists physically in the tree. 4. System containers propagate references downward If an object has: systemContainer = true then its own functionname is pushed down to all contained objects. So if printerCell is marked as a system container, nested objects can directly reference: current.printerCell This makes it easy for deeply nested components to find the root system they belong to. 5. Repeated roles become arrays automatically If a label already points to one object and a second different object needs to be stored under the same role name, the value is automatically converted into an array. So if one rewinder contains multiple turrets, then: rewinder.turret becomes an array of turret pointers instead of a single pointer. Users do not need to decide this in advance. Works for both machines and factories A useful feature of this approach is that a “system” does not have to mean a single tightly integrated machine. A system can be: one complex interconnected machine acting as a whole one cell within a larger process a factory made up of linked but physically distinct cells As long as those objects live under a meaningful tree structure, the same logic works. A printer cell can be used as a standalone system, then placed inside a larger factory container and reset again to gain one more level of functional context. That makes the approach scalable from machine-level modeling to line-level or factory-level organization. Example model I’m also including an example printer cell model where the labels are not pre-populated. You can: open the model press Reset inspect the created labels on the objects Then you can place that same printer cell inside a factory container, reset again, and inspect the results after the hierarchy changes. That gives a simple way to see the library working in both a standalone and larger-system context. Implementation details Below are the three user commands that make this work. 1. containerReset(<container>) Purpose This is the reset entry point. It does three things: registers the current object upward on its parent if it has a functionname if the current object is a systemContainer, propagates a reference to itself downward through everything beneath it calls the recursive function that builds the rest of the pointer map below it So this command seeds both the upward and downward context, then delegates the deeper hierarchy building. 2. assertReference(<objectToAddReference>, <referenceName>, <referenceObject>) Purpose This utility adds a reference safely and automatically handles whether the label should be: a single pointer or an array of pointers If the label is empty, it stores a single object pointer. If it already points to a different object, it converts the value into an array. If it is already an array, it adds the new object only if it is not already present. This is what removes the need for users to decide ahead of time whether a role is unique or repeated. 3. assertallobjectpointers(<involved>, <container>) Purpose This is the recursive traversal function. It walks downward through the tree under container and looks for objects with a non-empty functionname. When it finds one, it adds a reference on current using that object’s function name. When it encounters an object with no functionname, it does not stop. Instead, it recurses further downward through that object’s children. This is the key to skipping non-functional levels in the tree. In effect, this command says: Starting from the current functional object, keep searching downward until you find the next lower functional objects, then create references to them. That is what allows the reference chain to reflect logical structure rather than every structural level. Why this is useful This approach gives you: cleaner, more readable code no manual label maintenance automatic support for one-or-many references a functional map of the model rather than just a physical tree better reuse of machines, cells, and factory-level groupings Instead of writing search logic, you can work with meaningful chains such as: current.printerCell.rewinder.turret Best practices Use role-based names Set functionname based on what the object does, not its instance name. Good examples: printerCell rewinder turret infeedQueue Less useful examples: object1 machineA testNode Be consistent across models If you reuse systems or templates, keep the same functionname values so code remains portable. Add functionname only where it adds value Not every object needs one. Use it on objects you want to reference directly in logic. Include fixed resources too Do not treat this as a container-only feature. Fixed resources such as processors, sources, queues, and sinks can also participate and often should as these will be the objects your want to setup, load or listen to. Use systemContainer deliberately Mark the objects that represent meaningful system roots. That may be a machine, a cell, a line, or a factory-level grouping. Expect arrays when a role repeats If multiple objects with the same function appear under the same functional parent, that reference will become an array. Keep the hierarchy meaningful Since this works purely from tree structure, the physical organization of the tree should support the logical organization of the model. Use it to remove search logic If you find yourself repeatedly searching for the same kind of object, that is often a sign that it should have a functionname. Summary This approach turns the model hierarchy into a self-maintaining functional reference map. By assigning functionname labels to meaningful objects and rebuilding relationships during reset with containerReset(current), the model can automatically expose useful object references without manual wiring. That works whether the model represents a single complex machine or a larger factory made up of linked but physically distinct cells. The result is cleaner code, easier maintenance, and a more consistent way to navigate hierarchical models.

  When modeling arrivals or failures, it is common to reuse the inter-arrival time distribution as the one used to sample the time to first event. Except for memoryless processes (e.g., negative exponential), this is not statistically correct and introduces a left-bias where early events occur sooner than they should. The user command in the attached library generates a statistically valid time-to-first-event distribution from a definition of inter-arrival times.   Problem Being Addressed Inter-arrival distributions describe time between events, not time to the first event Reusing the same distribution biases early arrivals/failures Bias is most visible in: Short simulation runs Models without warm-up periods Models initialized with work-in-progress What the Command Does The command generates a sample set for time to first event using inter-arrival data provided as: A FlexScript distribution expression (string) An array of inter-arrival samples An existing Empirical Distribution object The process: Generates a timeline of events using inter-arrival samples Selects random observation points along the timeline Measures time to the next event Stores these values in a new Empirical Distribution object Runs the Fit function to suggest a best-fit distribution and parameters Output A new Empirical Distribution representing time to first event A fitted distribution expression (name + parameters) suitable for direct use Option to sample empirically or via the fitted distribution Typical Use Cases Time to first failure fields Arrival processes where warm-up is undesirable Short-term forecasting models Models requiring statistically defensible early-run behavior Why Use This Approach Avoids bias introduced by reusing inter-arrival distributions Produces statistically defensible results Reduces reliance on warm-up periods Especially beneficial when early statistics matter   How to Use the Command Loading the attached user library will auto-install the required user commands. The command createTTFeventDist creates an Empirical Distribution that represents the time to first event, derived from an inter-arrival time definition. Parameters P1 (string) Name of the new Empirical Distribution object to create. P2 (overloaded) Definition of the inter-arrival times. One of: A FlexScript distribution expression (string) An array of inter-arrival samples The name of an existing Empirical Distribution object P3 (optional integer) Number of time-to-first-event samples to generate and store in the new Empirical Distribution. (Default is suitable for most use cases.) P4 (optional integer) Number of inter-arrival samples used to construct the event timeline. (Larger values improve stability at the cost of run time.)   Example: Time to First Failure from a Weibull Inter-Arrival Process Assume failures follow a Weibull inter-arrival distribution, but the model starts at an arbitrary point in time and does not use a warm-up period. Instead of reusing the Weibull distribution directly for the first failure, generate a statistically correct time-to-first-failure distribution.  Open a script window and run this command with the example parameters: createTTFeventDist( "FirstFailureDist", "weibull(0,120, 1.8)", 5000, 100000);   This command: Generates a large inter-arrival timeline from 100000 samples of  the Weibull distribution Samples valid times to the next failure Creates an Empirical Distribution named FirstFailureDist Fits a theoretical distribution and reports suggested parameters (eg.  beta(-0.08, 356.54, 1.20, 4.89)) Using the Result in the Model You can now use the generated distribution in either of the following ways: Use the fitted distribution expression Copy the suggested distribution name and parameters into a Time to First Failure or arrival field. Reference the Empirical Distribution directly Sample from the Empirical object where a time-to-first-event value is required, choosing either: Fitted distribution sampling, or Empirical data sampling Both approaches ensure the first event is statistically consistent with the defined inter-arrival process.

This model is a proof-of-concept example demonstrating the integration of FlexSim with Python's Pyomo package to solve the Knapsack Problem. The model simulates a loading process of a logistic company. The truck has a weight capacity of 200 kg. The scenario includes 15 products, each with a specific weight and value. The product details are as follows: The objective is to determine which products to load onto the truck to maximize the total value of goods while ensuring the total weight does not exceed 200 kg. The ProductCreation Process Flow creates the products in a Queue. The General Process Flow has a Custom Code that creates a couple of Maps to store the products weights and values. It sets the capacity variable from the Parameters Table. These three parameters can be passed to python. Then it evaluates KnapsackProblem label on the Process Flow, passing those parameters in. The label is configured to connect to the KnapsackProblem function defined in the KnapsackProblem.py module. This function formulates the Knapsack Problem with Pyomo, solves the program, and then returns the optimal collection of products to be load onto the truck. Since the Decision Variables are binary, once the products are resolved, the values are stored in a Global Table, where 1 means that the product was selected. A Combiner uses this table to set the Component List. A forklift load the products and once completed, the truck leaves. When it enters the Sink a message is displayed showing the total weight and value loaded. Model Parameters There are two parameters that can be changed in this model. One is the Truck Capacity, which is the constraint of this problem. The value ranges from 100 to 300. There are three Global Tables in this model that store a different set of Weights and Values for each products. The table selected for the problem can also be changed using the GUI. Potential additions to this model could use priority for the products or include multiple trucks or constraints such as volume. Requirements to run the model In order to run this model, you need python properly configured, including: Install one of these python versions: 3.9, 3.10, 3.11 Install pyomo and highspy packages: python -m pip install pyomo highspy Make sure the python directory is part of your PATH environment variable. Configure your Global Preferences (the Code tab) to use the associated python version. This model was built in FlexSim 24.0 Knapsack_Problem.zip Troubleshooting If you are getting this error: exception: Code Binding Error: could not bind to function Node: /Tools/ProcessFlow/ProcessFlow>labels/KnapsackProblem Binding string: /**external python: */ /**/"KnapsackProblem"/**/ /** \nfunction name:*/ /**/"KnapsackProblem"/**/ Windows Error Code : 126 Check this post

Example Usage of the New AutoCAD FlexScript API The following example models were demonstrated at the Autodesk University presentation Elevating Factory Design: FlexSim and the Future of Autodesk Fusion Digital Factory. Refer to that presentation for a demo of these models and additional discussion regarding the topics demonstrated by these examples. These examples require the Autodesk Interop FlexSim Module. Healthcare Auto-Build Example Demo_AutoCadAPI_ER_4.fsm Using the new AutoCAD FlexScript API, the data within dwg files can be read using FlexScript to automatically build simulation objects within the model. The script in this Healthcare example is contained in the AutoBuildFromDwg() user command in the Toolbox. This command reads the average location of blocks on the Bed Layer to create Bed Location objects. It also reads the lines on the Wall Layer to automatically create Wall objects and connect them to the A* Navigator for automatic pathfinding around the walls. Reading dwg data string filePath = param(1); AutoCAD.Database db = AutoCAD.Database(filePath); if (!db)             return -1; var iter = db.getBlockTable().getAt("*MODEL_SPACE").newIterator(); for (iter.start(); !iter.done(); iter.step()) {             var ent = iter.getEntity();             print("Entity:", ent.layer, ent.objectType);             if (ent.layer == "Bed Layer") {                         if (ent.is(AutoCAD.Polyline)) {                                     AutoCAD.Polyline polyline = ent.as(AutoCAD.Polyline);                         }             } } Creating a bed location treenode bedConfig = library().find("/people/Objects/Location>behaviour/eventfunctions/configs/Bed"); Object obj = Object.create("People::Location"); function_s(obj, "changeShape", bedConfig); Creating walls Object walls = Model.find("Walls"); if (walls) walls.destroy(); walls = Object.create("People::Walls"); treenode wallsSurrogate = walls.find(">visual/drawsurrogate"); Object libraryPillar = node("/?Pillar", library()); Object newPillar1 = createinstance(libraryPillar, wallsSurrogate); newPillar1.setLocation(0.0, 0.0, 0.0); Object newPillar2 = createinstance(libraryPillar, wallsSurrogate); newPillar2.setLocation(10.0, 0.0, 0.0); function_s(walls, "addWall", newPillar1, newPillar2); Asserting the A* Navigator, a Grid, and connecting Walls Object walls = Model.find("Walls"); Object aStarNavigator = model().find("AStarNavigator"); if (!aStarNavigator) {             aStarNavigator = createinstance(library().find("?AStarNavigator"), model()); } Object grid = aStarNavigator.find("Grid1"); if (!grid) {             grid = function_s(aStarNavigator, "createGrid", 0, 0, 0, 1, 1, 0);             grid.name = "Grid1"; } contextdragconnection(grid, walls, "A"); AGV Read/Write Dynamic Blocks Example POC_OHT_3_MoveOHB.fsm POC_OHT_3_MoveOHB.dwg (If this file is named differently when you download it from Answers, make sure you name it back to this exact name. It is referenced by name in the model.) The script in this AGV example is contained in the interopAutoCAD() user command in the Toolbox. This command reads the location and names of particular dynamic blocks in the dwg file in order to automatically create AGV path simulation objects based on the configuration of each type of dynamic block. Additionally, the script has examples of both reading data and writing data back to the dwg based on modifications of the AGV paths within the simulation. The script is only partially complete as a demonstration of the API’s capabilities; the script is not a fully-working, robust solution for any arbitrary dwg. Factory Design Utilities Proof of Concept Example Demo_AutoCadAPI_FDU_1.fsm This FDU example model contains many user commands in the Toolbox with various functionality. The primary example starts in the Load FDU Layout button’s OnPress code. By default, it calls the AutoBuildFromDwg() user command. Alternatively, it has unreachable example code for calling AutoBuildFromLayout(), which can read the layout data from an FDU LayoutData xml file rather than a dwg file. The AutoBuildFromDwg() user command reads factory-specific meta-data about each FDU block in the dwg file and automatically creates simulation objects for each. The simulation objects then load the custom 3D shapes from FDU representing each of those objects. The import script also sets labels with the various Factory properties from each object. Within the CreateSimulationObjects() and CreateInternalObjects() user commands—called from the CreateFactoryAssetInstance() command—are hard-coded checks for particularly factory asset family ids to determine what type of simulation objects to create. This is merely a proof-of-concept example for handling FDU assets via FlexScript without any changes to FDU assets themselves. Future enhancements may include options for including such simulation meta-data within FDU assets directly for a more robust, easier-to-use solution. This workflow brings all the new Autodesk interop features together for an exciting, new way to bring factory data into FlexSim. Once that data is in FlexSim, you can use its many existing features to analyze the system with live 3D animation and dashboard charts showing simulation results. You can validate the throughput of the layout, identify potential bottlenecks, and balance resource use.

This article explores creating Fluid Tanks from a Basic FR and Process Flow. This turned out to be a lot more complicated than I thought. If you need fluid objects in FlexSim, use the standard fluid objects in the library or buy FloWorks. The approach in this article requires a lot of up-front work just to get started, and you probably want to spend that time configuring well-tested objects instead of cutting your own path. This article is directed at two audiences: Those who don't want to use the fluid library or FloWorks (they have elected the way of pain) Those who like learning from example models If you are still interested, read on! TankDemo_10.fsm Kinetic Tracked Variables Tracked Variables hold a number. As you change the value, the Tracked Variable tracks the min, max, average, etc. You can optionally track the history of the value over time (this history) or the amount of time spent at specific values (the profile). You can also listen to when a Tracked Variable changes. A special kind of Tracked Variable is a Kinetic Tracked Variable (KTV). A KTV lets you set a rate. The rate is the ratio of the change in value divided by the change in model time units. If you set a rate, the KTV records when you set the rate and the initial value. In this way, you can as a KTV for its value at any point and get the exact continuous value. KTVs are the heart of this model. You can use a KTV as a label value. Each tank has a label called "Level" that is a KTV that holds the level of the tank. They are also used to represent the progress of a transfer of fluid between tanks. Custom Draw The fluid tanks you see in the model are BasicFR objects. The shape of the object is set to a cylinder. The color of the object determines the color of the fluid. To draw the changing fluid level, the OnDraw trigger of the tanks use the Level label to determine the height of the fluid. Then the OnDraw trigger draws a cylinder covering the remainder of the tank. Because the draw code accesses the Level label's value, the cylinder will change as the value of the Level label changes. Tank: An Object Process Flow Most of the logic in this model is defined in an Object Process Flow called Tank. I used an Object Process Flow so that it would be easy to attach other objects to the flow to imbue them with fluid tank logic. In a way, it's like defining a programming class. When you attach an object, you create an instance of that class. The Tank flow defines behavior for a general fluid tank: A Tank can have fluid transferred in, out, or both A transfer indicates a source tank and a destination tank, and amount, and a rate. If the source tank is null, then the fluid is generated in the tank. If the destination tank is null, fluid is consumed in the tank. A tank can have as many active transfers as the user adds to it. There's not an accompanying concept of "pipes" in this setup. Each transfer changes the rate of the Level KTV for each tank. If the tank gets full, input transfers are paused until the the tank empties below a threshold (95% of its capacity). If the tank gets empty, output transfers are paused until the tank fills above a threshold (5% of its capacity). If the tank is stopped, both input and output transfers are paused until the tank is resumed. The Model Logic The model logic is contained in the process flow called Process Flow. It picks a random recipe from the Recipes table and uses that to create transfers into the Mixer tank. Once those transfers are complete, the Mixer tank empties itself. When it's completely empty, the tank produces an item. Then that process repeats. By using an Object Process Flow, the logic for "how to tanks work in general" is separated from "what are the tanks doing." Pros and Cons The main con is that you would need to implement this logic yourself rather than starting with an object. This includes finding and fixing bugs. I have found and fixed many bugs in this demo model, but I'm fairly confident there are more. It turns out creating an object is tricky. However, there are a few pros: Compared to the fluid library, there is no ticker. The fluid library relies on a ticker to handle changes in level. This approach uses KTVs instead. KTVs are newer than the fluid library. A ticker adds a frequent event to the model and loops through fluid objects checking for changes. It is possible that the approach in this article is more accurate and faster to run. It's also possible that it's slower, due to the number of process flow activities. Compared to FloWorks, there is no monetary cost. This may actually be a con as time spent developing logic is an expense. This approach will take 10x longer or worse to get right. Your future self will thank you for just buying it. You have full control over the behavior. If you don't like how something works, or you want to add additional logic, the logic is all available for you to edit. Again, this might be a con, because you have to fix bugs as you make them. Conclusion Overall, this demo model shows lots of FlexSim features working together. That is valuable in itself. As a replacement for fluid objects, this demo model isn't a great route, unless you have very specific needs. As I built this model, I realized that I was probably solving the same set of issues that the developers of the fluid library were solving. What I thought was going to be somewhat simple turned out more complicated. I still think this is doable, but I'd look at other options very carefully first.

When presenting and/or demonstrating a FlexSim model, it is often useful to have the model running in a loop that uses a flypath for a motion path. That way, you can more easily talk to the model while it runs, or leave it running unattended on repeat. The model below provides the code and settings needed to do that. In order to add this capability to your model, you will need to add a few things: A user event called EndTime. This setting will affect how long the model runs before resetting and running again. The First Event Time setting is where you can enter the number of seconds before this happens. The Event Code setting is where you can add custom code from the attached example model, found in the "event" tab. Model trigger code within OnRunStart and OnRunStop. This code can be found in the attached example model. A global variable called demo_mode. This can be set to 1 to enable the demo mode functionality, or set to 0 to disable it. Running the model with demo mode disabled is the same as how the model normally functions. Thanks to @Phil BoBo for helping to develop a solution for this. Also, the model requires FlexSim 23.2 or newer to work properly. presentation_demo_mode.fsm

This demo model shows the type of material handling logic that would be found in Bombay sorter system. This tiered conveyor system has products lined up in rows, then drop onto the next conveyor below while staying as a row. More a proof of concept than a fully-featured sample model, FlexSim users can use this as a springboard for more complex horizontal loop conveyor systems. A Bombay sorter (also known as a flat sorter) is a horizontal loop-style sorter. It's used for high-speed automated sortation of small, lightweight items, such as pharmaceuticals, books, and other small parcels. The chutes or cartons are located below the sorter, and when the product is in position, the doors swing open like a trap door to divert the product to the correct location. Bombay-sorter-demo.fsm

Note: the demo models were created specifically for the FlexSim user community who speak spanish, and all the explanations, statistics, and documentation available in the dashboard, GUIs, and Model Documentation are in Spanish. Nonetheless, given that 3D animation is a universal language, you are welcome to download these models regardless of the language you speak. Manipulación de material / Material handling Demo_Crossdocking.fsm En este modelo, llegan tres tipos de productos a dos zona de recepción. Un primer grupo de operarios se encarga de transportarlos a una zona de almacenamiento intermedio. Desde allí, otro grupo de operarios los clasifica según la ciudad a la que serán despachados. In this model, three types of products arrive at two reception areas. A first group of operators transports them to an intermediate storage area, where another group of workers sorts them according to the city they will be delivered to. Preparación de pedidos / Picking Demo_Picking.fsm En este modelo, los pedidos llegan de manera aleatoria a lo largo del día y son revisados y preparados por un operario. En este modelo, se puede modificar si los operarios realizan la preparación a pie o utilizando un vehículo, así como la ubicación del almacén de estibas y el número de operarios asignados. In this model, orders arrive randomly throughout the day, which are reviewed and prepared by an operator. In this model, you can change whether the operator does the picking on foot or using a vehicle, the location of the pallet zone, and the number of assigned operators. AGV - Vehículos de guiado automático Demo_AGV.fsm Este modelo demuestra la aplicación del módulo de AGVs de FlexSim, que permite simular sistemas que utilizan AGVs para el transporte automatizado de material. En este modelo, un AGV con capacidad para cinco productos se encarga de transportarlos entre dos zonas dentro de un proceso. This model demonstrates the application of the AGV module in FlexSim, which allows simulating systems that use AGVs for auomated material handling. In this model, an AGV with a capacity of five productos is responsible for transporting them between two zones within a process. Preparación de kits / Kitting Demo_Kitting.fsm Este modelo representa un proceso productivo que utiliza la técnica de preparación de pedidos. Mediante parámetros, es posible activar o desactivar estaciones de trabajo para evaluar el impacto en la productividad del proceso. This model represents a kitting process. Through parameters, it is possible to activate or deactivate workstations to evaluate the change in throughput statistics. Centro de vacunación / Vaccination center Demo_HC.fsm En este modelo se representan un sistema de atención de pacientes en un centro de vacunación. Los pacientes llegan de forma aleatoria, se registran y esperan hasta que una enfermera los vacune. This model represents a patient care system in a vaccination center. Patients arrive randomly, complete a registration process, and wait until they are vaccinated by a nurse. Cajero automático / ATM Demo_ATM.fsm En este modelo, se representan un sistema de retiro de dinero en cajeros automáticos (ATMs). Los usuarios llegan de forma aleatoria y realizan un retiro si hay un cajero disponible; de lo contrario ,esperan en la fila. This model represents a cash withdrawal system at ATMs. Users arrive randomly and proceed with a withdrawal if a cash machine is available; otherwise, they wait in line. Fluidos / Fluid Library Demo_Fluidos.fsm Este modelo representa un sistema de embotellado. Se generan, mezclan, procesan y finalmente embotellan dos tipos de fluidos. Después de embotellados, un operario los transporta a la zona de empaque. This model represents a bottling system. Two types of fluids are generated, mixed, processed, and finally bottled. After bottling, they are transported to the packaging area by an operator. Navegador GIS / GIS Navigator Demo_GIS.fsm Este modelo muestra cómo se utiliza el módulo GIS de FlexSim para determinar la ubicación óptima de un nuevo almacén, teniendo en cuenta una red de distribución específica. This model demonstrates how the GIS module of FlexSim is used to determined the optimal location for a new warehouse, considering a specific distribution network.

Last year a teacher asked me how to simulate public bus transportation, so I created a small sample model of a bus line in Nantes (France). Although all input and output data in the model are labeled in French, I thought that it could be nice to share it here with the worldwide community as 3D visualization is a universal language. Here is the model updated for FlexSim 2023: public_bus_23_0.fsm To set the travel times between the bus stops, and the stop times, I used the bus timetable that was available online in this document: Depliant-L-95-Web-2e.pdf You can check in the simulation if your bus arrives on time: Among the parameters, you can set how many buses are available at each terminus at the beginning. Be careful, if you don't have enough buses, you will not be able to stick to the timetable ! The road is built with network nodes. A checkbox allows you to show/hide the map. A listbox allows you to switch between the 3 network view modes (all details shown / edges only / hide all network).

This model shows a simple way of bringing together all the separate picks in an order to be consolidated in a putwall. It also shows a great way of tracking flowitems while on a conveyor through the use of tracked variable labels. A side concept is that the order reserves a slot in a rack for all of the picks. Conveyor-Routing-Order-Consolidation.fsm

Attached is a simple example of using the GIS Module. It contains a GIS Map with 8 Cities represented as points connected by driving routes. gis_example.fsm The model's Process Flow randomly generates tokens, which create items to be carried by trucks from one city to another. After a delay, the item is removed from the model. This very simple example demonstrates how to use the GIS Module to model movement of items from sources to destinations without any FixedResource objects. All the logic can be done through Process Flow to control what happens in the model. This model also demonstrates the Min Scale and Max Scale properties of a GIS Map object. By default, as you zoom the 3D view in and out, the 3D shapes on a GIS map scale so that they remain the same size on the screen, like abstract flat billboard images. When you zoom far out, because the items remain the same size, they seem really big relative to the map. Similarly, when you zoom far in, because the items remain the same size, they seem really small relative to the map. The Map object has Min Scale and Max Scale properties to cap the scaling up and down of objects as you zoom in and out, so that they will only scale up to a certain size and only scale down to a certain size. This makes it so they scale within a certain range, but don't get too big or too small. If you set both of these values to a particular number, then they will not scale at all, but rather be that particular size.

This model showcases the latest enhancements to the mass flow conveyor object, found in FlexSim 2023 Update 1. See several new features in action, including the Randomized fill order and Width Rules for conveyors. Mass-Flow-Bottling-Demo_23-1.fsm

This sample model shows the flexibility and power of the mass flow conveyor object. It contains many examples of stations found in this production process, from depalletizing glass bottles all the way through final packaging. The model makes use of many custom shapes that add realism and visual appeal to the simulation. Mass-Flow-Bottling-Line-Custom-Shapes.fsm

Attached is an example simulation of a rail hump yard. Trains in this hump yard are processed in three stages: Arrival - A train engine delivers an arriving train into the arrival area of the yard and then leaves Classification - The shunt engine takes trains from the arrival area to the hump. From there the train is uncoupled into sets of cars for classification, and each set of cars 'falls' to its designated departure train and couples to it. Departure - Once a train has been composed, it is transferred to the departure area, where it waits a random time until departure. I've tried to keep the logic as simple as possible so you can understand the process flow. I've implemented no traffic control between train engines/shunt engine, so they will occasionally run over each other. However, I have used AGV routing constraints to dynamically block off sections of track that are filled by trains, so the engines will move around them. HumpYardSample.fsm

I created this custom visual tool because I had a situation where we needed to see the progress of activites in the 3D View. I basically just change the size of a plane based on the completion level and calculate a percentage. Model is attached and contains some explanations. Enjoy, Custom visual tool.fsm

This model shows a two-floor healthcare facility with an elevator connecting the two floors. Patients are moved on a gurney from different rooms and across floors. There is a dashboard with two checkboxes so you can turn on and off the visuals for the different floors. One unique feature of this model is that each patient has a constant companion who follows them throughout their care process. This could be used either to demonstrate that companions can be modeled in FlexSim, or as a basis for another modeler to copy. FlexSim-HC-2023-MultiFloor_With_Companion.fsm

This small model shows how to batch various parts together to form 'valid' combinations as they become available. This differs from a regular combiner where the component quantities are set in advance of the components being accepted in the combiner (often based on the type of item on port 1 entry). The valid combinations are shown as the quantities required for a number of products in a global table "ProductPartQuantitiesGrid": By referencing the first picture and this table, you may be able to see that the model first constructs 4x Product2 followed by one product1 and a Product3. In the background process we are creating a token for each product which is then trying to pull all the parts needed while competing with the other products. This part of the process could be constrained in some way, for example where there is a target for the number of each product to produce over a time period. So these tokens are being created in the Object Process Flow of the object we're calling OpportunityCombiner at time zero based on the table shown above: Instead of the normal array generation this model creates a table label of the required parts for a product and stores it on the token. For Product1 that looks like this: Tables aren't quite fully supported as labels yet so the syntax is a little odd when using them - in this case we do it like this: Table(token.partsTable)[1]["Part"]  // evaluates to 'F' Setting the labels up so that syntax works is a bit more complex. Note that the partsTable label is actually a pointer to the data table label on the token - called partsTableData. To get the view shown above you need to right click on the label partsTabelData and select "Explore As Table". Hopefully in the future this may be more streamlined if more people start using labels as tables. The grid table doesn't play nice with sql, so another table creates itself at reset with a structure that is sql friendly: That means the label table can be created with this query: SELECT Part,Quantity FROM ProductPartQuantities WHERE Product=$1.product What remains for the product token just involves getting the parts (a subflow) and them moving the array of all items to the combiner (a queue in the example); stacking them together and releasing to the conveyor before looping back to try and produce another. Below you see the main flow with four tokens - one for each product defined in the grid. The subflow to get parts reads the token's table of parts for its product, and tries to get the correct quantities for each. This is similar to @Jordan Johnson 's solution for pulling from multiple lists, but is instead considering the table of parts from one list rather than arrays of resource lists and quantities. The key aspects of this flow are that 1. the first loop in the check section leaves the parts on the list, while the 'commit' section removes them 2. we exit the check loop by using the pull timeout when we fail to pull the required quantity of a part type 3. those that fail listen for pushes to the parts list 4. success full product pulls insert the items pulled to the tokens label 'allItems' for later use. Attached is the model. It should be relatively simple to transfer the process and tables to another model. OpportunisticCombiner.fsm

This Kiva system demo model showcases some of the new AGV/AMR features that were added in FlexSim 2023, including new events and parameters to help with deadlock and allocation failure, and dynamic barrier management. You can update the layout through five parameters, and then click the “Build” button to re-build the system. FlexSim-2023-Kiva-System-Demo.fsm

This supply chain demonstration model shows both a visual and statistical representation of a company's stock and backorder from day-to-day. The goal of the model was to predict shortages and backorder trends due to COVID-related disruptions. FlexSim's 3D view is used in a novel way to visualize the current stock and demand for each product. Each queue represents a different product SKU and each box represents a product unit, with red indicating product demand and blue indicating product availability. This model also contains a comprehensive set of dashboards to help visualize and interpret the data. Logistics_Supply-Shortages-Stockouts_v22-2.fsm

A number of questions on the forum involve racks being service by a combination of shuttles and elevators. There are solutions involving network, Astar and AGV navigators, but for this example we’re just going to use TaskExecuter FlowItems and conveyors. The elevator system in particular, as described to me, seemed it would benefit from the flexibility conveyors offer – particularly spacing options, and the possibility of having dog/power-and-free based travel. For the pick face we can just use the slot and item locations to give the task executers travel command, and we can use kinematics for loading and unloading tasks. This removes the need for network nodes or control points at each location and allows fine positioning of a ‘two spot’ shuttle in front of the slot. The system has been put into a container to represent the cell/aisle and it is this object that is the instance member of the ShuttleSystemProcess process flow. The cell is designed to be duplicated with each cell becoming a new member instance of the single process flow. It comprises two racks, two elevators (conveyor loops), and a shuttle return queue (also a conveyor but with no roller visual). The system assumes that by the time an inbound item arrives at the pickup position it has been assigned a slot in one of the racks in the cell – so you should assign a slot in the normal way before it reaches a shuttle. You can additionally request items for picking out of the racks by pushing the item to the global list ItemsToPick. Currently each shuttle will store and/or pick one item in one trip with a dedicated position for each. When doing both in a single trip, the order in which this happens will depend where along the level the slots are located. In the event that there are no remaining tasks but items still need to exit the cell, the shuttles at the front of the queue will be asked to circulate empty through the system, thereby allowing the outbound items to advance to the exit position. The number of shuttles in the system is a process flow variable. In the example system there are elevators at each end of the rack(s) with a number of carriers to transport shuttles to the levels. Both elevators have a process flow variable for the number of carriers to be generated. Shuttles are not allowed to pick from the same level at the same time but in order to keep the up-elevator moving the carriers can unload the shuttle to the level even if another is active on that level. The shuttles only travel along the face of the rack in one direction towards the down-elevator and once are collected by a carrier the next shuttle on that level can start its operations. It is possible to run the system with only one rack should you wish to view the operations without the second rack obscuring your view. Since different applications will use different rack dimensions the cell has a label method called “configureToRack” which will align the conveyors and decision points to Rack1 based on the level heights and size of the racks that the user has set for Rack1. There may be some limits to very small sizes when the conveyor decision points overlap. The second rack will be configured during this method call to mirror Rack1. Here’s an example invocation of this method for an instance of the cell: Model.find("RackShuttleSystem").as(Object).configureToRack The shuttles need levels to be the same height along the length of the rack. Some effort was made to configure the system based on the shuttle and carrier sizes, so you can try adjusting those to suit your needs and hopefully the alignment will work as needed. The elevator conveyor and shuttle speeds are not set by the alignment method so you can edit those in the usual way. This is an example for both learning and perhaps as a starting point for any project should you find the approach suits your application, modelling style and skills. ShuttleLiftAndRack.fsm Time taken: 1 day to build the working model - plus another to work around holes api for auto-alignment code. 17Nov Updated: to initalize shuttles at the load point (via fast entry) added shuttleQheight label for use to set the returnQ height in the cell (used by the alignment method) added a process flow variable 'shuttleLoadTime' for the time to un/load items. aligned shuttle kinematics to the speed and acceleration of the TE FlowItem.