En este video aprenderán a crear la lógica con los Triggers de un Operario para que regrese después de descargar un FlowItem en un modelo de simulación. Además, se enseñan el uso de Etiquetas de referencia y la selección múltiple de objetos 3D. Para más videos tutoriales pueden suscribirse al canal de YouTube de FlexSim Andina y acceder a nuestra lista de reproducción de FlexTips.

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

The attached model contains functionality to depict the item flow as a 3D map using a FlowMapper3D Object (cylinder) and an associated Object Process Flow. Additionally a 'kpi' label on the object gives an indication of layout performance to which you can link and observe as you interact/experiment on the layout. To set this up in your model you'll need to add a Group of objects whose entry events will be used by the mapper - calling that Group "FlowMapperObjects". Then you'll need to add a ColorPalette called "HeatPalette". Finally you'll want to copy the FlowMapper3D object and the FlowMapperProcess to your model. Note that there is a boolean label 'showPercents' on the FlowMapper3D object to tell it whether to show percentage text or the number of flowitems for each location pair. 3DFlowMapper.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 flexsim.privacy@autodesk.com 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.

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 LUKS (Linux Unified Key Setup) in default mode aes-xts-plain64:sha256 with a 512-bit key. Data is encrypted in transit with SSL. 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 "flexsim@company-xyz.com". 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.

FlexSim 2024 Beta is now available. (Updated November 20) FlexSim 24.0.0 Release Notes To get the beta, log in to your account at https://account.flexsim.com, then go to the Downloads section, and click on More Versions. It will be at the top of the list. The More Versions button does not appear when logged in as a guest account. The beta is available only to licensed accounts and accounts that have a license shared with them. Learn more about downloading the best version of FlexSim for your license here. If you have bug reports or other feedback on the software, please email dev@flexsim.com or create a new idea in the Bug Report space or Development space.

If you've ever tried to nest groups of objects inside a hierarchy of planes, you may find the drawing of the planes suboptimal and lacking information: Using the container (modified plane) in the attached user library you can represent the container with just an outline. A settings dashboard is installed with the library along with some user commands and global variables. Corner prisms show the nesting layers under the prism: The option 'Use the container center' allows you to use it as either a plane as before or, when unselected, a bordered frame where dropping an object or clicking and dragging within the borders will behave as though you are dropping onto or clicking/dragging the model floor. You can also choose to hide the containers entirely for the cleanest visuals. I hope this will encourage users to use containers more, since when coupled with Templates and Object Process Flows they can increase the scaleability and make your developed assets more manageable. ( In those cases the container becomes the member instance of the process flow or template master and references to its components are made through pointer labels on the container rather than names which you may want to alter for reporting purposes. The pointer labels are updated automatically when creating a new instance of the container.) ContainerMarkers_v1.fsl If you want planes you already have in your model to adopt this style just add this to their draw code: return containerdraw(view,current);

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 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 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).

