FlexSim 2023 Update 1 Beta is now available. (Updated March 14) FlexSim 23.1.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 [email protected] or create a new idea in the Bug Report space or Development space.

Attached is an example simulation of a rail hump yard. Trains in this hump yard are processed in three stages: Arrival - A train engine delivers an arriving train into the arrival area of the yard and then leaves Classification - The shunt engine takes trains from the arrival area to the hump. From there the train is uncoupled into sets of cars for classification, and each set of cars 'falls' to its designated departure train and couples to it. Departure - Once a train has been composed, it is transferred to the departure area, where it waits a random time until departure. I've tried to keep the logic as simple as possible so you can understand the process flow. I've implemented no traffic control between train engines/shunt engine, so they will occasionally run over each other. However, I have used AGV routing constraints to dynamically block off sections of track that are filled by trains, so the engines will move around them. HumpYardSample.fsm

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

The Statistics Collector is a powerful object. Its purpose is to record data about the model run as a table, and it is very effect at doing that. However, it is very abstract; being abstract allows it to be highly flexible, but makes it more difficult to learn. This article is meant to help you understand (or remember) how the Statistics Collector models the problem of converting model data from objects and events into a table of data. This article compares a Statistics Collector to a train being loaded an unloaded. It is NOT an article about how to model a trainyard or other rail-industry systems. The purpose is to compare the Statistics Collector, which is very abstract, to something most people understand. So we'll start by talking about the story of a simple freight train. This story has the following elements: Starting - the train starts its journey a the beginning of the line Loading Stops - the train makes several stops along the way to load goods Unload Planning - unlike a normal train, this train determines where it needs to go after this point based on what was loaded into the train Unloading Stops - the train makes several stops along the way to unload goods This is a very simple story. Just keep the sequence in mind - the train starts, makes several load stops, figures out its destinations, and then makes several unload stops. To see how this is like a Statistics Collector, take a look at this model: StatsCollectorVisualization.fsm This model is very simple. It consists of a Source, Queue, Processor, and a final Queue: Items are generated at the Source and flow through the Model. Items have a Type label, so that there are three Types of items: Type 1, Type 2, and Type 3. If you zoom out, you'll see a much bigger section of the model: This section simulates the logic of a Statistics Collector. As the model runs, you'll see AGVs run along the track, like a train. You'll see them make several stops and pick up boxes. Then you'll see them stop at the "Table" (the bigger black box in the image above) and "unload" data into the table. The Statistics Collector tool is a lot like this simulation. It has an internal "train", and you reference that train with the keyword data. When you use the Statistics Collector, you are configuring the journey of the train, which determines what data is recorded in your table. Starting the Train The statistics collector creates a train (the data object) when it observes an event. You configure which events a Statistics Collector cares about on the Events tab. You can listen to many different things, including: A flowitem enters or exits an object A token enters or exits an activity The model is reset The model gets to the warmup time Whenever any of these things happen, the Statistics Collector creates a train (again, called data) and starts it going on its journey. In this example, the Statistics Collector listens for items to enter Queue1. It also listens for items to exit the processor. Either event will start a train. Loading the Train Once the train is going, the Statistics Collector "loads" the train with information. In reality, this happens by adding labels and setting values on data. First, data gets all the values associated with the event (the event parameters) assigned as labels. Then, data gets all the labels specified in the "Additional Labels" section. Finally, data visits the Row Value station. Here, the special property called rowValue is set. Note that as you load the train, you can use anything already on the train to get more information loaded on train. In the example model, the row value is set to "data.item.Type"; data is the train, and the "item" label is already on board, so the row value field can use that to load additional information. Unload Planning The next stop for the train is something that you can't really see, but that is very important. The Statistics Collector inspects the row value on data. The Statistics Collector remembers all row values that it has ever inspected, and it adds a row to the table for each unique row value. This is where the row value got its name. If the Statistics Collector sees a value it has never seen before, it adds a row to the table, and associates the new row with the row value. Once the row is either added or found, the Statistics Collector sets the property rowNum on data. So now, the train knows which row it is going to visit. All that is left in this phase is to figure out which columns the train will visit. First of all, if the row was added, the train will visit all the columns to set their initial value, which is called the Row Add Value (the value to set when the row is added). Whether or not the row was added by the event, the train will also visit any columns that are connected to the event, setting the value to the Event Value (the value to set when a connected event happens). So in summary, the Statistics Collector figures out which row the train will visit based on the row value, adding a row if necessary. If the row was added, then the train visits all columns in the row, to set the Row Add Value. If the event is connected to any columns, the train will also visit those columns, and set the Event Value. Unloading the Train Finally the train can unload data into the table. As it visits each cell, it unloads information into that cell. As the user, you configure what gets unloaded at each cell. You can unload anything into the cell, including anything on the train, anything connected to anything on the train, or anything globally accessible. In reality, whenever the Row Value or Event Value is evaluated, you can access and labels or properties on data. You can also use values on data to access other values. Or you can access global values, such as the current model time, or a Global Variable, or a value in a Global Table. In the example model, the Event Value field accesses the value that is currently in the table at the cell being visited by data. Does the statistics collector really have to travel? In the visualization model, the data train takes up time on the clock to load, plan, and unload. However, for the true Statistics Collector, all of that happens in zero time. For example, when an item enters Queue1, the real statistics collector in the model finishes updating instantaneously. In contrast, the visualized statistics collector train is still moving to get more labels. This is for illustration purposes only. What about "Update when accessed" columns? All Statistics Collectors know when something is trying to read their values. For example, if you have a chart pointed at a Statistics Collector, and that chart repaints, it will read the Statistics Collector. Or if you access the table through FlexScript with code like Table("MyStatisticsCollector")[1][1], that will read the Statistics Collector also. So in a way, it's just another event. However, there are two differences: You can't load custom labels on the train for this event; it "skips" those stops The train visits all rows in the table When you set a column to update when the value is accessed, you are basically connecting it the "OnAccess" event. So when the table is accessed, the data train visits all rows of the table. For each row, it gets the rowValue and rowNum properties set, and then it visits all the "update on access" columns. What about other features? This article just covers the basics, and doesn't cover other features of the Statistics Collector. Just know that there are many ways to configure the train's journey. For a full reference, see https://docs.flexsim.com/en/21.0/Reference/Tools/StatisticsCollector/ However, all of the features discussed in the reference add more detail; you can just improve your mental image of how the Statistics Collector works.

