Intersection with traffic lights in an AGV network This model aims to showcase how allocations of control areas can be manually controlled to achieve more complex logic than the default “first come first serve” implementation. It depicts a four-way road intersection with arriving cars being able to continue in any of the three other directions. Cars driving straight on or turning right use the right lane, cars turning left use the left lane and must give way to oncoming traffic. Traffic lights manage which cars are allowed to enter the intersection at any given time. AGV network and general concept In order to understand the logic behind it, let’s first look at how the AGV network is setup. In the screenshot below we deactivated the visualization of the roads to show the paths and areas more clearly. For each of the four directions there are two incoming paths and one outgoing path. Control points (red) are placed on the incoming paths at the points where cars must stop (based on object center) when the light is red. A single, large control area that control the entry is placed such that is encompasses the entire intersection. Within this control area, an additional control point is placed on each of the left turning paths (orange). This is the location where left turning vehicles must wait for the oncoming lane to be clear. To enforce this the four smaller, rectangular control areas are used. The lane turning left and both the straight and right turning lane coming from the other direction pass through one of these areas. We will later explain how the straight and right turning cars are given priority to allocate these areas, resulting in cars wanting to turn left having to wait until no other allocation requests are present. As all paths are one-way and the geometry is pretty simple, all things considered, the distance between cars is handled by an accumulation behaviour set on the paths. The logic controlling the vehicles is very simple. If we zoom out, we can see that cars leaving the intersection in any direction eventually just turn around and return. At the turning points control points are placed that serve as the travel destination for the cars. A Process Flow with one token per car randomly chooses the next destination when the previous travel task is finished and sends the car there. The cars will automatically use the correct lanes, since those are the shortest paths to reach their destination. For the intersection logic each combination of origin and destination (meaning every possible way of crossing the intersection) is represented as a number. These numbers are stored as global macros for ease of use. The letters represent the four cardinal directions (north, west, south, east). For example, using the intersection to travel from east to west would be represented by the ‘mode’ number 4. At the same time as a new destination is chosen for the car, the respective mode number is also written to a label on the car. In the logic that controls entries into the intersection, these modes are used to identify which vehicles are allowed to enter. Powers of two are used, so the numbers can simply be added together to get a single number that encodes which lights are green. The light phases are defined in a global table. One of the simplest sensible configurations is shown below. At first, all lights are red (no entries in the “Green” columns) for 5 seconds. Then all cars coming from the west and east directions receive a green light for 20 seconds. This is followed by another 5s of all red lights and finally the other directions are allowed to move on. The table is then repeated from the top. The phase in line two would be represented as mode 1365 (1 + 4 + 16 + 64 + 256 + 1024). This becomes a lot more obvious when the mode is written in binary: 0000 0101 0101 0101 Each bit represents one of the possible directions. Allocation logic explained The control area is set to allow 0 concurrent allocations. Meaning for a request to actually result in an allocation, we need to override the return value of the “On Request” event of the control area. This happens in the control logic for the intersection that is implemented as an Object Process Flow linked to the control area. An Event-Triggered Source reacts to the On Request event and writes a reference to the “Allocator” (meaning the car/AGV) to a label on the token. Note that the “Will Override Return Value” box is checked. The token then enters a Finish activity in whose “Return Value” field the current traffic mode of the control area is compared to the mode of the requesting car. The “&” is the bitwise-and-operator. It goes through both numbers bit by bit. If the bit at a given position is 1 in both numbers, it will also be 1 in the returned value, 0 otherwise. If the mode of the car is part of the current traffic mode (which is a sum of such modes) the result will be the mode. This non-zero number is interpreted as “true” in the if-condition and the return value of the code is to allow the request to go through. Otherwise, the request is blocked. (The “Allow” and “Block” properties return 1 and -1, respectively.) The second part of the Process Flow is a loop with a single token that reads the next traffic mode from the global table. It then ‘announces’ which phase the intersection will enter next, so that the draw logic of the traffic light objects can start the process of switching from red to green or vice versa if needed. After a delay, in which those lights would show yellow, the current phase of the control area is updated. The same code that updates the label then also searches for cars that are now allowed to enter the intersection among the pending allocation requests. Since, as far as I could tell, there is currently no direct method to refire an allocation request, those cars receive a pre-empting task sequence that uses a break task to immediately return to the previously active sequence. The restart of their travel task then causes them to try to allocate the control area again. After waiting the duration assigned to the current traffic phase, the token once more updates the mode of the intersection to an ‘intermediate’ mode. This mode is the result of another bit-wise comparison of the current and the next mode. This allows lights that need to change to red to do so, while lights that stay green remain unchanged. Once the next phase is activated, additional lights might then become green. If the next phase doesn’t have any green lights, all lights will already be red in the intermediate mode, meaning the Process Flow block that updates the mode can be skipped and the token instead just waits out the duration in the “All Red Duration” Delay activity. The logic that makes left turning vehicles give way to oncoming traffic works in a similar way. It is also implemented as an Object Process Flow, linked to the four smaller control areas within the intersection. These areas allow a single allocation by default and also have a “Mode” label. But it’s not set based on a timer and otherwise static. Instead, these areas start in mode 0 and if a request is made while the area is empty, the allocation is always allowed, and the mode is set to match that of the allocator. When another request is made, the areas mode is compared with that of the new requesting car. If they match, the request can potentially be granted. First however, the code searches other pending requests for a mode with a higher priority than that of the current request. (The mode numbers are assigned in the order straight < right turn < left turn, so they can also be used as a priority value, where lower is better.) If such a request is found, the current one is blocked, to allow for the area to empty. At that point, a token created by a source listening to the “On Deallocated” event of the control area will reset the mode of the area to 0 and sort any pending requests by priority, before those get re-evaluated. In summary, this logic allows an arbitrary number of cars with the same mode to enter the area. As soon as a higher priority request that can’t immediately enter is created, other requests are blocked; they must ‘give way’. Visualization and parameters The traffic lights are BasicFR objects that draw colored circles as lights in their On Draw trigger, depending on a label. That label is updated in the On Message trigger whenever the intersection changes its phase. The roads are drawn along the AGV paths in the On Draw code of a dummy object placed to the side of the intersection. How wide and in what interval the white lines are drawn is determined by Array labels on the paths containing all necessary parameters. The model comes with five parameters: The first controls which table is used to determine the traffic light phases, the second and third set the time it takes a light to switch from red to green and green to red. The fourth sets the number of cars and the final one switches the visualization of the left turn lights to arrows. agv-traffic-mode-intersection.fsm