Requirements FlexSim 25.0 or later (found in the downloads page) NVIDIA's Omniverse USD Composer Background Historically, users have used USD Stages in FlexSim to create a live connection with an Omniverse application to be able to simulate animations in Omniverse. However, this relies on a live connection between FlexSim and Omniverse. Sometimes this type of connection is sub-optimal for a user's situation. This article will explain a workflow for writing animation data to a USD file to play in an Omniverse application independent from FlexSim. Disclaimer All the data we record during this example is meant to help us write meaningful data into a .usd file so we can generate an animation in USD Composer. When I say "animation", I mean positional and rotational data along with showing/hiding flowitems. If you want to see Operator Skeletal Animations, I'll post a similar article with a few tweaks later to showcase how to do that using USD Composer's Sequencer, which uses Tracks and Asset Clips to handle small-scale skeletal animations. Example Model I've built a sample model demonstrating the changes to the USD API and how to use them. This example model is just one way to use the API -- there are other ways that users are free to explore. example_model.zip Explaining the Model When you open the model, you'll see a few different windowpanes. In the top-right corner, you'll see a Global Table. If you reset the model, you'll see column headings appear. Each column is a different piece of data we'll be writing to the USD Stage. Each row is a different entry of data to write. In the center views, you'll have a 3D view on the left side and a Process Flow (PF) on the right. At the bottom, there's a script window with a few lines of code. Those lines of code are User Commands I defined to summarize the functionality they encapsulate. The 3D View In the 3D view, you should see some queues, processors, operators, and conveyors. This is a simple workflow where items come into the queues, operators move them into the processors for processing, and then the operators send them down the conveyor lines. With this model, we'll demonstrate (1) operator movement and (2) flowitem movement on conveyors. Setting Up the USD Stage There should be a "USD Stage1" present in the model. If you click on the USD Stage, its properties will appear on the right-side of the screen. In it, you'll see a blank edit field. This is where you put the path to the USD file you want to work on have appear. If you want to save a fresh one, while the edit field is blank, click the "Save" icon next to it. Once you select where you want to place the file, name it, and close the file explorer popup, the edit field should populate with the full path to the .usd file. For more info, you can check out the docs page on the USD Stage object. Viewing the Model in USD Composer Once you've saved your USD Stage, you can open the .usd file in any software that can view .usd files. For this demonstration, we'll be using NVIDIA's Omniverse application which as a USD Composer module. The Process Flow Open up the Process Flow tab to view the simple setup. I'll walk through each part of the PF to give you an idea of how it works. Operator Movement This block of PF is in charge of recording information about Operator positions and rotations. It records information whenever an Operator starts and ends a task. You can expound on this concept and record information when specific triggers or events happen, but for this example I kept it simple and record when any task happens. User Command: RecordInfoToTable Within the "Record Info" Activity, it calls a User Command to record information to the table. This function simply takes a token as the first parameter. This is what the code looks like: Token token = param(1); // Setup row for this iteration Table animInfo = Table("AnimationInfo"); animInfo.addRow(); int curRow = animInfo.numRows; token.labels.assert("Row", 1).value = curRow; animInfo[curRow]["Object"] = token.operator; animInfo[curRow]["AnimTime"] = Model.time; animInfo[curRow]["TaskType"] = token.taskType; // Record positional and rotational data Object operator = token.operator.as(Object); animInfo[curRow]["PosX"] = operator.location.x; animInfo[curRow]["PosY"] = operator.location.y; animInfo[curRow]["PosZ"] = operator.location.z; double Z = Math.fmod(operator.rotation.z, 360); if (Z < 0) Z += 360; animInfo[curRow]["RotX"] = operator.rotation.x; animInfo[curRow]["RotY"] = operator.rotation.y; animInfo[curRow]["RotZ"] = Z; To summarize: Start by assigning the value of the token (parameter 1) to the local variable "token" We get a reference to the Global Table (AnimationInfo) and add a row for the data we're about to write Record (1) which operator this data is for, (2) what time this is happening, (3) and the type of task they're performing. The task type isn't as important - it's for finer details and debugging if necessary. Then we record the positional data of the operator. We previously saved the "operator" label onto the token, so we can use that and "cast" it to be an Object. We do this because the Object class has a "location" property which holds the x, y, z coordinates of the object. Lastly, we do the same thing with "rotation", except we need to bound the rotation to be a positive number between 0 and 360. To do this, we call Math.fmod() to get the reminder after dividing by 360. If the value is negative, we add 360 to get a positive value. Running the Model If you reset and run the model to the stop time at 200, you'll see the Global Table populate with data. There should be valid data for all the columns except the last 3. The "BoxNum", "EntryConveyor", and "Show" columns are for recording flowitem data. We'll discuss that later. Once you've got data in the table, we can run the User Commands in the script window at the bottom of the screen. They should be: ClearTimestampedData(); return WriteToUsd(); The first one "ClearTimestampedData()" is used to loop through the operators and clear all their time-sampled data. We do this so no old data is used if you change things in the FlexSim model and export new data. The second one "WriteToUsd()" is what reads the Global Table line by line, defines and finds prims, writes time-sampled data to them, and saves the information to the .usd file. View the Animation in USD Composer After running these scripts, you should get a prompt in USD Composer to "Fetch Changes". Fetch the changes. Then, open the Timeline feature (Window > Animation > Timeline). This opens an animation timeline at the bottom of the screen. You can save predefined start and end times for the whole stage using the Flexscript API if you choose. Otherwise, you can change the settings manually in USD Composer. (I've color-coded the image below to help explain the tool.) On the far-left (green circle) is the starting frame of the animation while the far-right (red circle) is the ending frame. The inner numbers allow you to set specific sections of the animation to play. If not set, it will play the whole animation. The top-right value and blue "scrubber" (blue circle and arrow) denote the current frame. When you hit your space-bar (or click the "Play" button), that scrubber should move. The value next to FPS (yellow circle) represents the "Frames per Second" the animation runs at. If you want it to play faster, then you can set it to a higher FPS. Note that this example model is built assuming 24 FPS. There is a User Command "TimeToFPS" that simply multiples the given Model time by a desired FPS, defaulting to 24 FPS. If you want to change that rate, you can set it in the code. Now that we've got the animation timeline setup, hit play and watch the animation. You may need to adjust the animation range to be 850 to 4800 so you can see the movements. Like I mentioned in the Disclaimer, if you want to see skeletal animations in the Operator, I'll have another article explaining how to add that functionality. Add Flowitem Movement on the Conveyor Let's go back to FlexSim and check out the Process Flow again. I have two other containers labeled "Box Movement: Time-based" and "Box Movement: DPs". These flows represent two different ways to record this data: either based on a time interval or based on Decision Point positions. The time-based way can be more accurate, but it adds much more time-sample data than the DP version. Choose one of the versions to test out, open the properties of their Source, and then Enable it. If you reset and run the model, you'll start seeing entries for Flowitems. They'll utilize the last 3 columns of the Global Table to keep track of (1) the Box# they are, (2) the Conveyor they entered on, and (3) whether or not to "show" their prim. Click here to learn more about prim visibility. Run the scripts to export and save the model. Then, fetch and view the changes in USD Composer. Conclusion We've covered how to use some of the new features of the USD API in FlexSim 25.0 to create stand-alone animations in .usd files. We used FlexSim to record and export data to .usd files to then display in USD Composer. You can now play a standalone animation in USD Composer without a live connection to FlexSim.

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.