The following articles describe various error messages and numbers you may see as you work with your FlexSim licenses, along with possible solutions and workarounds.   flxActCommonHandleOpen (50003, 71000, 10103) flxActAppReturnSend (50018, 41145, 32) Manual activation error (50019, 41200, 19) Manual XML licensing error (50019, 42107, 10246) Licensing activation error (50041, 41143, 34)   Operations error: 7032 Invalid fulfillment ID Operations error: 7109 Invalid activation ID Operations error: 7131 Server activation is not allowed Operations error: 7174 Only deployed entitlement line item can be fulfilled Operations error: 7189 Client activation is not allowed Operations error: 7284 Cannot perform support actions on inactive fulfillment record Operations error: 7288 fulfill count exceeded the available seat count Operations error: 7466 The return of the fulfillment is denied Operations error: 7581 Online return/repair request is not originated from the original client machine   Trusted storage binding change detected

When you try to activate offline, the following error might appear in the console: ERROR: flxActSvrActivationRespProcess - (50019, 42107, 10246) "Failure to process response for an unspecified reason. This error may be returned when a valid failure response is received, for example when the activation server denies a request. Recovery: check parameters used for the request." License Server Manual XML Activation error example: Standalone Manual XML Activation error example: If you encounter this error, check the response.xml file you are attempting to process. If it includes the text SERVER_CONFIG or CLIENT_CONFIG, but your Trusted Storage is already configured, you may receive this error. With Trusted Storage already successfully configured, you must generate a brand new activation request. Upload the new request to your FlexSim Account for processing. If the license is available you will be able to download the XML response. This response should process and successfully activate your license. Full instructions for performing manual XML licensing for license servers can be found in our license server installation instructions document. ===== Here are some other items to keep in mind with manual XML licensing on your license server: Download the response XML files and transfer them to their license server without modification. Modifying the XML files in any way will "break" them. This includes line endings and other white space. The files include checksums and if the files change they will not work. The destination license server needs to be the same system where the request was generated. The FlexNet Licensing Service 64 needs to be installed, be a high enough version, and be running properly as a Windows service. Checking these items is covered in our license server installation instructions starting on page 6 with 3. FlexNet Licensing Service. flexsimserveractutil.exe may need admin privileges to write to the proper places on the system. Be sure to right-click the application and choose Run as Administrator.

