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.

O link que segue leva a um vídeo no qual é apresentada UMA entre várias formas de criar a lógica de alocação de peças no Rack. Os tópicos abordados no vídeo são: Objeto Rack Configurações lógicas do Rack Exemplo prático Vídeo Tutorial: https://youtu.be/tTeRwjt--Eo

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

O link abaixo, remete a um vídeo onde mostramos como usar o recurso paths para criar o percurso que recursos e pacientes devem seguir durante o fluxo dentro de um hospital, respeitando os limites dos layouts feito em Autocad e, o impacto nos indicadores usando o dashboard para análise. Vídeo Tutorial: FlexSim Healthcare - Parte II Esperamos que aproveitem esses vídeos com algumas dicas simples.

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.

The ideal way to access the User Manual is by viewing an electronic copy either online or inside the software. Online User Manual The User Manual is available online at docs.flexsim.com. There you can select a software version and manual language. We hope to provide additional languages in the future. In-software User Manual There are two ways to open the manual inside FlexSim: Click the User Manual button on the main toolbar. Click the Help menu and then click User Manual. Why the electronic manual is preferred The online / in-software version of the User Manual is better than a print or PDF version for many reasons, including: Regular updates - The electronic version keeps up with every new FlexSim release. A printed manual unfortunately goes out of date every four months with each new release of FlexSim. The online manual allows you to also view older versions of the manual. Animated GIFs - Animations enhance communication by making it possible to see FlexSim in real time. Animated GIFs won't work in a printed copy. Better search - The online version allows you to search the manual using Google. The in-software version also has a search program which is easier than trying to find relevant keywords within a large document. Styled and reflowable tables, images, and tip boxes - While these elements look good on the web, print or PDF versions don't always correctly format their placement within the document. Better organization - A printed manual won’t always maintain the same organization as the online and in-software manual, making it more difficult to navigate. Mini-table of contents - Each topic has easy navigation within each topic via inner-links. A printed or PDF mini-table of contents (found in most topics) can't function as a clickable index, making it difficult to easily skip to relevant sections within a topic. Printing topics from the User Manual While we don't recommend printing the entire manual, you can easily print individual topics for later reference. Print from the online manual Visit docs.flexsim.com using your favorite modern web browser. Use the table of contents in the left navigation bar to visit the topic you want to print. Use the printer button in the upper right of the topic window to print the page: Print from the in-software manual In FlexSim, open the User Manual and browse to the topic you'd like to print. Press the 'world' button to open the topic in your web browser. Choose the print function inside your web browser - depending on your browser, you may be able to right-click the web page and choose Print, or you can use the keyboard combo Ctrl+P.

Release Notes If you have bug reports or other feedback on the software, please email dev@flexsim.com or create a new idea in the Development space.

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

O presente tutorial tem como objetivo explicar o significado dos principais estados assumidos pelos objetos padrões do FlexSim em um modelo convencional que contenha tanto objetos fixos (Fixed Resources), quanto executadores de tarefas (Task Executers). Link para o vídeo: Explicação dos Principais Estados no FlexSim Obrigado.

O link que segue leva a um vídeo no qual é apresentado uma introdução à nova ferramenta do FlexSim, o Statistics Collector. No vídeo, explica-se quais são as configurações básicas da ferramenta. Também pode-se acompanhar um exemplo simples, desde a coleta de uma estatística básica, até a apresentação dos dados em um gráfico, do tipo histograma. Vídeo Tutorial: Overview sobre Statistics Collector Esperamos que aproveitem mais este vídeo tutorial.

Help->License Activation" />Open FlexSim Software. Click Help in the main menu. Choose License Activation. Click the Return tab. Each of your activated licenses will be listed in the dropdown selector. Select a license you want to return. Click the Return button. Please wait while your FlexSim Software communicates with the license server. The status text will update, and should end with an indication of success. Repeat to return any other Activation IDs that need to be returned. If you have any questions or problems, please search our Answers Community for possible solutions. There is a good chance someone else has already asked your question. Still not finding what you're looking for? Submit a new question and we'll check it out. If you're including any confidential information, such as license codes, be sure to mark your question as private! You can also contact your local FlexSim distributor for live phone, web, or email help.