En este video van a aprender cómo utilizar el objeto Separator para representar la división de FlowItems usando el modo Split. Para más videos tutoriales pueden acceder al canal de YouTube de FlexSim Andina y acceder a nuestra lista de reproducción de FlexTips.

En este video van a aprender cómo se establece la cantidad de FlowItems que se recibirá a través de los puertos de entrada de un Combiner usando la operación Update Combiner Component List with Labels. Para más videos tutoriales pueden acceder al canal de YouTube de FlexSim Andina y acceder a nuestra lista de reproducción de FlexTips.

En este video van a aprender cómo se cambia el color de los FlowItems y Objetos 3D en FlexSim usando la Ventana de Propiedades y los Triggers. Para más videos tutoriales pueden acceder al canal de YouTube de FlexSim Andina y acceder a nuestra lista de reproducción de FlexTips

En este video van a aprender cómo establecer tiempos de proceso por lotes usando el objeto Processor. Para más videos tutoriales pueden acceder al canal de YouTube de FlexSim Andina y acceder a nuestra lista de reproducción de FlexTips.

En este video van a aprender cómo establecer diferentes tasas de llegadas según la hora del día utilizando el objeto Source. Para más videos tutoriales pueden acceder al canal de YouTube de FlexSim Andina y acceder a nuestra lista de reproducción de FlexTips.

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

The attached model contains an object process flow for a basicFR to sit between a regular conveyor and a Mass Flow. It looks at the interval between the discrete items leaving the regular conveyor and creates a new generative rate when it detects a change, allowing you to convert a stream of hundreds of items to singular events for the MFC as needed and capitalize on the advantages of MFCs. It's a simple process flow: To use just connect a BasicFR between the two conveyors and add it to the object process flow as a member instance. This is a proof of concept and does not currently handle accumulation across the interface, or aggregation from multiple discrete conveyors. MFC_RateMaker.fsm

Would you like to remove your data from FlexSim? Here are two options: 1. Remove all data from FlexSim and Autodesk If you would like to remove all of your data from both FlexSim and Autodesk, please use this link. This will initiate a delete request across our systems to ensure that your data is removed in accordance with Autodesk's data privacy standards. 2. Remove specific data from FlexSim If you would like to have some or all of your data removed from FlexSim properties, please submit your request via email to [email protected] and we will complete your request. Note: We may retain certain data for legal and internal business purposes, such as fraud prevention, in accordance with applicable laws.