FlexSim 2020 is available. If you have bug reports or other feedback on the software, please email [email protected] or create a new idea in the Development space. Release Notes Changed models to automatically open the environment in which they were saved. Added boy and girl shapes to people visuals. Improved keyboard interactions within table views. Improved tabbing between fields in certain windows. Updated the 3D names and stats text rendering to support more fonts and Unicode. Improved the 3D view's lighting capabilities by adding Light objects that can be arranged in the model. Improved lighting in RTX Mode, including support for soft shadows and a denoiser. Adjusted the Rack Dimensions tab to be able to specify slot padding. Added an optional parameter to TaskSequence.create() for waiting until TaskSequence.finish(). Added an OnValuePulled event to the List. Added methods for creating a DateTime using a string or component parts. Added support for in-place addition and subtraction of DateTimes. Fixed bugs with DateTime methods when using certain years or ranges of time. Improved the convert() command's capabilities with converting dates and times. Improved the exporting of null bundle values to Excel. Added an excelcreateworkbook() command. Added statistics collectors and calculated tables to the Excel Export. Added an option for creating sheets using the Excel Export. Fixed rotation issues with pasting certain objects. Added a Vec3.projectRotation() method. Added a Vec2 FlexScript class. Changed the License Activation window to be responsive during licensing operations. Added an index type to statistics collector columns for improving performance. Added a categorical combo type to tracked variables. Updated the query builder to handle CASE statements. Simplified certain queries written by the query builder. Changed the tree structure to simplify creating custom webserver interfaces. Added a repeat type to animations for remaining in the last frame after running the animation. Added a Go To Row/Column option in quick properties for tables. Improved time plots to be able to show durations as well as calendar times. Added an optional wire mesh rack visualization. Added more picklist options to the storage object slot assignment strategy. Updated the animator so that keyframes are updated using a right-click menu option instead of automatically. Added an option to duplicate an animation keyframe into another animation. Changed the default network node speed limit to 0 (no speed limit). Reorganized the Use Transport pick list and added a No Transport Reference option. Fixed a bug with the rack's default pull requirement not reevaluating after becoming full. Fixed an issue with copy/pasting sub-locations. Fixed the dark patterns when zooming out in RTX Mode. Fixed a crash on certain hardware in RTX Mode when rendering too many transparent layers. Improved the Time Table Date Based GUI to draw past the last event and allow scrolling into the future. Added PushWheelchair and PushCart animations to Operators Backwards Compatibility Note: the following changes may slightly change the way updated models behave. Time tables now combine consecutive down periods if using the same state and profile or the same down behavior. Fixed issues with pick/place offsets on drive in racks to improve usability with A*. Because of performance improvements to query(), the row order is not guaranteed unless using an ORDER BY statement. Fixed excelrangewrite() so that the correct overload is available in FlexScript. Improved the FlexScript hypertext preprocessor scoping mechanism used by the webserver. Fixed object color being applied incorrectly to ambient material color on certain meshes. Changed point source light attenuation. Changed TASKTYPE_NODEFUNCTION to pass variants in as parameters instead of interpreted legacy doubles. This fixes the types of arguments that are passed when calling treenode.evaluate() as part of a TASKTYPE_NODEFUNCTION task. This allows you to add TASKTYPE_NODEFUNCTION tasks with parameters that are not just numbers, (nodes, strings, arrays, etc.) and have those parameters be preserved in a type-safe manner and properly passed into the subsequent treenode.evaluate() call. However, this change may have some consequences for older models. The following guidelines apply: If you use the inserttask() command, and cast a node to a number with tonum() to pass it in as a task variable, then you should use parnode() to get those parameters out in the nodefunction. While this method will continue to work, this mechanism is nevertheless deprecated. The now-correct method for adding a TASKTYPE_NODEFUNCTION task to a task sequence is to use TaskSequence.addTask(). This method takes full Variants as its task variable parameters, so you do not need to use tonum(). When using this, you should use param() to get the parameters back out. Older models that use neither of these methods may need to be updated to use method 2 in order to work properly in this version. Process Flow Changed the default behavior of the Create Task Sequence activity to work easier with task sequences created outside of Process Flow. Added a Finish Task Sequence activity that works with the new Create Task Sequence features. Changed the default value of Task activities from token.resource to token.taskSequence. Improved the interface for connecting activities. Added a mechanism for connecting to and from containers and routing tokens between activities using those connections. Added an option to the Run Sub Flow activity to run tokens one at a time. Adjusted the size of containers and connections based on the zoom level when created. Removed the width attributes of themes. Improved the UI for entering times in the Date Time Source activity. Change Set Color By Case and Set Object Color pick options to enable setting the color of a token. Fixed the display of task parameters in the event log. People Improved people resource shared assets to be able to reference other people resources. Added Sort By and Filter By fields to people resources. Simplified and improved several activity sets. Improved the list of labels in drop-down menus to include People Settings labels. Added a Kiosk to the list of locations. Added an Observation Room multilocation. Added an option to the Toolbox to add all people tables to the Excel Export. Added more people tables and charts. Improved the performance of many existing people tables and charts. Updated preempted resources to be able to be reacquired with a higher priority. Updated Escort Patient and Tranpsort Patient activities to set the staff's TravelingWithPatient label when escorting or transporting a patient. Improved the query builder interface with support for adding group/individual subsets. Changed people acquire activities to have the default max wait timer trigger release the token out connector 2. Changed the Split activity default to creating child tokens in the Healthcare environment. Changed the repeat type of the LayDown and SitDown/SitDown2 animations to repeat the last frame. Backwards Compatibility Note: the following changes may slightly change the way updated models behave. Changed how labels are handled by People Settings. Improved animations and positioning of transports and equipment when staff move them. Emulation Added support for OPC UA connections.