Flexsim 2021 Update 2 is now available for download. You can view the Release Notes in the online user manual. For more in depth discussion and videos of the new features, check out the official software release page. If you have bug reports or other feedback on the software, please email dev@flexsim.com or create a new idea in the Development space.

We recently had a customer ask how to draw a flow item label on the flow item object. I thought that this information would be useful to other FlexSim users as well. In the 3D model, drag and drop a Text visual from the Library. Select the text in the 3D model, then copy it to the clipboard using Ctl + C Go to the Toolbox tab, open the FlowItem Bin, and double click the Flow Item of interest. Right click the 3D flow object, and click "Explore Tree" Click in the white space underneath the Flow Item's node, and use Ctl + V to paste the text as a subnode to the flow item. If you zoom out in the Flow Item's 3D view, you will see the text. You can double click on the text and use the General tab to position it wherever you would like. Double click the 3D Flow Item. Underneath the Labels tab, select the green plus sign to add your label. In my example, I added a number label called "Type" with a default setting of 0. Click "OK". Double click the text that you added in step 5 and 6. Underneath the Display tab, click the custom code button next to Text Display. Within the custom code type something like the following: /**Custom Code*/ Object current = ownerobject(c); treenode textnode = param(1); textnode.value = "Type: " + string.fromNum(current.up.Type); //Note: If your label is called something other than "Type", make sure to replace it in both places. Click out of the "FlowItem Bin" tab and back into the "Model" tab. Double click the source where your Flow Item is being created. Underneath the Triggers tab, add an On Creation trigger. Click the green plus next to the On Creation trigger. Hover over Data and select "Set Label". Make sure the text next to the Label field matches the text of the label you set in step 7 and 8. By following these steps, each Flow Item will have a text label that displays the Flow Item label next to the Flow Item object. Please see the attached gif for a demonstration. flowitem-label.gif