The following article applies to FlexSim versions 26.0 and older. For Autodesk FlexSim 2027 and onward, please visit Autodesk analytics programs | Autodesk   You might be wondering what data is collected when you use FlexSim simulation software. How is it sent to FlexSim? How is it stored? What is it used for? Can you opt out?   Below you'll read all about it, but for those who can't be bothered:   tl;dr: Our customers have complete control when deciding what data is sent to FlexSim. Any data gathering is easily circumvented, disabled, or avoided.   If that interests you, read below for the details.   Introduction There are four ways your data may be sent to FlexSim, and there are workarounds you can implement for each to avoid sharing any data. Each link jumps to its section below: FlexSim Accounts (contact information) Licensing your software or your local license server (license and computer information) Online communications from the software (license and computer information) Support or model building services (customer-sent data) You can also jump to the Conclusion.   FlexSim Accounts We receive user personal contact information when someone signs up for a FlexSim account, or when an account is created for a person in order to give them a license. FlexSim Account information includes required fields (name, email, organization, country) and optional fields (including title, address info, phone). These data are submitted to FlexSim through web forms. Our website is only accessible via HTTPS, with TLS 1.2 or higher enforced. FlexSim's databases are hosted in United States data centers, and this data is encrypted at rest with AES-256. Data is encrypted in transit with TLS 1.2. FlexSim US's CRM is HubSpot, and US contacts are saved there. HubSpot ensures that your data is encrypted at rest. HubSpot's sites and services are accessed via HTTPS and we've configured our account's security settings to require TLS 1.2 or higher. Contacts from outside the United States are forwarded to their regional FlexSim distributor, who operate independently and may use a different CRM. Our websites track usage information to help us improve our marketing and fix site issues. Basic web browsing logging data is collected, such as IP/location information, browser type, session duration, etc. Additionally, if you are logged in to your FlexSim account, we keep download, license, and profile logs. Check out Autodesk's privacy policy. Workaround A FlexSim Account requires a person's contact information for convenience only. If a customer wishes, an account can be set up with a generic name, like "CompanyXYZ FlexSim Rep," and a generic email, like "[email protected]". Having a real name and email of an actual person is convenient, but also optional. As long as we have a way to communicate with a customer, that works!   Licensing License codes When a client PC communicates with our main license server to activate or return a standalone FlexSim license, it does so over secure HTTPS.   When licensing a local license server using the licensing utility flexsimserveractutil.exe license codes are transmitted in plaintext over HTTP. This means that license codes are transmitted in the clear. The risk to a licensed user is that if your online communications are being monitored your license keys could be compromised, allowing someone else to obtain your FlexSim license keys and potentially use them to activate your FlexSim licenses and consume your seats, leaving you without the ability to activate those seats normally.   If there is ever an issue where a license should be available but for some reason is not successfully activating, customers can contact their local FlexSim distributor for licensing support. These situations can be handled quickly.   License codes are stored in plaintext in FlexSim's main Flexnet Operations server database.   Additional license history information When a license is activated over the Internet, whether by a client PC (standalone license) or when configuring a license server (server license), FlexSim also receives the Windows username of the person logged in doing the action, and the Windows computer name where the license is being activated. When activating a standalone license this information is first AES-256 encrypted before transmission over HTTP. For a license server the username/computer name are transmitted in plaintext over HTTP. Once received by FlexSim, the Windows computer name and username are stored in our database which is LUKS encrypted at rest and are displayed to the customer in their account's license history. The license history allows customers to track license usage and location - a useful feature requested by our customers to help manage standalone licenses shared among multiple people.   When activating a standalone license over the internet, the software also sends basic operating system and FlexSim software version information, which, like the Windows username/computername, is AES-256 encrypted before being transmitted over HTTP. This additional information is AES-256 encrypted at rest.   Workaround We have an alternate method of licensing that applies to both standalone PCs and license servers where a user generates XML requests and manually submits them to FlexSim's website over HTTPS using TLS 1.2 or higher. Licensing by XML avoids the following potential issues: License codes sent in plaintext over HTTP FlexSim receiving Windows username and computer name information, and in the case of standalone licensing, additional operating system and FlexSim software version information. Manual licensing is somewhat less convenient and more time consuming than online licensing - instead of just a button push there are several steps to follow in sequence, including generating requests, uploading requests, downloading responses, processing responses. It is up to you to decide whether easy-online or manual-XML licensing is most appropriate for your organization.   License operations, both automated/online or manual/XML are documented in our article Licensing Procedures.   Online communications Start page FlexSim software has a web-based start page that by default sends basic computer information to FlexSim to request introductory content to display when starting the software. This information includes FlexSim version, and general Operating System properties including Windows version, language, and country. These are used to display appropriate content to the user. For instance, we have localized versions of the start page depending on the country and language settings sent by the client PC. If a computer is licensed, the license information along with Windows username and computer name are also sent, again for a history of license use, and also in the case that FlexSim needs to display specific information only to licensed users, such as expected maintenance windows for FlexSim's main license server, etc.   The start page is enabled by default. The above-described information is AES-256 encrypted and then transmitted to FlexSim over HTTPS using TLS 1.2 or higher. The data remains AES-256 encrypted at rest.   Telemetry A user can also enable additional telemetry as an opt-in feature. This sends additional operating system and hardware information such as CPU, RAM, screen resolution, GPU type and driver version, all of which helps us build an aggregated view of the computer capabilities of our user base. This is useful for development decisions, to make sure we target the simulation software to hardware that is generally available to a majority of our user base. This telemetry info is AES-256 encrypted, transmitted to FlexSim over HTTPS TLS 1.2 or higher, and stored in AES-256 at rest.   Workaround: The start page can be disabled with an in-software setting. Additional telemetry is an opt-in feature. You can read more about online communication in our Sofware License Agreement, item 15. Online Communication. The in-software settings are configured from FlexSim simulation software's main menu > File > Global Preferences > Dynamic Content tab.   Support In the course of using FlexSim simulation software, your simulation engineers may send models or other data to Autodesk's FlexSim support team for help via email, or by posting to this online community. Your employees should only do so according to whatever applicable policies you have in place.   In this online community, questions are asked publicly, allowing our worldwide community and partners to help solve problems and provide answers, insights, and experience. Any information or attachments posted to this community are public.   Workaround Don't post or email confidential data. If you need support but your simulation model contains proprietary/confidential/secret information, you could: Pose a general question without including any attachments. Post a sample model you create that demonstrates the question or issue at hand without using any confidential information. If you have a current maintenance contract, you can also contact your local FlexSim distributor for live phone or web meeting support. You could share your screen so that our support staff could help troubleshoot your issues directly on your PC. In this way you could get the help you need without ever transferring any files or data off your computer.   Conclusion Any data that FlexSim might receive is described above, and any data gathering can be circumvented, disabled, or avoided using the provided workarounds. Our customers maintain complete control when deciding what data is sent to FlexSim. In addition, we're happy to delete any information we may already have on your company or your users. We are responsive to our customer's requests and wish to assure you of our commitment to your privacy and security. Simply contact your local FlexSim distributor with any requests about what data we have about you or to request any deletions.   Thank you for your patience in reviewing this long article! Contact your local FlexSim distributor if you have any questions or concerns.

