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

In a recent model I was building I needed a case packer that had some special abilities. This "Combiner" is different than a traditional library accessed Combiner because: 1) You can set how many containers can be packed at a time. (In my model 3 cases were packed simultaneously with each cycle. I call these "batches" in my logic. This variable is accessed as a label on the 3D object. 2) It assumes that all the flowitems being packed come from the same port, you can't have multiple sources of flowitems or have a recipe. Although it could be modified to allow for that. 3) It is very easy to set home many flowitems per container. This variable is accessed as a label on the 3D object. This could be changed easily as the itemtype or some other criteria changes while running the model. 4) If the flow of containers or flowitems is delayed, the machine can time out and release a partial batch or partially filled container. I have included a model control GUI so you can manually stop the sources and test this logic. Note the labels associated with max wait time in the object labels again. 5) After a batch of containers and flowitems has been collected, there is a RobotCycleTime that occurs that represents the moving of the flowitems into the containers, this time is ran one time for the entire batch. While this object may not be the final solution for a lot of instances, I believe that it is a good starting point for a lot of objects that will be needed in future models. The Process Flow is well documented to explain the logic. Note that this is an Object Process Flow and all instances will need to be connected to the logic in the process flow. CustomCasePacker.fsm 0

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

Attached are three models that can be used to see the VR capabilities of FlexSim. oculus-warehouse-demo4.fsm (built with FlexSim 7.7) oculustouchdemo-6.fsm (built with FlexSim 17.1) The zombie production game was also updated for VR. These models were primarily designed and tested with the Oculus Rift, but they work with the HTC Vive as well. The HTC Vive requires a more powerful graphics card than the Oculus Rift does to achieve similar performance. You need to maintain 90+ frames per second (File > Global Preferences > Graphics > Show FPS Counter) in order to avoid judder with the HTC Vive. The Oculus Rift will remain smooth at 45 FPS or higher due to asynchronous spacewarp in their driver. In any model in 17.1, you can teleport around by pointing and pressing the Vive touch pads or Oculus Touch thumb sticks as buttons. The position where the thumb presses the button on the Vive or the direction that the thumb stick is rotated on the Oculus Touch will affect the direction you are looking when you teleport. This control scheme is similar to the Oculus Home controls. Moving via teleporting minimizes the motion sickness felt by users who are unaccustomed to VR. In the touch demo model, you can push buttons to release conveyor merge lanes, move operator figurines to change the operator assignments, and control the crane. The code that handles the touch inputs is in the ModelOnPreDraw user command. See VR model custom code for a version of the model with more comments in the code. The warehouse demo model was built in 2015 and doesn’t have any interactive elements that work with the Oculus Touch or HTC Vive controllers. For optimal tracking, after you press the VR Mode button in FlexSim and put on the headset, make sure you recenter the headset in the VR settings while standing or sitting in the middle of your play area and looking straight forward. On the Vive, push the system button to open the Steam VR overlay, then press the Settings button near the bottom-right corner, then look straight forward and press the Reset Seated Position button. On the Oculus, press the Oculus home button and then press the Reset View in App button in the upper-right corner.

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.

Attached is a simple model that implements functionality for "pallet moles." These are small vehicles that move pallets forward in a racking system. The targeted behavior is a FIFO storage mechanism like what you would see in gravity flow racks. However, for incredibly deep storage, a gravity flow mechanism would result in unacceptable pressures exerted on the pallets at the front of the rack, especially when pallets collide with each other as they roll down the slot. These pallet moles solve these issues. They provide the forward movement that enables FIFO storage, without the unacceptable pressures that come with gravity flow. The functionality is implemented as two object process flows, one for the rack, and one for the pallet mole. As such, it is scalable to higher numbers of racks and moles. Just add the set of racks/moles that your model uses, and then make sure those objects are attached as instances of their respective object process flow. Moles can be moved between different slots in the racking system. If a mole needs to move to a different slot, it will request transport from a team of fork lifts. The fork lift picks the mole up from the slot, and moves it to the destination slot. RackMole.fsm

Attached is a sample model that tracks social distancing metrics. I just grabbed one of our testing models, so it's not necessarily eye popping as far as visuals, but the basic concepts of social distancing metric tracking are in there. This model is implemented in the new 20.2 beta. It uses the new Agent module to detect proximity between objects. I added a proximity system, and added each operator as an agent in the system. I created an object that draws a "heat map" where proximity points happen. This is a visual tool called "HeatMap" in the model. If you send a message to the object it will add a "hot point" at the location of the sending object. I implemented the object's OnReset, OnMessage, and OnDraw triggers to do this. Once the heat map is set up, I have the proximity system send a message to the HeatMap from the involved agent object as part of it OnEnterProximity trigger. Second, I do some statistical tracking using a statistics collector named ProximityTimes. This listens to the agent proximity system's OnEnterProximity and OnExitProximity events, and collects data accordingly. The trickiest part to setting this up was sampling the actual event. For now (hopefully we'll get a better system in the future) you have to sample the event in the tree. In the Events tab of the statistics collector, press the sampler button, then in the tree navigate to the node at MODEL:/ProximitySystem>variables/behaviors/Proximity Behavior and hover the cursor over it to get the list of events. The ProximityTimes statistics collector collects individual times. This allowed me to add the "Time In Proximity" dashboard chart. For the other charts, I needed a calculated table to aggregate the values. The ProximityAggregates table aggregates the data needed for the other three dashboard charts: Total Proximity Time, Proximity Count, and Average Time In Proximity. SampleSocialDistancing.fsm

[ FlexSim 16.1.0 ] Attached is an example model that uses both of the new template process flows for AGV and AGV elevator control, available in FlexSim 2016 Update 1. Thanks @Katharina Albert (I believe), who provided the seed model, which I adjusted/extended as I implemented these process flows. This model enumerates many of the control point connections and path configurations you might use in an AGV model when using these template process flows.