Attached is a sample model that uses Google's OR-Tools python module to find optimal AGV dispatching solutions. I recently stumbled on Google's OR-Tools, which includes several classes for finding optimal solutions to things like vehicle routing, scheduling, bin packing, etc. Since FlexSim now has a mechanism for easy connection to python, I decided to try and see if/how it could be connected to FlexSim for testing AGV dispatching strategies. I threw together this model just to see how/if the connection can work. All source/destination locations are chosen at random, and work inter-arrival rates are random with a user-defined mean inter-arrival time. To get this model running on your side: Install a version of python Run the following from the command-line: python -m pip install ortools In FlexSim, make sure your preferences are configured for the correct version of python, and that python is part of your PATH environment variable. Open the model. In the Parameters table, set DispatchMode to 'VRP Solver'. This model uses the Vehicle Routing Problem solver to find optimal AGV assignment strategies. The main work generation logic is in the 'Work Generation' process flow. At random intervals, work requests arrive. They are assigned to random source and destination locations. Then, when dispatching in 'VRP Solver' mode, the logic calls the optimizeVRP() user command. This command packages the current state of the model into a valid vehicle routing problem, and then passes it to the py_optimizeVRP() user command, which is implemented in python, in the AGVVRP.py file. The command creates the VRP problem using the OR-Tools classes, and then calls the solver, returning the results. OptimizeVRP() then interprets the results and assigns AGVs as needed. Note that the VRP is re-solved every time new work arrives. You'll see little 'freezes' in the execution of the model, because it is solving the VRP at each work arrival. Note that the standard Vehicle Routing Problem is slightly different from the problem this model needs optimized: In an AGV model, there’s no depot. Instead AGVs may be currently located anywhere in the warehouse. There’s no ‘depot-loaded’ capacity of an AGV, and no ‘demand’ at customers. The standard VRP is a situation where trucks are loaded at the depot, and then depleted as they visit each customer in the route. This is not present with single-capacity AGVs. When an AGV picks up at an origin location, it must immediately deliver to the destination location. In order to wrangle the AGV problem into a valid vehicle routing problem that can be solved by OR-Tools, I constructed the problem as follows: I made each AGV’s ‘current location’ a node in the graph The distance from the depot to the AGV’s current location is 0 The distance from the depot to any other node in the graph is prohibitively large. This will cause vehicles to always go to their 'current location' first, with 0 cost. The distance from any node in the graph back to the depot is 0 A given AGV must visit its current location as part of its route. This can be added as a constraint to the problem in OR-Tools For immediate unload after loading, I initially tried adding this rule as a constraint, but the solver hung when solving. So, instead of graph nodes being locations in the facility, I made graph nodes represent ‘tasks’, i.e. visiting this node means picking up the item AND dropping it off. As such, the ‘cost’ of ‘visiting’ a ‘task’ node is the cost to travel from the ‘destination’ of the previous node to the ‘origin’ of this ‘task’ node, plus the cost to travel from the ‘origin’ of this task node to the destination of this ‘task’ node. Once I did this, OR-Tools was able to solve the problem 'optimally'. By optimally, I mean it was finding the AGV routing that minimized the maximum 'travel makespan', which is the maximum distance route of all of the AGVs. Once I had done this, I wanted to compared it with various heuristic-based scenarios. So I set up a 'Closest' dispatch mode. Here, when an AGV finishes a task, it will take up the next task whose pickup point is closest to its current position. I also created a 'FIFO' dispatching mode, which is that work will be dispatched to AGVs always in FIFO order. These three dispatching modes I compared with the experimenter. My initial experiments showed some interesting results. Most interesting was that in 'VRP Solver' mode, work task time-in-system was relatively high. This is because the objective function completely ignored time in system of the work, and was only optimizing for vehicle travel distance. So some work was being pushed off until much later because vehicles could get better travel distances by pushing it off. To account for this, I added a 'soft upper bound', which is kind of like a 'due date' for the work. Namely, work is due to be finished 800 'meters-of-agv-travel' after it arrives. This was a quick-and-dirty workaround and could certainly be improved, but it did serve to get the time in system for VRP Solver mode down. Below are some of the resulting experimenter results. AGVTaskTime - Time from starting a task to finishing it (i.e. a kind of takt time) The VRP solver performed the best across all scenarios here, and was especially better than the other strategies in low-demand scenarios. This intuitively makes sense. When there are a lot of under-utilized AGVs, the closest and FIFO strategies will always dispatch idle AGVs to do work, which could potentially make them travel long distances. However, the VRP solver can find opportunities to decrease travel distance by waiting to dispatch an AGV that will be near a task in the future, and leave other AGVs idle. Note that I think the 'closest' strategy only finds the 'closest' next task for an AGV that just finished a task, not the 'closest' idle AGV for an arriving task. Obviously that could be changed for a better performing 'closest' strategy. On the other hand, I think in this model all idle AGVs go back to the same park location, so such a change would require distributed park locations to take advantage of closer idle AGVs. AGVWorkStaytime - time-in-system for a given AGV task Here the 'closest' strategy actually performed better than the VRP. This would seem counter-intuitive at first, but upon further evaluation, it does make sense. The VRP, in its current form, only optimizes for total AGV travel distance. It completely ignores job time in system/due dates/etc. So the solver will always assign a route that is shorter even if that route pushes back jobs that have been in the queue for a long time. The solver also re-solves every time a new job arrives. So we may be having scenarios where some jobs are always 'better' to be pushed to the end of the route, and so they keep getting pushed back, resulting in poor time-in-system performance. The solver does include soft and hard job 'due dates', so we could make adjustments to the problem to make the VRP get better time-in-system results. AvgAGVUtilization AvgAGVUtilization is where the VRP especially shines in low-demand scenarios. It finds opportunities to leave AGVs parked because there will be opportunities for busy AGVs to take up jobs in the future with minimal extra travel overhead, whereas the 'FIFO' and 'Closest' strategies will always dispatch idle AGVs to unassigned jobs, causing extra unnecessary empty travel. I am still a bit perplexed by the high-demand scenarios though. Here the 'Closest' and 'FIFO' strategies both beat the VRP in the 120/hr and 102/hr scenarios. This probably would warrant further investigation as to why the other strategies do better here. It may be that, in these scenarios, the AGVs cannot keep up with demand. So there is a queue of jobs that is ever-increasing. The VRP solver is optimizing the full plan, meaning it is scheduling job assignments, and finding travel distance minimization opportunities, that are way out into the future. And it is not getting the opportunity to execute those optimized routes because the problem is being re-solved at each job arrival. With an increasing job queue, the 'closest' and 'fifo' strategies might be actually doing better specifically because they are short-sighted. Just take the closest job to you. On the other hand, if we have increasing job queues (i.e. the AGVs can't keep up), then the AGV utilization should be around 100% anyway, which it's not. Anyway, it's something still to churn on. ThroughputPerHour The throughput per hour indicator tells us whether the AGVs actually kept up with the jobs. If the AGVs were able to keep up with jobs, then the resulting means should be right around the scenario's throughput/hr number. It looks like FIFO got way behind on both the 120/hr and 102/hr scenarios. 'Closest' and VRP both got a little behind in the 120/hr scenarios. One exciting possibility of using this design is that the python script is not technically dependent on FlexSim. So you can use FlexSim to test your python-based optimization, and then you can deploy that python script in a live setting. AGVVehicleRoutingProblem.zip