FloWorks 25.0.1 is now available (21 January). This version of FloWorks is intended for use with FlexSim 2025 (LTS). If you are using FloWorks with FlexSim 2024, please update to FloWorks version 24.0.7. If you are using FloWorks with FlexSim 2024 Update 2, please update to FloWorks version 24.2.1. 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 [email protected]. 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 [email protected]. Release notes View the full release notes in the online documentation. FloWorks 25.0.1 (21 January 2025) FloWorks was not loading correctly in FlexSim 25.0.2. FlexSim Compatibility Note: This release of FloWorks is for FlexSim 25.0.2 and higher versions. It may not work with FlexSim 25.0.1 and earlier. FloWorks 25.0.0 (19 December 2024) Improvement: FlowConveyor can be reversed. All bug fixes in FloWorks 24.2.1 below. FloWorks 24.2.1 (19 December 2024) Improvement: Made Disconnect Flow Objects properties more clear. All bug fixes in FloWorks 24.0.6 below. FloWorks 24.2.0 (6 August 2024) Bug fix: removed flicker due to unnecessary repaint in ApplyImpactFactor QuickProperties panel. All bug fixes in FloWorks 24.0.4 below. FloWorks 24.1.1 (6 August 2024) Bug fix: removed flicker due to unnecessary repaint in ApplyImpactFactor QuickProperties panel. All bug fixes in FloWorks 24.0.4 below. FloWorks 24.1.0 (17 April 2024) Feature: new "Apply Impact Factor" activity in ProcessFlow. Feature: new "Connect Flow Objects" and "Disconnect Flow Objects" activities in ProcessFlow. All bug fixes in FloWorks 24.0.3 below. FloWorks 24.0.7 (21 January 2025) FloWorks was not loading correctly in FlexSim 24.0.8. FlexSim Compatibility Note: This release of FloWorks is for FlexSim 24.0.8 and higher versions. For FlexSim 24.0.7 and earlier, please use FloWorks 24.0.7. FloWorks 24.0.6 (19 December 2024) Bug fix: Flow Mixer stops with error when pulling product from an invalid port. Bug fix: Reactor vessel shape was not correctly upgraded to 24.0 from older versions. Bug fix: FlowConveyor content visualization was incorrect. Bug fix: SharedResource showed exception and didn't work correctly. Improvement: Impact events can be resumed with a Variant id identifier instead of treenode eventObject . Improvement: Fixed many incorrect tooltips in the FloWorks ProcessFlow activities. FloWorks 24.0.5 (27 August 2024) Bug fix: Version 24.0.4 installer contained an incorrect module (.t) file Bug fix: Removed ProcessFlow activities which are only available from 24.1 from the drag/drop library FloWorks 24.0.4 (6 August 2024) Bug fix: FlowToItem was not behaving correctly when an item buffer was used. Bug fix: Fixed a timing issue when FlowToItem got starved while an item was being released. Bug fix: Fixed some rounding issues in event scheduling. Bug fix: Fixed Quick Properties product combo when product has been deleted. Bug fix: Missing states 19 and 20 added to state profile. Bug fix: Fixed several issues in FlowConveyor visualization. Bug fix: Invalid curved FlowConveyor animation fixed. Bug fix: Invalid initial content for Segmented Pipe fixed. Bug fix: "FlowConveyor content changes are not allowed" error (and subsequent exception) fixed. Improvment: Curved conveyor now also supports FlowConveyor length property. Improvement: Tank label hidden in FlowItems (FlowVessel and FlowTruck). Improvement: Cleaned up the variables in the FlowItems' model tree. Improvement: Tank size/position and max content changed for FlowTruck, also as FlowTaskExecuter. Improvement: Slight optimization in preventing unnecessary FlowControl events. Improvement: Added SetMaxContent for FlowToItem and improved handling for Flow Tanks. FloWorks 24.0.3 (17 April 2024) QuickProperties behavior improved. Fixed invalid manual references. Fixed missing code completion documentation. FloWorks 24.0.2 (6 March 2024) Made activity path references in warning message more clear. Restore missing Flow Trigger Process Flow activities to the library. Fixed Tank level indicator settings for some tank shapes. Add Accumulating checkbox to the Conveyor properties. FloWorks 24.0.1 (5 February 2024) Added vertical splitter to Mixer recipe editor and other small layout improvements. Fixed missing icons in statistics panel pin menus. Flow Polygon Tank property panels fixed and documentation updated. Added "Fill Sideways" property for Flow Polygon Tank. IsMultiProduct setting on Flow Tank is now a proper property. Renamed Flow Tank shapes from Cylindric and Rectangular to Tank and Container, respectively. Fixed "Copy Production Plan" button in Flow To Item properties. Some objects were not correctly reset. ItemToFlow statistics were accessible through .output instead of .input . Breaking changes: Deprecated the input.triggerAmount , input.triggerInterval , output.triggerAmount , and output.triggerInterval properties. FlowObject.stats.input and FlowObject.stats.output now return a Tracked Variable. Cylindric level indicator now expects size of bounding box instead of center and radius. The update script will try to convert these for you. FloWorks 24.0.0 (14 January 2024) All bug fixes in FloWorks 23.0.5 below. Improved warning and error messages throughout Fixed rounding issue in Mass Flow Conveyor

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

