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

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.

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

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

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

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.

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

As many of you have seen from our youtube video, we recently released an early beta version of a new FlexSim Agent module. This module can be downloaded from the Downloads section of your FlexSim account, under the Modules tab. Note that the Agent module will only work properly with FlexSim 20.1.1 or later. Here I'm posting some of the models I created and showed on the video. BasicProximitySystem.fsm TwoPhaseAGVSystem.fsm OnePhaseAGVSystem.fsm Boids.fsm AStarSystem.fsm RoomEvacuation.fsm HallwayTravel.fsm The AGV models aren't perfect (there's some tweaking needed, and there are some bugs that need to be fixed), put I'm putting them out there anyway. Since this is a beta version, I'm going to just upload unannounced module updates to the downloads section, so you can check the dates/versions on the downloads page against the version you have installed if you want to get the latest and greatest.

To go along with the launch of Flexsim 2018, we've put together a few sample models to show some of its features. Internet Cafe internetcafe.fsm This model shows off several of the new animations added to the Operator and Person flowitem. It also demonstrates how the Create Person activity can be used to attach a Person flowitem to an Instanced Process Flow. People with yellow shirts are attached to the ComputerUsers flow. They acquire a computer desk and then have an employee bring them over to their computer. Those in orange shirts are attached to the FoodCustomers flow. They buy drinks or snacks at the counter and then hang out at the tables. Casual Restaurant casualrestaurantredux.fsm Clinic clinic.fsm Grocery Store grocerystore.fsm Airport Security airportsecurity.fsm Bus Stop busstops.fsm

Note: these demo models have been designed for the French-speaking FlexSim user community (all explanations and statistics shown in dashboards are labeled in French). However as 3D animation is a universal language, feel free to download these models whatever language you speak. Manutention de marchandises / Material handling download link: https://redirect.flexsim.fr/download_demomanutention niveau: ★☆☆ Ce modèle donne une vue d'ensemble sur les ressources disponibles dans la librairie FlexSim pour transporter des produits: AGV, opérateur, cariste, ascenseur, robot 6 axes, pont roulant, transtockeur. This model gives an overview of available resources in the FlexSim library to transport products: AGV, operator, forklift, elevator, 6-axis robot, crane, ASRS. Triage sur convoyeur / Conveyor sorting system download link: https://redirect.flexsim.fr/download_demotriage niveau: ★★☆ Dans ce modèle, des colis arrivent sur un carrousel et sont triés sur un des 6 convoyeurs de sortie en fonction de leur référence de commande. Si la cellule photoélectrique du convoyeur de sortie est saturée, les colis font un tour de carrousel supplémentaire. In this model, packages arrive on a carousel and are sorted on one of the 6 exit conveyors, according to their order reference. If the exit conveyor's photocell is saturated, packages make an additional carousel lap. AGV - Automated Guided Vehicle download link: https://redirect.flexsim.fr/download_demoagv niveau: ★★★ Ce modèle illustre une application des capacités de simulation d'AGV de FlexSim. Des caisses y circulent entre divers modules via des AGVs. This model demonstrates a subset of FlexSim's AGV simulation capabilities. Loads are transported by AGVs between several modules. Workshop download link: https://redirect.flexsim.fr/download_demoworkshop niveau: ★★★ Ce modèle présente une approche possible pour simuler des gammes de fabrication. Une gamme est assignée à chaque produit entrant dans le modèle. Le produit traverse ensuite chaque étape de sa gamme. This model presents a possible approach for data-driven product routing. Each product moves through a series of processing steps defined in a table. Clinique / Clinic download link: https://redirect.flexsim.fr/download_democlinique niveau: ★☆☆ Ce modèle est un exemple de parcours patient dans une clinique: enregistrement, triage par une infirmière, examen par un médecin, soins (ECG, radio ou IRM) et enfin présentation du diagnostic au patient avant raccompagnement vers la sortie. This model is an example of patient flow in a clinic: sign in, triage by a nurse, consult with a doctor, treatment (EKG, X-ray or MRI) and finally patient education before escorting him to the exit.

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

Every now and then, there are technical support questions that are asked more than once by different users. This article seeks to address a couple of “how to” questions that have come up over time. As such, this isn’t a massively technical paper just a quick look at a few things that might make your modeling experience more fun and your models a little more interesting. Background: This is a physical screening clinic similar in nature to those you might encounter either in the military or in a hospital that supports a large industrial area where employee physicals are required either by insurance companies or an employer. That said, it could even be a part of a much larger function like an ER. In a nutshell, patients that represent a mixed population of both men and women, are sent to the clinic without an appointment and arrive according to an exponential distribution. In the model, the mix of men and women is 50-50 although it can be altered to accommodate any distribution of patients. Once a patient registers, he/she is either directed to a gender-specific changing room where they change into a white surgical gown, or take a seat in the waiting room until a changing room is available. Once changed, each patient is escorted to an exam room by one of two nurse practitioners, is examined for a time period that is also gender-specific (men – normal(20,5,1), women – normal(17,3,1)), and is eventually released to return to a changing room and finally to leave the clinic. Any time there is no changing room available, patients take a seat in the waiting room. The clinic opens at 0800 hrs and closes at either 1600 hrs or after 1600 hrs when the last patient departs. Open and run the model, “changing-rooms-model-11-16-2016.fsm” to see the model in operation. Modeling challenges: The challenges are straight-forward and not at all complex. Specifically, they address the following questions: How do you stop patient arrivals (e.g. in-flow) at a certain time of day and then close the clinic when the last patient departs? How do you make sure that patients go to their own gender-specific changing rooms? How do you change a patient’s shirt color to white representing a patient gown and then back to their original color when they change back into their street clothes? How do you use a patient label to determine treatment time if a distribution is contained in the label? Flow Chart: Before we dissect the model, it’s probably not a bad idea to take a close look at the flowchart if only because, despite the model’s size, it can seem a little complex. Notice that the changing rooms really are the central point in the model. As such, connecting lines have to be constructed that link the Registration Area (0ne way), the waiting room (two way), the exam area (two way) and the Patient exit (one way) with each of the Changing rooms. Setting the Stage: Because the purpose of this model is to make provisions for and track both male and female activities, it uses two different PCIs (Patient classification Index numbers) to represent Men (PCI1) and Women (PCI2). Those PCIs and any related labels that may generally carry information about patients that might be used for decision making later, are initially entered in the Track Manager, under the tab labeled, "Patient Classification” as shown to the right. Note that, in this case, there are fields for identifying which Track a specific PCI will follow, what each PCI’s Acuity will be, which Gender different PCI’s will represent, which distributions represent each PCI’s Exam Time in the model, and a direct reference to which changing room a patient should use. Needless to say, each of the three types of fields – text, number and code – are accessible from various elements of the model and may be used to determine and isolate almost any patient characteristic a modeler might use to define patient Activities. One other “setting the stage” aspect of the model that deserves mention is the positioning of the nurses. Note that the two nurses aren’t arrayed in a single line, the default positioning of resources in a model, but rather are positioned as if they're having a conversation. Although somewhat inconsequential when a resource staff is small, large collections of staff members cry out for better, more life-like poses. To change a resource’s initial location in a model relative to its home base - in other words, it’s “Offset” – first make sure the model is in “3D View” by clicking on View>Model View (3D) in the main menu. Then, simply click on the individual resource and drag it to the place you’d like it to stand as its initial position. Note that the X Offset, Y Offset and Rot Offset values that are unique to each member of a resource group, will automatically be changed to the new coordinates. Finally, note that by clicking and holding down your left mouse button over any of the Offset positioning arrows (circled in red above), and then moving your mouse forward and back, you can also manually reposition any specific resource. Arrival Pattern : Open the Properties window for the Patient Arrivals Object to follow this discussion . The Patient Arrival pattern is simple to construct, involving nothing more than identifying the correct exponential distribution (i.e. exponential(0,20,1)) in the Patient Arrivals Properties’ Interarrival Time field as shown at the left. Notice also that the Patient Classification Index (PCI) field contains an expression to calculate and therefore generate two different PCIs. As mentioned previously, PCI 1’s are classified as men and PCI 2’s as women. In this case P(50.00, 1, 50.00, 2) insures that a mix of 50% men and 50% women will be generated by the Patient Arrivals Object during the model run. Setting Certain Patient and Model Characteristics : The purpose of the Patient Arrivals object isn’t only to create a unique pattern of patient arrivals but also to serve as the source of every patient’s initial characteristics as well as set certain actions that affect the performance of the model as a whole. In this case, changes to the patient’s appearance and the stopping time for patient arrivals are both determined in two different Patient Arrivals’ Property Triggers as shown at the right. Note that the “On Creation” Trigger is used to identify any actions the modeler might want to activate that occur when a patient is created for entry into the model. As shown, picklist option can be used in the On Creation Trigger to change any number of model parameters In this model, only that referring to the patient’s shirt color is changed. In this case, there are three entries to select from … (1) the fact that the patient’s shirt color should be changed, (2) which color palette should be used to obtain the desired color (Palette2), and (3) which color (by index number) should be used. Note that the color index number is determined by the patient’s PCI of either 1 or 2. Different palettes unique to the software can be viewed by selecting, “Edit > Color Palettes,” from the software’s main menu. Note that new palettes and/or colors may be added to the color palette editor by selecting the appropriate functional options (ie. Add/Delete Palette, More/Less colors). In this case, Male patients will wear green shirts and female patients will wear yellow. Note that the “OnExit” Trigger is used to identify any actions the modeler might want to occur when a patient exits the Patient Arrival object. In this case, the picklist option, “Stop or Resume Flow” is selected to act as a brake for patient arrivals after a specified elapsed time. Although there are seven different drop down options to select from regarding the condition desired to stop patients from entering the model, the option “time()>960” is selected to stop arrivals at 1600 hrs (4 p.m.). Note that “960” represents the elapsed time in minutes since midnight (time 00:00) of the first day of the model run. Many first time modelers make the mistake of assuming that the time value represents the elapsed time since the model’s beginning time, in this case 8 a.m., which isn’t the case. In any event, this picklist option examines the time of every patient’s departure from the Patient Arrivals object and the first patient created at or after 1600 hrs, automatically stops any additional patients from being created. Closing the Clinic’s Doors and stopping the model . Open the Properties window for the Patient Exit object to follow this discussion. Clearly there are two actions that are required to close the clinic at or after 4 p.m. when the last patient departs. The first is to close the front door which is accomplished by the “OnExit” Trigger found in the Patient Arrivals object as discussed in paragraph 5B above. The second is accomplished in the Patient Exit object’s “OnEntry” Trigger as shown at the right. In this case, the drop down picklist option, “Stop Model Based on Condition,” is selected and used to establish two criteria for the model’s end. The first criteria is that the elapsed time be later than 4 p.m. and the second is that there be no patients in the clinic when 4 p.m. arrives. The correct entry for the picklist option then, is shown at the left and takes both circumstances into account. What it determines every time a patient leaves the clinic is, what time it is and if anyone remains to complete treatment at that time. If the time is even a second past 4 p.m. and the clinic census is zero, the expression stops the model. So far, we’ve accomplished several tasks that include, (1) setting the patient’s shirt color, (2) establishing a criterion for closing the clinic door at 4 p.m. and stopping clinic operations at or after 4 p.m. when the last patient leaves, and (3) positioning resources at various places in the model rather than in a single straight line. Now, we need to change the patient’s shirt color to white – symbolizing changing into an examination gown – and back to its original color when the exam is over, and determine the patient’s Exam Time. It’s a simple process that we’ll cover in Activities 40, 60 and 80. Activity 10_Arrival: This activity causes the patient to walk unescorted from the Patient Arrival Object to the Registration Area. Although there’s nothing complex or unfamiliar about the activity, it’s important to note that even though this activity has no predecessors, a check mark is still required in the Predecessors box to cause the model to begin this activity without a command from some other activity. Activity 20_Registration : This activity causes the patient to use someone from the ClerkGroup at the Registration desk for normal(2,1,1) minutes to log in. Activity 30_TravelToChange1:This activity causes the patient to walk unescorted to one of the two changing rooms based on the patient’s sex. As such, which of the changing rooms is determined by the entry in the Patient Destination field, in this case, from the drop down picklist option, “Based on a Condition,” and by the edited drop down option, “getlabelnum(patient, "Gender") == 1 as shown to the right. Note that there are actually 12 different, “Choose a Condition” options the modeler can employ to set the patient’s destination. Activity 40_Change1 : This activity causes the patient to take normal(3,1,1) minutes to change into an examination gown and changes the patient’s shirt color from either green or yellow to white representing that change. The expression that causes the color change is contained in the Advanced Function, “Activity Finished Trigger.” In this case, the drop down picklist option, “Set Color” is selected to change a patient’s shirt to white as shown to the right. White is the color whose index number is 15 in the color palette 3. Activity 50_TvlToExam: This activity causes the patient to be escorted by a member of the NurseGroup from the changing room to the first available Exam room. Activity 60_Exam : This activity causes the patient to spend a period of time specified in the Processing Time field being examined by the same nurse that escorted them to the Exam room. Note that the exam time is entered by selecting the drop down picklist option, “Based on Patient’s Label,” and then by selecting the Patient Label, “ExamTime,“ that was previously set in the Patient Classification Index (PCI) Table. See Paragraph 3 above. Activity 70_TvlToChange2 : This activity causes the patient to walk unescorted to one of the two specifically named changing rooms. As such, which of the changing rooms is determined by the entry in the Patient Destination field, in this case, from the drop down picklist option, “Based on a Condition,” and by the edited drop down option, “getlabelnum(patient, "Gender") == 1 as shown to the right. See paragraph 7C for the same logic initially entering a changing room. Activity 80_Change2 : This activity causes the patient to take normal(3,1,1) minutes to change out of their examination gown and back into their street clothes by changing the patient’s shirt color from white back to their original color. The expression that causes the color change is contained in the Advanced Function, “Activity Finished Trigger.” In this case, the drop down picklist option, “Set Color” is again selected to change a patient’s shirt to its original color using the patient’s PCI number. Note that this is the same way the shirt color was assigned initially. See paragraph 5A Activity 90_Departure: This activity causes the patient to walk unescorted to the clinic exit and leave the model. Special Notes regarding the Changing Room model . As simple as the model may seem, it serves to reinforce several modeling techniques that we sometimes overlook. For example, … All activities are assigned unique Milestone names. In this case, TvlToChange1 and TvlToChange2 are identical in every respect. However, Change1 and Change 2 aren’t. To combine the four different activities into two identical activities would change the Patient Timeline widget in the Dashboard so that a patient’s time spent waiting for a nurse following the first Change would be combined as a single display element. This might make it difficult to glean specific information from the Timeline regarding total time changing and waiting for resources. The use of floor displays and walls to enhance a model’s appearance is highly encouraged. To design effective and realistic models, practice using the Infrastructure tools to create underlying floors and the Library tool, “Visual Objects,” to create enclosures.

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 model is a proof-of-concept example for combining FlexSim's GIS features with the power of mixed integer programming in python. The model simulates a distribution network of 'factories' (red icons) and 'warehouses' (blue icons). The factories produce the product you are selling, and then distribute the product to various warehouses in the network. Every day, each warehouse generates a random demand for the product. Once demand from each warehouse is known, the 'demand dispatcher' must determine which factory should produce and ship how much of the product to each warehouse, fulfilling all warehouses' demands at minimum total cost. Each factory has a maximum daily capacity of production and a per-unit cost of production. In addition, shipping costs must be taken into account from each factory to each warehouse. Given these factors and constraints, the problem of optimal dispatching boils down to the well-known min cost flow problem in optimization. I've created a simple python script that uses cvxpy to solve this min cost flow problem as a mixed integer program. The MIP is not exactly the same as the standard min cost flow problem, since total factory capacity may be more than total warehouse demand, and I'm using integer instead of continuous variables. Nevertheless, it is sufficient to demonstrate the capability. The Warehouse process flow generates daily demand for each warehouse and pushes it to a shared Demand list. The DemandDispatcher then pulls demand from the list, and marshals capacity, demand, and cost data into parameters that can be passed to python. Then it evaluates getMinCostFlow label on the process flow, passing those parameters in. The label is configured to connect to the getMinCostFlow function defined in the MinCostFlow.py module. This function formulates the MIP with cvxpy, solves the program, and then returns the optimal shipping quantities for each factory-warehouse pair, returning control back to FlexSim. Once the shipping quantities have been resolved, the DemandDispatcher process flow creates and labels 'Trucks' that are sent to each warehouse. Note that this travel mechanism is purely for animation purposes, letting you visualize how much product is being sent from factories to warehouses each day. Potential additions to this model could use inventory management strategies, simulating randomized lead times, etc. I've added several dashboards that show the cumulative average breakout for each warehouse of which factories supply that warehouse, as well as the cumulative average breakout for each factory of which warehouses that factory supplies. I've also added costing measures for the warehouses and factories. Some interesting insights that can be gleaned from this model are how shipping vs. production costs affect the balance of which factories will ship to which warehouses. For example, if your shipping costs are low relative to your production costs, then the min cost flow algorithm will push production to factories that are the lowest cost to produce, even if they are far away from the destination warehouse. High production cost factories are consequently relegated to little if any production. However, if shipping costs are high, the algorithm will localize production to the factories nearest their respective warehouses. In order to run this model, you need python properly configured, including: Install one of these python versions: 3.7, 3.8, 3.9, 3.10 Install the cvxpy and cvxopt packages: python -m pip install cvxpy cvxopt 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 22.1. MinCostFlow.zip

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