Update: FloWorks 17.2.1 has been released on September 18. FloWorks 17.2.0 for FlexSim 2017 Update 2 has been released. This new version of FloWorks has some major changes to align it with recent updates to FlexSim, such as dot syntax, Process Flow templates, and a revised user manual. The bug fixes in this version are also available for FlexSim 2017 Update 1 as FloWorks version 17.1.3 and for FlexSim 2017 (LTS) as FloWorks version 17.0.6. FloWorks downloads can be found in the Downloads section of your FlexSim account on the 3rd party modules tab. Please do not hesitate to report any bugs, usability improvements and feature requests to support@talumis.com. About FloWorks FloWorks is a 3rd party module developed and maintained by Talumis BV ( talumis.com). It provides faster and more accurate modelling and calculation of fluid systems than the default FlexSim fluid library. It is especially useful within the oil, gas, and bulk industry both for production and supply chain optimization. This module requires a FloWorks license with active maintenance. For any questions, please email support@talumis.com. Release notes FloWorks 17.2.1 Bug fix: Adding charts using "Pin" buttons would show error message. Bug fix: Incorrect reference in Wait For Event activity in Mixer recipe schedule template for Process Flow; disabled Repeat Schedule by default. Bug fix: FloWorks objects remove pending events from the list when they are destroyed. FloWorks 17.2.0 (September 1, 2017) For FlexSim version 17.1.x use FloWorks 17.1.3. For FlexSim version 17.0.x (LTS) use FloWorks 17.0.6. Added FlowObject class interface ("dot syntax") for majority of FloWorks objects. Can now access products by name when using FloWorks product table ( e.g. source.product = "Raw material" instead of source.product = 3 ). Can define recipes for products in the products table and dynamically load / execute them on Flow Mixers. Added Process Flow templates for mixers executing production schedule and flow tank with cleaning / certification. Updated Pin to Dashboard buttons to use Statistics Collectors to collect data. Revised most of the user manual (tutorials are missing, will be re-released in a future version). Bug fix: Calling SelectFlowIp and SelectFlowOp with multiple ports produced FlexSim error. Bug fix: When using a product table, sometimes the Product dropdown would not show the correct product when opening Properties. Bug fix: Flow Conveyor would not suspend correctly when output flow restricted. FloWorks 17.1.3 For FlexSim version 17.2.x use FloWorks 17.2.0. For FlexSim version 17.0.x (LTS) use FloWorks 17.0.6. Bug fix: Calling SelectFlowIp and SelectFlowOp with multiple ports produced FlexSim error. Bug fix: When using a product table, sometimes the Product dropdown would not show the correct product when opening Properties. Bug fix: Flow Conveyor and Mass Flow Conveyor can cause FlexSim to crash, when used in combination with a product table. Bug fix: Flow Conveyor would not suspend correctly when output flow restricted. FloWorks 17.0.6 For FlexSim version 17.2.x use FloWorks 17.2.0. For FlexSim version 17.1.x (LTS) use FloWorks 17.1.3. Bug fix: Calling SelectFlowIp and SelectFlowOp with multiple ports produced FlexSim error.