This article is an updated version of a previous article by @Paul Toone. Thanks to Paul for the original, which you can read here: https://answers.flexsim.com/articles/23118/flexsim-xml-18.html In FlexSim, you can save any tree (including models and libraries) in XML format. There are many advantages to using this capability in your model development, including: Since XML is an ascii/text based format, it increases the utility of using content management and versioning software such as Subversion, CVS, Microsoft Visual SourceSafe, git, etc. to manage the development of a model. These systems automatically track a history of changes to a model or project, and for ascii/text based files, they allow you to see line-by-line change logs for the files, as well as revert line-item changes if needed. With the added benefit of versioning systems comes the ability to develop a model concurrently by different modellers using a much more stream-lined method. No more saving off individual t files from one modeller's changes to a model and loading them manually into the master model. When saving to XML format, if one modeller is working on one portion of the model, only that portion of the model file changes when saved, so when the modeller checks his changes into the versioning system's repository, another modeller can automatically merge those changes into his copy. If there are conflicts, where two modellers change the same part of the model, then the versioning system has tools that allow modellers to easily see in the XML file where the conflicts occur and quickly perform the manual conflict resolution. FlexSim also has the added ability to distribute a single model across multiple XML files. This increases your control over how to manage the model development in your versioning system, and makes conflict resolution even easier. The distributed save mechanism also opens the door for much more automated control of FlexSim. By saving small pieces of your model off into separate XML files, you can auto-regenerate one or more of those XML files outside of FlexSim, consequently changing the configuration of the model for the purpose of running different scenarios. Tutorial This tutorial will take you through saving a model as XML, and how you can configure the distributed save. Build a Simple Model First build a simple example model containing a Source, Queue, Processor and Sink. Save in XML Format Save the model, and in the save dialog, choose "FlexSim XML" from the drop-down at the bottom. Save the model as "PostOfficeXML". Now you've saved the file in FlexSim's XML format. You can view the file in a regular text editor like Visual Studio Code, Notepad++, etc. It's not necessary to know all the details of the file format. In simple terms, the primary tag in FlexSim XML is the <node> tag, representing a node in FlexSim. The node's name is described in the <name> tag, and the node's data, if applicable, is described in the <data> tag. If you plan on doing automated changes, and need a more detailed definition of the xml format, you can refer to FlexSim's xml schema (see the FlexSim install directory/help/MiscellaneousConcepts/FlexSimXML.xsd for more information). Version Management with Git At FlexSim, the development team uses Git to manage collaboration between developers. Part of development includes updating the MAIN and VIEW trees. In a similar way, you can use Git to collaboratively update the MODEL tree. The standard way to use Git is as follows: Set up a remote repository for the project. There are many online services for this, including GitHub, BitBucket, and many others. Each one has different pricing and terms of use. It is also possible that your company already runs a Git hosting service where you could create your remote repository on a company server. Once you have a remove repository, each user "clones" that repository to their local computer. Everyone "pulls" the latest changes from that repository and "pushes" their changes to that repository. To manage pushing and pulling, you can use Git on the command line. However, most users interact with Git through a client. One free one is called Git Extenstions: http://gitextensions.github.io/ By itself, version management is a deep topic. You might consider reading some tutorials to become more familiar with Git concepts: https://git-scm.com/docs/gittutorial https://github.com/git-guides https://github.com/skills/introduction-to-github https://www.atlassian.com/git/tutorials/learn-git-with-bitbucket-cloud Managing Changes with Git Let's assume you have a repository with the model file already in it. Let's make a change by moving the queue and saving the model: Once you save the model, Git can show you the changes you've made. In this case, you can see the spatialx and spatialy in your Git client: At this point, you could commit and push your changes. Others could then pull the changes into the model. Notice that git looks at changes in terms of lines being added and removed. In this case, we removed two old lines and added two new lines. Distributed Save As models get bigger and more complex, it can be helpful to split a single model file into multiple XML files. To do this you create a "FlexSim File Map" file. This is an xml file with the .ffm extension. It must be placed in the same directory as the model's .fsx file, and, except for the extension, must be given the same name as the .fsx file. So, let's create that file. Let's also create a subdirectory to put the distributed files into. Now edit PostOfficeXML.ffm in a text editor. The first thing we'll do is put the node MODEL:/Tools/ Workspace into a different file. This is something you'll probably want to do always if you're using version management. The node MODEL:/Tools/Workspace stores all of the windows open in the model, so if you're editing a model and change or reposition the windows that are open, that will change the model file. For version management this is often just static that doesn't need to be tracked, so we'll have the node saved off to a different file, and then we can just never (or at least rarely) check that file into the version management system. Specify the following code: <?xml version="1.0" encoding="UTF-8"?> <flexsim-file-map version="1"> <map-node path="/Tools/Workspace" file="distributedfiles/windows.fsx" file-map-method="single-node"/> </flexsim-file-map> Save the file map, then go back into FlexSim. Save the post office model again under the same name "PostOfficeXML.fsx". Now look in the distributedfiles directory. You'll see that it contains a new xml file named windows.fsx. This xml holds the definition of the node MODEL:/Tools/Workspace. All interaction with the model remains the same, i.e. from FlexSim you just load and save the main xml model file, but now the model is distributed across multiple files. If you look a the change to PostOfficeXML.fsx in your git client, you'll see that many lines have been replaced with a single line specifying the other file: This shows how much of the content of PostOfficeXML.fsx has been moved to distributedfiles/windows.fsx. In the file map, the main document element is the <flexsim-file-map> tag. Inside the main document element should be any number of <map-node> elements. Each <map-node> element should have a path attribute, a file attribute, and a file-map-method attribute. The path attribute should specify the path, from the main saved node, to the node that is going to be saved into the distributed file. The file attribute specifies the path, relative to the saved model file, to the distributed file that you want to save. The file-map-method should either have a value of "single-node" or "split-points". In this case "single-node" means you want to save all of the active node into windows.fsx. Now let's do an example of the "split-points" method. Let's say we want to save the Tools folder in one file, the Source and Queue into another file, and the Processor and Sink in a third file. To do this, add another <map-node> element to the file map: <?xml version="1.0" encoding="UTF-8"?> <flexsim-file-map version="1"> <map-node path="/Tools/active" file="distributedfiles/windows.fsx" file-map-method="single-node"/> <map-node path="" file="distributedfiles/Tools.fsx" file-map-method="split-points"> <split-point name="Source1" file="distributedfiles/Source_Queue.fsx"/> <split-point name="Processor3" file="distributedfiles/Processor_Sink.fsx"/> </map-node> </flexsim-file-map> Now save the file, save your FlexSim model, and again you'll see new files created in the distributedfiles directory. If a element uses the "split-points" method, then it can have sub-elements. Each split-point should have a name, defining the name of a node inside the map-node's defined node, and a file attribute defining the file to save to. The map-node has a path="" attribute. This means that it applies to the root node, or the model itself. The map-node's file attribute defines the first file to use. This configuration tells FlexSim to save all sub-nodes in the model up to but not including the node named "Source1" to the file "distributedfiles/Tools.fsx", save everything from Source1 up to but not including the node named "Processor3" in "distributedfiles/Source_Queue.fsx", and save everything from Processor3 to the end in "distributedfiles/Processor_Sink.fsx". Why Distribute? The main reason you would want to distribute your model across multiple files is for version management. It allows you to easily see what you've changed in your model by seeing what files, and consequently which parts of the tree, have changed. If you inadvertently changed one piece of the model, you can easily see that and then revert that change if needed. When multiple modellers are developing the model, one modeller can essentially confine himself to one part of the model tree, and by associating that part of the tree with a specific file, it makes it much easier to merge changes from different developers, it reduces the chance of conflicts in the merge, and makes it easier to do a manual merge if needed. Note on connections: FlexSim's XML save mechanism does have one catch regarding input/output/center port connections, as well as any other mechanism that uses FlexSim's coupling data. If you change connections in one portion of your model, it will actually change the serialized values of all connections/coupling data that occur after those connections in the tree, even if those connections were not changed. This can very easily cause merge issues if multiple modellers are changing connection data. However, if you distribute the model across multiple files, connection changes where both connection end-points are within the same file will only affect that file, and will not change other files. So if you can localize large "connection sets" into individual files, you can minimize the effect of changes and subsequently minimize merge conflicts.