In this article, you will learn how to export data from individual replications to an external database. This is an advanced tutorial, and assumes some exposure to databases and SQL. It also assumes that you are familiar with the Experimenter and/or Optimizer feature in FlexSim. This tutorial uses PostgreSQL, but should be compatible with the most popular SQL database engines. Model Description Let's assume you have a model with at least one Statistics Collector, as well as an experiment ready to go. The model used in this example is fairly simple: As the model runs, a Statistics Collector fills in a table. The table makes a new row for every item that goes into the Sink, recording the time, and the Type label of the item: For the experiment, we don't have any variables, but we do have one Performance Measure: Input of the Sink. Of course, an actual model would have many Variables, Scenarios, and Performance Measures, but this model leaves out those details. For reasons which come up later, this model also has two global variables, called g_scenario and g_replication. We will use these during the experiment phase. Connecting to the Database To connect to a database, you can use the Database Connector tool. Each Database Connector handles the connection to a single database. If you need to connect to more than one database, you will need more than one Database Connector. For this model, I have added a Database Connector, and configured the connection tab as follows: This configuration allows me to connect to a PostgreSQL database called "flexsim_test" running on my computer at port 9001. You can test the connection by clicking the "Test Connection" button. The test attempts to connect, as well as query the list of tables found in the database. Setting Up the Export Next, take a look at the Export tab: This tab specifies that we are exporting data from StatisticsCollector1 to the table called experiment_results in the database (this table should exist before you set up the export). The Append to Table box means that when the export occurs, the data will be added to the table. Otherwise, the data would be cleared from the target table. The other interesting thing here is that we are exporting more columns than the Statistics Collector has, namely the Scenario and Replication number. However, the expression in the From FlexSim Column column must be valid FlexQL (FlexSim's internal SQL language). Wrapping the values in Math.floor() leaves the values unchanged, and works well with FlexQL. Setting up the Experimenter Finally, let's take a look at just a little bit of code that makes the Experimenter dump data to a database. There is code in Start of Experiment, Start of Replication, and End of Replication: In the Start of Experiment, we need to clear the table. The code in this trigger connects to the database, runs the necessary query, and the closes the connection to the database. In the Start of Replication trigger, the code simply copies the replication and scenario values into the global variables we created for this purpose. In the End of Replication trigger, the code uses function_s to call "exportAll" on the database connector that we created. This uses the settings on the Export tab to dump the data from StatisticsCollector1 to the database table, including the replication and scenario columns. These same triggers run during an optimization, so the same logic will apply. Run the Experiment Finally, you can run the experiment. When each replication ends, the Statistics Collector data will be exported to the database. Databases can handle many connections simultaneously. This is important, because the child processes that run replications will all open individual connections to the database at the end of each replication. This leads to many concurrent connections, which most databases are designed to handle. But how can we tell that it worked? If you connect to the database with another tool, you can see the result table. Note that there are 1700 rows, and that data from Replication 5 is included. Additionally, you could use the Import tab to import all the data, or summary of the data data, into FlexSim. Conclusion Storing data in a database during an experiment is not difficult to do. There are many excellent tools for analyzing and visualizing database tables, which you could then use to further explore and understand your system. postgresqlexperimentdemo.fsm

FlexSim Answers is designed to make information available to the FlexSim community. However, there are times when you will need help with a model or project that contains proprietary or otherwise confidential information. Here are a couple ways of getting the help you need while protecting sensitive information. Private Questions When you create a question you can mark it as Private. The question is then only viewable to FlexSim employees. A lock icon will show up next to the question for those who can see the question Comment Visibility (Currently this option is only available to moderators, but moderators may use it to make comments visible only to you and other FlexSim employees) You can also post private comments by setting the visibility level of your comment. Setting the visibility of the comment to Viewable by Moderators will make the comment visible only to FlexSim employees. Posting private comments is useful for posting confidential information to questions that aren't private.

Have you received this licensing error? An error occurred in the activation request Operations error: 7174 Only deployed entitlement line item can be fulfilled. You may encounter this error if your license code is no longer valid or is in need of support. Here are some common scenarios where this might happen: If this was a timed license that has expired, it is no longer viable and was likely obsoleted. If the license was upgraded, you need to make sure you're using the latest version of the activation ID, as any older versions of the license code will not work once an upgrade of the same license has been used. If the license model was changed from standalone to license-server (or vice-versa) you may be trying to use an old license that was replaced. If your license was put into a support state and was not changed back. If you are encountering this error, please start a new Private Question and include your activation ID. We'll be able to look up the specific situation for your license. Or you can reach out to your local distributor for direct phone, email, or web support.

FlexSim 2021 Update 1 Beta is now available. 21.1 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. Subsequently 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 [email protected] or create a new idea in the Development space.

One of the most powerful features of Process Flow is the ability to easily define a Task Sequence. However, many real-life situations require the coordination of multiple workers and machines to do a single task. This article demonstrates one approach you can use with Process Flow to coordinate multiple Task Executers, or in other words, to create a coordinated task sequence. This article talks about an example model (handoff.fsm). It might be easiest to open that model, watch it run, and perhaps read this article with the model open. The Example Scenario Here is a screenshot of the demo model used in this article: Items enter the system on the left. The yellow operator must carry each item to the queue in the middle, and then wait for the purple operator to arrive. Once the two operators are both at the middle queue, then the yellow operator can unload the box, and the purple operator can take it. After this point, the yellow operator is free to load another item from the left queue. The purple operator takes the item, waits for a while, and then puts the item in the sink on the right. The interesting part of this model is the hand off. The yellow operator must wait for the purple operator, and vice versa. This is the synchronization point, and it requires coordination of both operators. The approach used in this model allows you to add more operators to the yellow side, and more to the purple side. But it still maintains that a yellow operator must wait for a purple operator before unloading the box. The Example Model In addition to to the 3D layout shown previously, there are 5 process flows in the example model. The first is a general flow, and defines the logic for each task. The second is a Task Executor flow, and defines the logic for the yellow operator. The third is also a Task Executor flow, and defines the logic for the purple operator. The remaining two flows are synchronization flows, for synchronizing between the other three flows. Synchronizing on a Task The basic approach in this model uses the Synchronize activity. This activity waits for one token from each incoming connector, before it allows any of the tokens to move on. Here is the Yellow Purple Sync flow (a global Sub Flow) from the example model: The flows for the yellow and purple operators each use the Run Sub Flow activity to send a token to this flow, to their respective start activities (you can use the sampler on the Run Sub Flow activity to sample a specific start activity in a sub flow). This is what allows both the yellow and purple operators to wait for each other. However, it is important that the yellow and purple operators are both doing the same task. In this model, there is a token that represents each item that needs to be moved. Both operators get a reference to this task token. The Synchronize activity is set up to partition by that Task token. That means that a yellow and purple operators must both call this sub flow with the same task token, ensuring that each task has its own synchronization. In the example model, this kind of synchronization happens between operators, and it happens between each task and an operator. Basically, the task must wait for the operator to finish that operator's part. The Task Flow A task token is created every time an item enters the first queue. The tasks flow puts that task on both the Yellow and Purple lists. In both cases, the task token does not wait to be pulled, but keeps itself on the list. Then, the task token waits for a yellow operator to finish with it, and then for the purple operator to finish with it. There is a zone in this flow, but its only purpose it to gather statistics for how long the whole task took. The Yellow and Purple Flows These flows are easiest to understand when viewed side by side: Recall that each task is put on both the Yellow and Purple lists at the exact same model time. The yellow operator waits to get a task (at the Get Task activity). Then the operator travels to the first queue, gets the item, and travels to the second queue. At this point, the yellow operator waits. At the same time, the purple operator is also waiting for the task. The purple operator just has to travel to the second queue before waiting for the yellow. Once the yellow operator arrives, the purple operator also has to wait for the yellow operator to unload the box. On the yellow side, once the purple operator arrives, the yellow operator unloads the box, and then synchronizes with the purple operator, allowing the purple operator to load the box. Summary The purpose of this article is to show one method for synchronizing token in separate flows. That method is as follows: Have a token for each task. As each task executor (or fixed resource) needs to synchronize, they each use a Run Sub Flow activity, putting the token in a specific Start activity. The Sub Flow (a global Sub Flow) has a synchronize activity, that requires a token from each participant for that task before releasing the tokens. This is certainly not the only way to create this model. However, there are some advantages: By forcing the task to synchronize, you can gather stats on how long each phase of the task took, as well as how long the complete task took. You can add more yellow or purple operators by copy/paste. They simply follow their own logic Each set of logic is separated; tasks, yellow operators, and purple operators each have their own flows, making each one much simpler. The exact approach used in the example model will not work exactly as it is for each model. However, you can apply the general principles, and adapt them to your own situation.

Have you received this licensing error?   Operations error: 7581 Online return/repair request for the activation ID example.com01-ABCDE-FGHIJ-KLMNO-FSENT22.2 is not originated from the original client machine.   This error means that the licensing system did not recognize the the computer that requested the repair is the original computer where the license was initially activated.   This can happen when: It is not the same computer. Maybe the user activated a license, then moved the hard drive to a new computer (or cloned it, etc). This would break the license, and it wouldn't be able to repair because the licensing system recognizes that the computer hardware is different. There was a significant change to the computer. A large operating system update, a change to the hard drive's boot sector (for instance, installing a 2nd operating system to dual boot), or another significant hardware change.   In this case the license cannot be returned, and it cannot be repaired. You will need to contact your local FlexSim representative to explain the situation.   As you work with your FlexSim rep, they will guide you in deleting your unreturnable/unrepairable fulfillment (license server, standalone), then after your FlexSim rep performs a license force-return, your license should be available again for a new activation.

Cycle time per process.fsm Cuando creamos modelos de simulación en ocasiones nos limitamos a modelar un proceso o un numero de parte, en el cual tenemos problemas. Pero ¿Qué pasa cuando corremos un plan de producción completo con distintos números de parte, que ha su vez corren a diferente tiempo ciclo? Este es una manera que permite correr diferentes números de parte en diferentes procesos tantos como tu desees, cada uno con su tiempo ciclo. ¿Qué necesitamos? 1.- Etiqueta en cada ítem que identifique que numero de parte es. Por ejemplo Label: IDpart Value: ABC12 2.-Etiqueta en cada máquina que identifique el proceso que este corre. Por ejemplo Label: Station Value: Processor1 3.- Tabla global que contenga en las columnas los diferentes procesos que tienes en tu línea de producción y en los renglones los diferentes números de parte que pueden correr en tu línea. La información que contenga esta tabla será referente a los tiempos de ciclo de cada numero de parte en cada proceso. Por ejemplo: Processor1 Processor2 Processor3 ABC12 20 10 13 BAC21 11 30 20 4.-Deberas configurar el tiempo de procesamiento de tu processor haciendo referencia a tu tabla global y colocando lo siguiente: Con esto, obtendremos estadísticos ponderados de utilización para los equipos. Beneficios: Puedes correr diferentes números de parte en una misma línea con su respectivo tiempo ciclo cada una. Utilización de equipos y operadores mas exacta. Modificar tiempos ciclos en una tabla global es más fácil y controlado que directo en los procesos. Cálculo de capacidad de tu línea más exacta corriendo un plan de producción real. Puedes agregar y quitar procesos o incluso modificar el flujo de tu línea sin afectar el tiempo de ciclo que corra ese procesador. Ya que esta referenciado por su etiqueta a la tabla global.

FloWorks 25.1.0 is now available (15 April). This version of FloWorks is intended for use with FlexSim 2025 Update 1. If you are using FloWorks with FlexSim 2024, please update to FloWorks version 24.0.8. If you are using FloWorks with FlexSim 2024 Update 2, please update to FloWorks version 24.2.2. If you are using FloWorks with FlexSim 2025 (LTS), please update to FloWorks version 25.0.2. 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.1.0 (15 April 2025) All changes in version 25.0.2 FloWorks 25.0.2 (15 April 2025) All changes in version 24.0.8. Improvement: Updated FloWorks tutorials Bug fix: merged duplicate "Modules" folders in offline User Manual 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. For FlexSim 25.0.0 and FlexSim 25.0.1, please use FloWorks 25.0.0 or upgrade your FlexSim version. FloWorks 25.0.0 (19 December 2024) Improvement: FlowConveyor can be reversed. All bug fixes in FloWorks 24.2.1 below. FloWorks 24.2.2 (15 April 2025) All changes in version v24.0.8. Bug fix: merged duplicate "Modules" folders in offline User Manual 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.8 (15 April 2025) Improvement: Setting .content of multi-product tank will now increase or decrease layers as if there was inflow or outflow. Improvement: Internal build tools updated to ensure for example FloWorks FlexScript API documentation is always updated and Table of Contents of online and offline manual are synchronized. Improvement: Installer no longer contains the build number in the filename (e.g. FloWorks_25.0.1.msi instead of FloWorks_25.0.1.2348721.msi). Improvement: More actions create a module dependency, such as creating a FloWorks object through Object.create . Improvement: Start joint of a flow pipe can now be dragged too; also added controls on the segments to drag the whole pipe in z-direction. Improvement: Impact ID in functions like FlowObject.stop() are now Variant instead of treenode . Backwards Compatibility Note: The following may change the way updated models behave. Improvement: Setting trigger interval will now cancel and recalculate already scheduled trigger. See the extended note at Set Flow Trigger - "Interval (each)". 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.6 or upgrade your FlexSim version. 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

FlexSim 2024 Update 2 Beta is now available. FlexSim 24.2.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 create a new post in the Bug Report space or Development space.

This article explores an example model. In this model, items on downstream lanes are able to reserve dogs so that items on upstream lanes cannot use them: reservedogdemo.fsm About Dogs in FlexSim FlexSim simulates dogs on a power-and-free system in an extremely abstract and minimal way. A dog isn't a persistent entity at all. Instead, FlexSim calculates where dogs would be, given the speed, and when they would interact with items. This has a huge performance benefit. But if your logic needs items to interact with specific dogs, this can pose a problem: how do you interact with such an abstract entity? The Catch Condition The only time you can "see" a dog in FlexSim is during the Conveyor's Catch Condition: https://docs.flexsim.com/en/23.1/Reference/PropertiesPanels/ConveyorPanels/ConveyorBehavior/ConveyorBehavior.html#powerAndFree The catch condition fires when a dog passes by an item. If the catch condition returns a 1, the item catches the dog and transfers to the power and free conveyor. If the catch condition returns a 0, the item does not catch the dog. During the catch condition (and only during a catch condition), you can learn many things about a dog: ID - each dog has an ID. The ID is derived from the length of the conveyor and by the distance the conveyor has travelled. If a conveyor is 26 dogs long, the dogs will have IDs 1 through 26. Location - Since an item is trying to catch the given dog, you can derive the dog's location from the items location. Speed - The conveyor that owns the dog is "current" in the catch condition. So you can get the speed of the conveyor at that point. We'll use all these pieces of information in a moment. Creating Tokens to Represent Dogs The first real insight into this model is to make a dummy item. The purpose of this dummy item is to cause the Catch Condition to fire. It never gets on the conveyor. But when the catch condition fires, it makes a token that represents the dog. In this example, that item has a label called "DogFinder" Here is the relevant code from the catch condition: if (item.DogFinder?) { Object pe = current.DogPE; if (pe.stats.state(1).value == PE_STATE_BLOCKED) { return 0; } double dist = current.MaxDogDist; double speed = current.targetSpeed; double duration = dist / speed; if (!item.labels["DistAlong"]) { item.DistAlong = Vec3(item.getLocation(1, 0, 0).x, 0, 0).project(item.up, current).x; } Token token = Token.create(0, current.DogHandler); token.DistAlong = item.DistAlong; token.Conveyor = current.as(treenode); token.Duration = duration; token.DogNum = dogNum; token.Speed = speed; token.DetectTime = Model.time; token.release(1); return 0; } There's a lot going on in this code: This logic only fires for the fake dog finder item If the photo eye just upstream from the dog is blocked, that means there is an item, and this dog is not available. Return here if that's the case. Figure out how long this dog will last (the duration), assuming the conveyor runs at the same speed. In this model, there's a label on the conveyor called MaxDogDist. This is the distance from the PE to the end of the conveyor, minus 2 meters. If this is the first dog ever, calculate the position of the dog, given the position of the item. Store that on a label. Create a token with all kinds of labels. We'll need all this information to estimate where the dog is later, and to estimate how far it is from other items. Pushing Dog Tokens to a List Once the token is made, we need to push it to a list, so that items can pull them. If all your items are the same size, you can just push the token to a list directly. In this model, however, there are larger items that require two dogs. So there's a batch activity first. The dummy item is far enough back that it can detect two dogs and still push the first dog to the list in time for the first lane. So it holds the dog back in a Batch activity until one of two things happen: Either the next dog token appears, completing the batch. Or the max wait timer on the batch expires, indicating that the next dog is not available. Otherwise, there would have been a token. This duration is based on the conveyor's speed and dog interval. If the batch is complete, the first dog in the batch can be marked as a "double", meaning the dog behind it is also available. Once the flow has determined whether the dog is a single or double, it then pushes it to the list. Creating the DistToDog Field When pulling the dog from the list, an item needs to know the position of the dog relative to the item. Is it 0.3 meters upstream? Or is it 2 meters downstream? When we query the set of dogs, we need to filter out downstream dogs and order by upstream dogs, to reserve the closest one: WHERE DistToDog >= 0 ORDER BY DistToDog Here, DistToDog is positive if the dog is upstream, and negative if the dog is downstream. The code for this field is as follows: /**Custom Code*/ Variant value = param(1); Variant puller = param(2); treenode entry = param(3); double pushTime = param(4); double distAlong = Vec3(puller.getLocation(1, 0, 0).x, 0, 0).project(puller.up, value.Conveyor).x; double dt = Model.time - value.DetectTime; double dx = value.Speed * dt; double dogDistAlong = value.DistAlong + dx; return distAlong - dogDistAlong; This code assumes that the item waiting to merge is the puller. So we calculate the item's "dist along" the main conveyor. Then we estimate the location of the dog since the DogFinder item created the token. Then we can find the difference between the item's position and the dog's position. Pulling Dogs from the List Each incoming lane has a Decision Point. The main process flow creates a token when an item arrives there. At a high level, this token just needs to do something simple: pull an available downstream token. If all the items are the same size, it's that simple. But this example is more complicated! If the item is large, we also need to pull the upstream dog behind the dog we got, so that no other item can get that dog. And it gets even more complicated! It can happen that an item acquires the dog after a double dog. In that case, we need to mark the downstream dog as "not double", so that big items won't try to get it. So most of the logic in the ConveyorLogic flow is handling that case. Using the Dog Finally, the item must be assigned to that dog. The ConveyorLogic flow sets the DogNum label on the item. Then, the catch condition checks to see if the dog matches the item's DogNum. Upstream Items The final piece of this model is allowing upstream items to catch a dog on this conveyor. This model adds a special label to those items called "ForceCatch". The catch condition always returns true for those items.

En este video aprenderán a representar el uso de un montacargas con un operario. Este video está basado en esta pregunta del Foro. Para más videos tutoriales pueden suscribirse al canal de YouTube de FlexSim Andina y acceder a nuestra lista de reproducción de Retos FlexSim.

En este video aprenderán a utilizar el Dispatcher para gestionar equipos de trabajo en un modelo de simulación. Para más videos tutoriales pueden suscribirse al canal de YouTube de FlexSim Andina y acceder a nuestra lista de reproducción de FlexTips.