FlexSim 2017 Update 2 is available. If you have bug reports or other feedback on the software, please email dev@flexsim.com or create a new idea in the Development space. Release Notes Reorganized the User Manual and updated its formatting. Added more topics, tutorials, and reference pages to the User Manual. Added new Statistics Collector and Calculated Table tools. Added new generic charts for plotting statistics gathered with Statistics Collectors and Calculated Tables. Updated the pin to dashboard buttons to create and use Statistics Collectors instead of the legacy charts. Added a Variant constructor and assignment operator to Vec3 and Color classes. Added functionality for copying dashboard charts as images, and pasting images into dashboards. Added new interfaces to FlexScript, such as Math, Group, and DateTime. Added toNum() and fromNum() methods to the string class. Added a setState() method to the Object class that will work correctly with listening to state changes. Improved handling of read-only model files. Keyboard shortcuts (Ctrl+PageUp and Ctrl+PageDown) and additional enhancements for switching tabs. Added the ability to have null values in a bundle. Added the ability to make kinematics exclude incline rotation when managing rotations. Improved the parenthesis and quote autocomplete functionality. Added autocomplete for curly and square brackets. Added a new print() command to write to the output console more easily. Added support for instanced meshes. Updated the animation system so a single shape can have multiple animators from different shape files. Changed the assimp 3D importer so that it can extract and load embedded textures. Added support for using specular maps and gloss maps. Added support for FlexScript dot syntax in SQL queries. Added the capability to specify a warmup time in the interactive model run. Added options for following objects with the view. Improved MTBF/MTTR state listening to use less events and be more precise. Updated the Network Navigator to work for an object that is inside a container that is connected to the network. Fixed a bug with global variable highlighting and autocomplete. Fixed an issue with destroying a TE on a network when it blocks space on the network. Included fixes listed in 17.1.5. Backwards Compatibility Note: the following changes may slightly change the way updated models behave. Fixed a bug with min() and max() when using distribution functions. Previously, getting the number of columns in a Global Table using Table.numCols or gettablecols() returned 0 when the number of rows was 0. Column headers and data types are preserved even when there is no row data. These commands now return the number of columns. Changed operators to not change their incline rotation when traveling on inclines. This will change location calculations if you have advanced logic based on internal operator locations. NodeListArrays like Object.outObjects can no longer be implicitly cast to an Array. Use the toArray() method instead. Fixed a bug with animations drawing their first frame instead of their last frame at times beyond the endtime. Added a special rule for ambient color {0, 0, 0} to not use the ambient color. This change will make shapes with ambient {0,0,0} to appear brighter. Change the ambient color to a dark gray, such as {1,1,1} if you want them to remain dark. Fixed a bug in the shader that dulled specular highlights with the diffuse texture. This may change how shapes look; they may appear shinier now. Added the IS NULL and IS NOT NULL clauses to SQL. Math and comparison operators on null values now return NULL. FlexSim's SQL execution engine is now more in line with the SQL ANSI standard regarding null values. Specifically, if you do comparisons or math operations on elements that have null values, this will return null values. This is different than in FlexScript, where a null value acts like 0 in math operations. Also, null values will be ignored in aggregation functions like AVG(). An option to use legacy SQL nulls was added to Model Settings to preserve backwards compatibility. Upgraded models will automatically enable this option, but new models will default to using the SQL ANSI standard for nulls. Added support for more SQL query operators, such as the case-when-then-else-end operator and window functions. This adds many new keywords to SQL, meaning that if you used these as column names in older queries, they will create syntax errors in the query parser in this version. To fix this, put square brackets [] around the column name. Changed accessing dynamic label properties to use evaluate() instead of value. For example, consider the following code sample: Variant value = current.MyLabel; In 17.1 and previous, this code was the same as: Variant value = current.labels["MyLabel"].value; In 17.2 we changed it so that this code is now the same as: Variant value = current.labels["MyLabel"].evaluate(); The difference is in how FlexScript-toggled node values are retrieved. In 17.1 and previous, current.MyLabel would have just given the text that is the FlexScript code. In 17.2, retrieving current.MyLabel will actually evaluate the FlexScript as code. This is consistent with how table values are accessed. If you have old code that explicitly tried to get the code text with current.MyLabel, you will need to update that code in 17.2 to use current.labels["MyLabel"].value. Process Flow Added a Material Consumption and Replenishment template. Added functionality for pasting images into Process Flow views. Conveyor Added a Gap-Optimizing Merge Controller Process Flow template. Added instanced rendering to improve Render Mode performance. Changed Render Mode to be enabled by default. Added new visual options for conveyors. Improved run speed performance of the Conveyor Module. AGV Added unload-to-empty capability to the AGV Process Flow template. AStar Added a bridge element to the AStar network. Added functionality for collision avoidance. Improved heat maps for analyzing AStar traffic. Backwards Compatibility Note: the following changes may slightly change the way updated models behave. Changed the path finding algorithm for the AStar navigator. When you tell an AStar traveler to travel to an object, now it will behave more like the default navigator. It will calculate a "threshold radius" around the object, based on the object's size. Then it will only travel to the edge of that radius. This makes it work better especially for loading/unloading to/from rack objects. The travel operation won't commit as much to traveling to the center of the object,because that can be left to the load/unload operation, which determines exactly where in the rack to pick/place the item. However, this change does affect how older models work because it changes the routes that travelers take.