FlexSim 2025 is now available for download. You can view the Release Notes in the online user manual. FlexSim 25.0.0 Release Notes For more in-depth discussion of the new features, check out the official software release page: FlexSim 2025: Container Object, Task Sequence Queue, and more If you have bug reports or other feedback on the software, please create a new post in the Bug Report space or Development space.

Engage with the FlexSim community here on the FlexSim forum boards. Check out our learning resources. Customers with current licensing can request direct technical support from their FlexSim representative, via phone, email, web meeting, or support ticket.  

This article describes an example of Reinforcement Learning being used to solve scheduling problems. See the model and python files in the attached zip file. SchedulingRL.zip Problem Description This model represents a generic sheet metal processing plant. There are four machines in series. Each job requires time on all four machines. Jobs come in batches of 10. A poor sequence of jobs will cause blocking between items, lowering throughput. If the time between batches is long, such as a shift or a day, you could use the optimizer to determine the best sequence. If the time between batches is short, however, the optimizer may not be feasible. For real sequencing problems, the time to find a good sequence can be anywhere from 5 minutes to an hour, or even longer. This makes it impractical for high-velocity situations. The attached model requests a decision every time the first machine in the series is available. The only action is an index for the Nth available job. So the decision can be interpreted as "which job should I do next?" Solution The general solution is to use reinforcement learning. However, this problem required customized python scripts: The model uses custom parameters for observations. This allows arbitrary values for observations. The model uses a custom observation space. The observations include a table of the required times at each station for the remaining jobs. They also include an array of the in-progress jobs and their predicted remaining times. By using a Dict space, the python scripts can combine all the observations into a single space. The model uses an Action Mask. An Action Mask is a binary array with one value per value of the action. This tells the RL algorithm about invalid options. The python scripts require the sb3-contrib package. Use pip install sb3-contrib to install it. Results After training for 500k time-steps, the agent learns to choose jobs moderately well. If you run the inference script, you can use the experimenter to compare a random policy to a trained agent:

FloWorks 24.1.0 is now available (17 April 2024). This version of FloWorks is intended for use with FlexSim 2024 Update 1. If you are using FloWorks with FlexSim 2024 (LTS), please use FloWorks version 24.0.3 (LTS). 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 [email protected]. 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 [email protected]. Release notes View the full release notes in the online documentation. FloWorks 24.1.0 (17 April 2024) Feature: new "Apply Impact Factor" activity in ProcessFlow. Feature: new "Connect Flow Objects" and "Disconnect Flow Objects" activities in ProcessFlow. All bug fixes in FloWorks 24.0.3 below. FloWorks 24.0.3 (17 April 2024) QuickProperties behavior improved. Fixed invalid manual references. Fixed missing code completion documentation. FloWorks 24.0.2 (6 March 2024) Made activity path references in warning message more clear. Restore missing Flow Trigger Process Flow activities to the library. Fixed Tank level indicator settings for some tank shapes. Add Accumulating checkbox to the Conveyor properties. FloWorks 24.0.1 (5 February 2024) Added vertical splitter to Mixer recipe editor and other small layout improvements. Fixed missing icons in statistics panel pin menus. Flow Polygon Tank property panels fixed and documentation updated. Added "Fill Sideways" property for Flow Polygon Tank. IsMultiProduct setting on Flow Tank is now a proper property. Renamed Flow Tank shapes from Cylindric and Rectangular to Tank and Container, respectively. Fixed "Copy Production Plan" button in Flow To Item properties. Some objects were not correctly reset. ItemToFlow statistics were accessible through .output instead of .input . Breaking changes: Deprecated the input.triggerAmount , input.triggerInterval , output.triggerAmount , and output.triggerInterval properties. FlowObject.stats.input and FlowObject.stats.output now return a Tracked Variable. Cylindric level indicator now expects size of bounding box instead of center and radius. The update script will try to convert these for you. FloWorks 24.0.0 (14 January 2024) All bug fixes in FloWorks 23.0.5 below. Improved warning and error messages throughout Fixed rounding issue in Mass Flow Conveyor