In this example model you'll see two identical elevator setups. However, you will notice that ElevatorBank1 allows the patient to move to the next floor properly, whereas ElevatorBank1_2 will float the patient up the network node instead of using the elevator. There are a few steps you must follow to ensure you will have a properly working elevator in your model. Make sure everything is working the way you intended, without an elevator. Now you can add in the elevator, select it and then check the 'Connect to Path' box as seen below Now ensure that the elevator is connected to the nearest path node and any nodes above it. One thing to note is that after resetting if you click on any of the Path nodes that the elevator is connected to you will see that the On Arrival Trigger now says Send Message to Request Elevator. This is the code that actually calls the elevator when a patient arrives at the node. The elevator automatically adds this to the nodes connected to when resetting, but this trigger option can be added to any node. Another good practice, especially if patients walk by the elevator without always using it, is to make a separate node off on a spur. That way patients aren't triggering the elevator every time they walk by.

RailWorks 22.0.0 is now available ( 25 July 2022). This version of RailWorks is intended for use with FlexSim 2022. All versions can be found in the Downloads section of your FlexSim account on the 3rd party modules tab. Please do not hesitate to report any bugs, usability improvements and feature requests to developmentbrflexsim@flexsimbrasil.com.br About RailWorks The FlexSim Brasil RailWorks module consists of premade custom objects, designed to represent a real environment for the Rail problem modeling, with less configuration. Our approach is to unite 3D modeling with the Process Flow functionality, allowing object configuration and visualization through the native 3D FlexSim solution, and the rail system events to be triggered by the Process Flow, using not only defaults FlexSim Process Flow activities, but also new ones developed by our team. For any questions, please email developmentbrflexsim@flexsimbrasil.com.br Release notes RailWorks 22.0.0 Release for FlexSim 2022 Refactor: Changed the way that Rails can be resized and moved. Feature: Added the RailWorks manual to FlexSim. Feature: Added travel offset to the MoveTrain activity. Feature: Added speed profiles to the Locomotive. That means that you can now set the speed of a Locomotive based upon if it is coupled to a Wagon or not. Feature: Added acceleration and deceleration of locomotives. Feature: Added RailwayTimetable, providing observability for the model as it saves every important event in RailWorks, like the time when a locomotive arrived at a station, as an example. Feature: Added a new model to the Stations: Fuel Station. Feature: Added a new model to the Stations: Flow Station. Feature: Integration with FloWorks. Feature: Added loading modes to thee LoadWagon activity. Bug Fix: Fixed various bugs affecting the locomotive movement. Bug Fix: Fixed a bug affecting the load and unload actions. Bug Fix: Fixed a bug affecting the Experimenter. RailWorks 21.2.0 Release for FlexSim 2021 Update 2 Feature: Added a new routing algorithm option, focused on preventing train collisions (Requires Python installed). Bug Fix: Fixed a bug in the model limit. RailWorks 21.1.0 Release for FlexSim 2021 Update 1 Feature: Added trigger - onCreate - to the SourceTrain object. Feature: Added triggers - onEntry, onExit - to the Rail object. Feature: Added triggers - onFuel, onLoad, onUnload - to the Station object. Feature: Added triggers - onLoad, onUnload - to the Crane object. Feature: Added trigger - onArrival - to the RailControlPoint object. Feature: Added tank wagon 3D Model option to the Wagon Object. Feature: Added custom dashboards to the module. Feature: Added auto-connect to SourceTrain to connect with the nearest ConnectPoint. Feature: Added the possibility to keep the FlowItems or create new ones when loading and unloading. Feature: Added the possibility to load FlowItems fractionally or discretely. Bug Fix: Fixed bugs on train movement. Bug Fix: Fixed bug on entry of task executer as flow item in Station. Bug Fix: Fixed a bug in the RailControlPoint. Refactor: Changed functionality of Rail's Connect Points. Style: Changed RailSystem model. Style: Added a new model to the Wagon Object: Gas Tank Wagon.

FlexSim 19.0.4 and 19.1.1 are now available for download. IMPORTANT NOTE 1: The 19.0.3 installer has a bug that causes the current installer to hang during the Cleaning Up stage when upgrading from 19.0.3 to a newer version. We have resolved the issue for future installers, but to avoid the error now, uninstall 19.0.3 using Add/Remove Programs before installing the new version. Alternatively, you can press the X in the upper-right corner of the empty window, click Yes to canceling the installation (this won't do anything), and the Cleaning Up... window will successfully finish installing the upgrade. IMPORTANT NOTE 2: 19.0.4 and 19.1.1 include a bug fix to the JT importer. The JT importer now correctly accounts for the measurement units of the shape that are defined in the file. JT shapes in existing models may appear scaled incorrectly when you open them. You can resolve their scaling issue by executing the script below: forobjecttreeunder(model()) { treenode focus = a; string path = gets(shape(focus)); if(stringlen(path) > 3) { string extension = stringcopy(path, stringlen(path)-1, 2); if(comparetext(extension, "jt", 1)) { double x = xsize(focus); double y = ysize(focus); double z = zsize(focus); applyshapefactors(focus); setsize(focus, x, y, z); } } } Below is an example of the issue. Note that the shape is much smaller than its yellow box. Running the script above fixes the shape's scale factors so that it correctly fits in the yellow box again.

Neste vídeo, abordamos de forma rápida e bem resumida, como funciona simulação em ambientes hospitalares e elaboramos uma rápida demonstração através de um passo a passo, o funcionamento do software FlexSim Healthcare. O vídeo encontra-se disponível no canal do Youtube da FlexSim Brasil.