FlexSim 2024 Update 1 is now available for download. You can view the Release Notes in the online user manual. FlexSim 24.1.0 Release Notes If you have bug reports or other feedback on the software, please email [email protected] or create a new idea in the Bug Report space or Development space.

At the current release state 2024.2.2 FlexSim does not provide a tool to export an animated USD stage of a model. There is a way around though by recording the FlexSim model connected to a NVidia Omniverse live session using one of the tools in NVidia’s USD Composer, the Animation Stage Recorder. This is a step-by-step tutorial to guide you through the process. It is assumed, when you are interested in this you already know how to connect FlexSim to a live session in NVidia Omniverse. This may not be ther perfect way to go, but it worked for me. Record_Animated_Stage_from_FlexSim.pdf

The following article applies to FlexSim versions 26.0 and older. For Autodesk FlexSim 2027 and onward, please visit Autodesk FlexSim 27.0 Licensing and Sign-in Experience   Staying up-to-date   FlexSim recommends staying up-to-date and using the latest Software version. New features, improvements, and bug fixes make your simulations more stable, more powerful, and easier to build.   In addition, the Software is developed for use with contemporaneous hardware, operating systems, and drivers. Among other reasons, as third parties phase out these technologies, FlexSim must discontinue support for Software versions developed for use with those technologies.   Finally, as usage of older versions decreases, FlexSim must devote its resources to supporting more recent Software versions to best serve the majority of our customers who stay current on Software maintenance and updates.   Lifecycle and Support Policy   If you must use an older Software version, understanding the Software Support Lifecycle will help you make informed decisions about when to upgrade.   A Software release is generally supported until it is four (4) or more versions prior to the current release. For the most up-to-date lifecycle and support policy information, please see section 17. Software Support of FlexSim's Software License Agreement (SLA).   As with all future-looking plans, our lifecycle and support policy is subject to change. You should not rely on this policy for making purchasing decisions. We attempt to keep this article up to date, but in any cases where this information disagrees with FlexSim's Software License Agreement, the SLA governs.   Lifecycle status terminology   Supported - FlexSim will maintain licensing infrastructure necessary for a given Software version and will provide technical support for that version for licensed users under current maintenance or subscription. Bugfixes - Bugfixes are issued periodically for the latest Software version, as needed. A Software version typically receives bugfixes until the next Software feature release. Learn more about FlexSim version numbering and bugfixes. LTS - Long-term support versions receive bugfixes for a longer period, typically 12-15 months. Beta - Preview the next version of FlexSim Software for demonstration, testing, and validation. Beta versions may not be suitable for day-to-day production use. Beta versions are superseded by their production-release version. No support - After a Software version is 4 or more versions older than the latest release it is no longer supported. Such a version may continue to work on the computer where it is installed and licensed, but it is no longer eligible for technical support and FlexSim cannot guarantee that licensing infrastructure will remain in place to move the license key to another computer.   Supported Versions   The following Software versions are currently supported.    Application   Version   General Availability     Lifecycle Status  FlexSim 26.0 2025-12-09   supported + LTS FlexSim 25.2 2025-08-12   supported FlexSim 25.1 2025-04-14   supported   Unsupported Versions   The following Software versions are past their supported lifecycle. We recommend updating your software to a supported version.    Application   Version   General Availability   End-of-Life   Lifecycle Status  FlexSim 25.0 2024-12-11 2026-06-08 no support FlexSim 24.2 2024-08-05 2025-12-09 no support FlexSim 24.1 2024-04-08 2025-08-12 no support FlexSim 24.0 2024-12-06 2025-04-14 no support FlexSim 23.2 2023-08-07 2024-12-11 no support FlexSim 23.1 2023-04-03 2024-08-05 no support FlexSim 23.0 2022-12-05 2024-04-08 no support FlexSim 22.2 2022-08-02 2024-04-05 no support FlexSim 22.1 2022-04-04 2024-04-05 no support FlexSim 22.0 2021-12-06 2024-04-05 no support FlexSim 21.2 2021-08-09 2024-04-05 no support FlexSim 21.1 2021-04-02 2024-04-02 no support FlexSim 21.0 2020-12-04 2024-03-26 no support FlexSim 20.2 2020-08-11 2024-03-26 no support FlexSim 20.1 2020-04-10 2024-03-26 no support FlexSim 20.0 2019-12-06 2023-12-31 no support FlexSim 17.0 - 19.2 various 2023-12-31 no support FlexSim 7.7 - 16.2 various 2022-06-30 no support HC 5.3 2017-10-13 2022-06-30 no support FlexSim < 7.7 various 2020-12-31 no support HC < 5.3 various 2020-12-31 no support   Notes   The date format used is YYYY-MM-DD Bugfix releases follow the same lifecycle as the major release with which they are associated. Versions not listed should be assumed as past their supported lifecycle.