This example model was created to clarify pre-emption of task sequences created in process flows. Specifically it will show: 1) that pre-empting of task sequences generated in a process flow does not require the token generating the sequence to be pre-empted. 2) that you can push a partially created sequence to a tasksequence list type. 3) how to use recursive calls to a sub flow. and afterwards: 4) how the milestone task can be used in a PF generated task sequence 5) the use a task type nodefunction Each queue is a member of the object process flow shown in the picture. Each generates a box along with a job to take it to another queue and pulls an initial task executer from the list of FreeTEs. The first task to travel and collect the box is preemptable and so we push the task sequence to a Premptable Job list before we add that travel task and pull it off the list when the task has completed. The rest of the task sequence is a standard load, travel and unload set of tasks. When the job is complete we know that the TE is free and could preempt another TE - which could be desired if the newly free TE is closer to the pickup queue than the one currently assigned. The CheckPreempt subflow is called with a label referencing the TE that has become free. This TE may not be the original TE that we pulled from the list of FreeTEs when the job was started, and so we discover the current TE by looking for the task sequence's owner object - done with the function findownerobject() since it does not cache the value in the same way ownerobject() does, and we could have had more than two TEs assigned to this tasksequence. Since the task sequence gets destroy I do this in the assign labels activity before we finish the ts: The Check Preempt subtask first tries to pull a preemptable job where the invoking TE is closer than the current executer of that job, and chooses the one where it is the most pronounced difference. The taskssequence list type has the distance field prepopulated and from that the two other field expressions otherDistance and howMuchCloser are derived. If no task sequence is chosen then we push the finishing TE to the FreeTEs list. If we choose a task sequence to preempt then we first label the token with the otherTE and the preempt the task sequence with a simple zero delay task. The we reDispatch the task sequence to the te that is calling Check Preempt. Since we now know that we've freed the otherTE from the task sequence it had we can invoke the Check Preempt subflow for that task executer, knowing that it will either get put onto the FreeTE list or get another task sequence and preempt another TE. This the is a recursive subflow call with the exit condition being that no preempatable tasksequence is found. Note that no token preemption from activities takes place and this is because the tasksequence is still tied to the token and its activity, which will still receive the call back when a task is complete, regardless of which task executer actioned the task. TEpreemptIfCloser1.fsm Next: Changing colors to indicate preemptable TEs and their destination - using milestone and nodefunction tasks. To better see the allocation and preempt activities we'll now change the model such that the TE color reflects the following: White when idle Gray when busy and not preemptable Matching the pickup queue's color when preemptable. First of all I defined two user commands - one to set the color of the TE (setTEcolor) and another (commandNode) to get the executable node of a user commands. This is so that I can add the fn() SetColor activity (it's a custom task of type nodefunction) ; specify the function using: commandNode("setTEcolor") and pass in the queue color as parameter 2 (parameter1 will be the TE that is executing this task). This means the user command code is just: Object te=param(1); Color col=param(2); te.color=col; The milestone task allows us to define a set of tasks that need to be repeat if the TE gets pre-empted. It's added again using the Custom Task activity and selecting the type as Milestone and has a parameter to specify the number of subsequent tasks that should be considered within the preemption range that will trigger tasks to be repeated. Since we want the Travel preemption to retrigger the setting of the color we set the range to 2. However since the token only needs to be notified when the travel task is complete that it should go on to the next process, and until then wait in the travel task we can uncheck the "Wait Until Complete" box of the Milestone and fn() SetColor activities: If you don't clear this for those two tasks we expect some misbehavior/desynchonization with the token. Finally there needs to be a resettrigger on the TE to set the color to white and a regular Change Visual activity after the pickup point is reached to set it to gray. Note I prefer the use of commands to sending messages, which would be another option, mostly because users can tell the intent of the call without having to inspect the message code. TEpreemptifCloser2.fsm

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

Attached is a simple example of using the GIS Module. It contains a GIS Map with 8 Cities represented as points connected by driving routes. gis_example.fsm The model's Process Flow randomly generates tokens, which create items to be carried by trucks from one city to another. After a delay, the item is removed from the model. This very simple example demonstrates how to use the GIS Module to model movement of items from sources to destinations without any FixedResource objects. All the logic can be done through Process Flow to control what happens in the model. This model also demonstrates the Min Scale and Max Scale properties of a GIS Map object. By default, as you zoom the 3D view in and out, the 3D shapes on a GIS map scale so that they remain the same size on the screen, like abstract flat billboard images. When you zoom far out, because the items remain the same size, they seem really big relative to the map. Similarly, when you zoom far in, because the items remain the same size, they seem really small relative to the map. The Map object has Min Scale and Max Scale properties to cap the scaling up and down of objects as you zoom in and out, so that they will only scale up to a certain size and only scale down to a certain size. This makes it so they scale within a certain range, but don't get too big or too small. If you set both of these values to a particular number, then they will not scale at all, but rather be that particular size.

This model demonstrates a method of giving a task executor a set of tasks (or jobs) to accomplish in a specific sequence by referencing information stored in a global table. In this case, an operator needs to move boxes between queues in a very specific order. The global table defines the order of operations, with each row representing one job. The row contains necessary information about the job: the item to be moved and its destination. These jobs are to be carried out in order, row by row. First, Product1 will be moved to Queue1, then Product2 to Queue2, Product3 to Queue3, Product1 to QueueOut, and so on and so forth. Any modifications made to this table will directly modify the model’s behavior. The logic behind the process flow is relatively simple: a single token loops through a task sequence, with the operator completing a job with every loop. Assign Labels activities are used to get information about the job from the global table and attach that information to the token. The “Assign Labels: Get Table Data” activities reference the current row in the global table to access and store information about the current job (the item name and its destination). The “Assign Label: Item” activities use custom code to search through a group containing all the queues in the model until it finds the item matching the item name from the global table. The task sequence directs the operator to travel to the item’s queue, load the item, travel to the destination, and unload the item. The token’s labels contain the information that is needed for these activities. After this sequence is completed, the label “row” is incremented so that the next row in the table will be used for the following job. Although this demo model shows an operator moving boxes between queues, this method of acquiring data from global tables to define an order of operations can be used in a variety of other applications. GlobalTableDemo.fsm

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

FlexSim 2022 Update 1 Beta is now available. (Updated March 28) FlexSim 22.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. 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 dev@flexsim.com or create a new idea in the Development space.

This article demonstrates how to use the Statistics Collector and Calculated Tables to create three utilization pie charts: a state pie chart an individual utilization pie chart a group utilization pie chart Example Model You can download that model (utilizationdemo.fsm) to see the working demonstration. The model has a Source, a Processor, a Sink, a Dispatcher, and several operators. The operators carry flow items to and from the processor, as well as operate the processor. The operators are in a group called Operators. State Pie Chart First, we need to make a Statistics Collector that collects state data for the operators. The easiest way to do that is to use the pin button to pin the State statistic for any object in the model. Use the pin button to pin a pie chart to a new dashboard. The pin button creates a new Statistics Collector, as well as a new chart. Open the properties for new Statistics Collector (double click on it in the toolbox), and change its name to OperatorStatePie. On the Data Recording tab, remove the object from the Enumerated Rows table. Using the sampler, add the Operators group (you can sample it in the toolbox). Now, when you reset and run the model, the state chart should work. Utilization Pie Chart Often, users need to combine sever states into a single value that can be used to determine the utilization of an object in the model. In order to gather this data, we can use a calculated table. Make a new Calculated Table, and give it the following query: SELECT Object, (TravelEmpty + TravelLoaded + Utilize) / Model.statisticalTime AS Busy, 1 - Busy AS NotBusy FROM OperatorStatePie This query sums the time in several states into a total, and then divides by the statistical time. Be sure to set the name of the table (the part after FROM) to the name of your Statistics Collector. Run the model for a little bit of time, and then click the Update button on the properties window. You should get a table like the following: Instead of viewing the data as just numbers, change the Display Format of each column to better represent the data. On the Display Format tab, set the Object column to display Object data. Then set the other two columns to display percentages. When you switch back to the Calculations tab, the data will be formatted: Once we get the query right, set the update mode to Always. This will updated the data in the table whenever the data is needed, including every time the chart draws. If updating the table is computationally expensive, you can use the By Interval or Manual options. Generally, a small number of rows (1-100) is small enough to use the Always mode. Regardless of the update mode, we can make a chart based on this table. In the dashboard, create a new Pie Chart. For the Data Source, select the calculated table. For the Pie Title, select the Object column. For the Center Data, select the Busy column. Be sure to include the Busy and NotBusy columns. This should show you a pie chart, comparing the operator's busy and not busy time. Group Utilization To make the final utilization chart, make a second calculated table. The query for the second table should be as follows: SELECT AVG(Busy) AS AvgBusy, AVG(NotBusy) AS AvgNotBusy FROM CalculatedTable1 Again, use the Update button to be sure the query is correct. Once it is, set the update mode to Always. Finally, you can make the pie chart for this data: Things to Try If you feel comfortable with this model, you can try a couple extra tasks, such as: Remove one of the operators from the group, reset, and run. The charts will update accordingly. Add the Processor to the group, reset, and run. The state chart should work automatically.

In version 2018 and on, you can make this chart by dragging the Throughput Per Hour by Type template from the dashboard library. If you install the template (available on the Advanced tab), you will see a Process Flow and a Statistics Collector appear in your toolbox. One of the most common questions from FlexSim users is as follows: How do I make a chart that shows the output every hour? You can make this chart in three steps. Configure the Statistics Collector First, you need a Statistics Collector. Make a new one in the toolbox (click the green plus button, select Statistics, and then select Statistics Collector). On the event listening tab, use the green plus button to add a timer event, and configure as shown here: This timer event will fire every hour (every 3600 seconds) in the model. Notice the shared label, that is storing all members of the Processors group as an array. We will use this label in the next step. Once you have configured the timer, then you need to set up the row mode for this collector. We want one row per processor, and we need to use the Processors label as the row value. Since the Processors label is an array, we will get three rows per timer event, each row corresponding to a processor. Finally, we can add the columns. The three columns are as follows: Time - use the pick list to select Model Date/Time from the Time menu Object - use the pick list to select ID of row value from the IDs menu Output - use the pick list to select Statistic by Object from the Object Statistics menu Use data.rowValue as the object value in the popup If you use the pick options to choose these options, then the storage type and display format options should be set automatically. With these three columns in place, we can watch the table populate. Reset and run the model at high speed. Every model hour, you should see a new set of rows appear, one for each processor in the group. The table will look something like this: Configure the Calculated Table The Statistics Collector table from the previous steps is close to what we want, except that the output value always increases as the model runs. But what about the output for just a single hour? To get that value, we can use a Calculated Table. Make a new calculated table, and give it the following query (in the Query field): SELECT Time, Object, ISNULL(Output - LAG(Output) OVER (PARTITION BY Object), 0) AS OutputPerHour FROM StatisticsCollector1 This query uses SQL window functions. Basically, it says that each row's value should subtract the previous row's value for the object. In addition, if that value is NULL (because it's the first row), then just use a value. If you reset and run the model, so that the collector table has at least a few rows in it, click the Update button to run the query. Notice that the Time and Object columns show numbers. This is because the Calculated Table can't infer the formatting of the column. To set the formatting, use the Display Format Tab. You may also wish the table to update every hour, with the Statistics Collector. Make the Chart Now that our data is correct, we can make a chart. Make a new dashboard, and create a Time Plot chart. Point the chart to the calculated table. Let's use the Time column for the X values, and let's use the OutputPerHour column for the Y values. In addition, make sure to split by the Object column. If the calculated table updates every hour, then running the model should create the chart shown at the beginning of the model. Here is the model used to create this chart (should work in 2017 Update 2 Beta or later; beta must be built on or after August 21, 2017). outputperhourdemo.fsm

Sometimes things don't work out the way you thought they would. Usually, at least with license servers, it just means that you missed a step, or there is some issue that wasn't considered. Below we'll outline some things you should check:   Server configuration   - Check the service   Is the FlexSim_License service you created using LMTOOLS up and running? When you created and configured your licensing service, did you check the log file? Look for any errors or issues in the log. Troubleshoot the service if necessary.   - Local test   You can rule out configuration issues by installing FlexSim locally on your license server. Configure the local FlexSim installation using the port you specified (default is 26914) and the local IP address 127.0.0.1, to point your local FlexSim installation to the local license server to see if your license server can license itself.   - Connectivity problems   If your local test works, then your client PC licensing issues may actually stem from connectivity problems. In that case, check out our article Client/Server connectivity.   - Check, check again   Double check that your server is configured properly. When viewing your license service’s log file, you should see indications of ports in use, features being served, etc. (lmtools, lmadmin). If no features are listed, or port numbers are different than what was expected, please revisit the configuration guide (lmtools, lmadmin). Carefully read and execute each step of the instructions to make sure that you have properly configured your license server.   Overzealous anti-virus   Some anti-virus solutions prevent unrecognized services from running or accessing necessary functionality. If a local test (above) works, you may only need to test disabling anti-virus solutions on the client PC. Or if you're trying to get the license service to run on the server, you may need to test there also. Remember to reactivate your anti-virus software after this experiment.   Version or product mismatch   Your actual license, activated to your server using flexsimserveractutil.exe (online, manual), must be for a FlexSim version the same or greater than the software’s version number.   Your license is also for a specific product (FlexSim vs FlexSim Healthcare vs FlexTerm, etc.).   See the article FlexSim Version Numbering, for more information regarding FlexSim versioning and how it relates to licensing.   Seats all in use   If your FlexSim client software is not obtaining a license from the server, it’s possible that all seats are already in use on other client PCs. Check the log files (lmtools, lmadmin) to determine where your seats are currently in use.

First things first Sometimes the easiest method for fixing a standalone license is to simply activate the same license again. No need to return first. Just get the full activation ID for any broken licenses and activate them again. Look for the broken licenses within FlexSim by going to Help > License Activation > View Licenses tab and pressing the View Licenses button. Scan the license information for licenses that indicate they are **BROKEN**. For licenses that are broken, look up the full activation IDs in your online FlexSim Account. Using the full activation IDs for each broken license, activate the licenses normally within FlexSim by going to the Activate tab and pasting and activating each activation ID in turn. No need to return the licenses first. In case you need more detailed activation instructions, see: Standalone - Activation - Online Standalone - Activation - XML / Offline If you completed the 3 steps above but encountered error messages, it is time to manually repair your licenses. Okay, time to repair Standalone licensing does not have a method for repairing online. Here are the steps to manually repair your license. These instructions apply to FlexSim 2016 and later. If you are using an older version of FlexSim, please download FlexSim's latest version and follow these instructions. You can manage your older FlexSim licenses from the latest software - the License Activation window will still show your older licenses and you'll be able to complete all these steps for your broken pre-version-16.0 licenses. Open FlexSim as an administrator by right clicking the program icon and selecting Run as Administrator. From the main menu, go to Help > License Activation. Go to the Advanced tab, then the Repair tab. For each broken license listed in the License selector box, click the Generate XML Request button. Save each XML file to a convenient location on your computer. Log in to your FlexSim Account. From the top navigation header click the Licenses link, then choose Manual XML in the Licenses submenu. Upload your XML files by dragging them onto the drop zone. Your uploaded XML requests will be processed. Upon completion, you will be prompted to download each XML response. In FlexSim (your instance opened above in step 1 using Run as administrator), you should still be on the same License Activation > Advanced > Repair tab. Process each response by pressing the Process Response button and browsing to an XML response. FlexSim should successfully repair the license. After repair it should be usable and returnable. If you have any questions or problems, please search our Answers Community for possible solutions. There is a good chance someone else has already asked your question. Still not finding what you're looking for? Submit a new question and we'll check it out. If you're including any confidential information, such as license codes, be sure to mark your question as private! You can also contact your local FlexSim distributor for live phone, web, or email help.

Assumed configurations   All steps below assume that you followed the installation instructions as described in our license server installation instructions, and that all FlexSim's license server files were extracted to the location C:\FlexSim_LMTOOLS. Throughout these instructions we will reference files inside that folder.   Reread the license   Within your FlexSim_LMTOOLS folder, right-click lmtools.exe and choose Run as administrator. You may need to accept a permissions prompt. Go to the Start/Stop/Reread tab. Choose the FlexNet License service for your FlexSim licenses. The name of the service could be FlexSim_License, but the service could have been given a different name. Press the ReRead License File button. Close lmtools.

FlexSim 2025 Update 2 Beta is now available.   FlexSim 25.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 FlexSim Forums.

Every now and then, there are technical support questions that are asked more than once by different users. This article seeks to address a couple of “how to” questions that have come up over time. As such, this isn’t a massively technical paper just a quick look at a few things that might make your modeling experience more fun and your models a little more interesting. Background: This is a physical screening clinic similar in nature to those you might encounter either in the military or in a hospital that supports a large industrial area where employee physicals are required either by insurance companies or an employer. That said, it could even be a part of a much larger function like an ER. In a nutshell, patients that represent a mixed population of both men and women, are sent to the clinic without an appointment and arrive according to an exponential distribution. In the model, the mix of men and women is 50-50 although it can be altered to accommodate any distribution of patients. Once a patient registers, he/she is either directed to a gender-specific changing room where they change into a white surgical gown, or take a seat in the waiting room until a changing room is available. Once changed, each patient is escorted to an exam room by one of two nurse practitioners, is examined for a time period that is also gender-specific (men – normal(20,5,1), women – normal(17,3,1)), and is eventually released to return to a changing room and finally to leave the clinic. Any time there is no changing room available, patients take a seat in the waiting room. The clinic opens at 0800 hrs and closes at either 1600 hrs or after 1600 hrs when the last patient departs. Open and run the model, “changing-rooms-model-11-16-2016.fsm” to see the model in operation. Modeling challenges: The challenges are straight-forward and not at all complex. Specifically, they address the following questions: How do you stop patient arrivals (e.g. in-flow) at a certain time of day and then close the clinic when the last patient departs? How do you make sure that patients go to their own gender-specific changing rooms? How do you change a patient’s shirt color to white representing a patient gown and then back to their original color when they change back into their street clothes? How do you use a patient label to determine treatment time if a distribution is contained in the label? Flow Chart: Before we dissect the model, it’s probably not a bad idea to take a close look at the flowchart if only because, despite the model’s size, it can seem a little complex. Notice that the changing rooms really are the central point in the model. As such, connecting lines have to be constructed that link the Registration Area (0ne way), the waiting room (two way), the exam area (two way) and the Patient exit (one way) with each of the Changing rooms. Setting the Stage: Because the purpose of this model is to make provisions for and track both male and female activities, it uses two different PCIs (Patient classification Index numbers) to represent Men (PCI1) and Women (PCI2). Those PCIs and any related labels that may generally carry information about patients that might be used for decision making later, are initially entered in the Track Manager, under the tab labeled, "Patient Classification” as shown to the right. Note that, in this case, there are fields for identifying which Track a specific PCI will follow, what each PCI’s Acuity will be, which Gender different PCI’s will represent, which distributions represent each PCI’s Exam Time in the model, and a direct reference to which changing room a patient should use. Needless to say, each of the three types of fields – text, number and code – are accessible from various elements of the model and may be used to determine and isolate almost any patient characteristic a modeler might use to define patient Activities. One other “setting the stage” aspect of the model that deserves mention is the positioning of the nurses. Note that the two nurses aren’t arrayed in a single line, the default positioning of resources in a model, but rather are positioned as if they're having a conversation. Although somewhat inconsequential when a resource staff is small, large collections of staff members cry out for better, more life-like poses. To change a resource’s initial location in a model relative to its home base - in other words, it’s “Offset” – first make sure the model is in “3D View” by clicking on View>Model View (3D) in the main menu. Then, simply click on the individual resource and drag it to the place you’d like it to stand as its initial position. Note that the X Offset, Y Offset and Rot Offset values that are unique to each member of a resource group, will automatically be changed to the new coordinates. Finally, note that by clicking and holding down your left mouse button over any of the Offset positioning arrows (circled in red above), and then moving your mouse forward and back, you can also manually reposition any specific resource. Arrival Pattern : Open the Properties window for the Patient Arrivals Object to follow this discussion . The Patient Arrival pattern is simple to construct, involving nothing more than identifying the correct exponential distribution (i.e. exponential(0,20,1)) in the Patient Arrivals Properties’ Interarrival Time field as shown at the left. Notice also that the Patient Classification Index (PCI) field contains an expression to calculate and therefore generate two different PCIs. As mentioned previously, PCI 1’s are classified as men and PCI 2’s as women. In this case P(50.00, 1, 50.00, 2) insures that a mix of 50% men and 50% women will be generated by the Patient Arrivals Object during the model run. Setting Certain Patient and Model Characteristics : The purpose of the Patient Arrivals object isn’t only to create a unique pattern of patient arrivals but also to serve as the source of every patient’s initial characteristics as well as set certain actions that affect the performance of the model as a whole. In this case, changes to the patient’s appearance and the stopping time for patient arrivals are both determined in two different Patient Arrivals’ Property Triggers as shown at the right. Note that the “On Creation” Trigger is used to identify any actions the modeler might want to activate that occur when a patient is created for entry into the model. As shown, picklist option can be used in the On Creation Trigger to change any number of model parameters In this model, only that referring to the patient’s shirt color is changed. In this case, there are three entries to select from … (1) the fact that the patient’s shirt color should be changed, (2) which color palette should be used to obtain the desired color (Palette2), and (3) which color (by index number) should be used. Note that the color index number is determined by the patient’s PCI of either 1 or 2. Different palettes unique to the software can be viewed by selecting, “Edit > Color Palettes,” from the software’s main menu. Note that new palettes and/or colors may be added to the color palette editor by selecting the appropriate functional options (ie. Add/Delete Palette, More/Less colors). In this case, Male patients will wear green shirts and female patients will wear yellow. Note that the “OnExit” Trigger is used to identify any actions the modeler might want to occur when a patient exits the Patient Arrival object. In this case, the picklist option, “Stop or Resume Flow” is selected to act as a brake for patient arrivals after a specified elapsed time. Although there are seven different drop down options to select from regarding the condition desired to stop patients from entering the model, the option “time()>960” is selected to stop arrivals at 1600 hrs (4 p.m.). Note that “960” represents the elapsed time in minutes since midnight (time 00:00) of the first day of the model run. Many first time modelers make the mistake of assuming that the time value represents the elapsed time since the model’s beginning time, in this case 8 a.m., which isn’t the case. In any event, this picklist option examines the time of every patient’s departure from the Patient Arrivals object and the first patient created at or after 1600 hrs, automatically stops any additional patients from being created. Closing the Clinic’s Doors and stopping the model . Open the Properties window for the Patient Exit object to follow this discussion. Clearly there are two actions that are required to close the clinic at or after 4 p.m. when the last patient departs. The first is to close the front door which is accomplished by the “OnExit” Trigger found in the Patient Arrivals object as discussed in paragraph 5B above. The second is accomplished in the Patient Exit object’s “OnEntry” Trigger as shown at the right. In this case, the drop down picklist option, “Stop Model Based on Condition,” is selected and used to establish two criteria for the model’s end. The first criteria is that the elapsed time be later than 4 p.m. and the second is that there be no patients in the clinic when 4 p.m. arrives. The correct entry for the picklist option then, is shown at the left and takes both circumstances into account. What it determines every time a patient leaves the clinic is, what time it is and if anyone remains to complete treatment at that time. If the time is even a second past 4 p.m. and the clinic census is zero, the expression stops the model. So far, we’ve accomplished several tasks that include, (1) setting the patient’s shirt color, (2) establishing a criterion for closing the clinic door at 4 p.m. and stopping clinic operations at or after 4 p.m. when the last patient leaves, and (3) positioning resources at various places in the model rather than in a single straight line. Now, we need to change the patient’s shirt color to white – symbolizing changing into an examination gown – and back to its original color when the exam is over, and determine the patient’s Exam Time. It’s a simple process that we’ll cover in Activities 40, 60 and 80. Activity 10_Arrival: This activity causes the patient to walk unescorted from the Patient Arrival Object to the Registration Area. Although there’s nothing complex or unfamiliar about the activity, it’s important to note that even though this activity has no predecessors, a check mark is still required in the Predecessors box to cause the model to begin this activity without a command from some other activity. Activity 20_Registration : This activity causes the patient to use someone from the ClerkGroup at the Registration desk for normal(2,1,1) minutes to log in. Activity 30_TravelToChange1:This activity causes the patient to walk unescorted to one of the two changing rooms based on the patient’s sex. As such, which of the changing rooms is determined by the entry in the Patient Destination field, in this case, from the drop down picklist option, “Based on a Condition,” and by the edited drop down option, “getlabelnum(patient, "Gender") == 1 as shown to the right. Note that there are actually 12 different, “Choose a Condition” options the modeler can employ to set the patient’s destination. Activity 40_Change1 : This activity causes the patient to take normal(3,1,1) minutes to change into an examination gown and changes the patient’s shirt color from either green or yellow to white representing that change. The expression that causes the color change is contained in the Advanced Function, “Activity Finished Trigger.” In this case, the drop down picklist option, “Set Color” is selected to change a patient’s shirt to white as shown to the right. White is the color whose index number is 15 in the color palette 3. Activity 50_TvlToExam: This activity causes the patient to be escorted by a member of the NurseGroup from the changing room to the first available Exam room. Activity 60_Exam : This activity causes the patient to spend a period of time specified in the Processing Time field being examined by the same nurse that escorted them to the Exam room. Note that the exam time is entered by selecting the drop down picklist option, “Based on Patient’s Label,” and then by selecting the Patient Label, “ExamTime,“ that was previously set in the Patient Classification Index (PCI) Table. See Paragraph 3 above. Activity 70_TvlToChange2 : This activity causes the patient to walk unescorted to one of the two specifically named changing rooms. As such, which of the changing rooms is determined by the entry in the Patient Destination field, in this case, from the drop down picklist option, “Based on a Condition,” and by the edited drop down option, “getlabelnum(patient, "Gender") == 1 as shown to the right. See paragraph 7C for the same logic initially entering a changing room. Activity 80_Change2 : This activity causes the patient to take normal(3,1,1) minutes to change out of their examination gown and back into their street clothes by changing the patient’s shirt color from white back to their original color. The expression that causes the color change is contained in the Advanced Function, “Activity Finished Trigger.” In this case, the drop down picklist option, “Set Color” is again selected to change a patient’s shirt to its original color using the patient’s PCI number. Note that this is the same way the shirt color was assigned initially. See paragraph 5A Activity 90_Departure: This activity causes the patient to walk unescorted to the clinic exit and leave the model. Special Notes regarding the Changing Room model . As simple as the model may seem, it serves to reinforce several modeling techniques that we sometimes overlook. For example, … All activities are assigned unique Milestone names. In this case, TvlToChange1 and TvlToChange2 are identical in every respect. However, Change1 and Change 2 aren’t. To combine the four different activities into two identical activities would change the Patient Timeline widget in the Dashboard so that a patient’s time spent waiting for a nurse following the first Change would be combined as a single display element. This might make it difficult to glean specific information from the Timeline regarding total time changing and waiting for resources. The use of floor displays and walls to enhance a model’s appearance is highly encouraged. To design effective and realistic models, practice using the Infrastructure tools to create underlying floors and the Library tool, “Visual Objects,” to create enclosures.

We have released a beta version of our bottling module. The module adds two new objects to the FlexSim 3D Library. The Mass Flow Conveyor (MFC) and the MFC Motor. The Mass Flow Conveyor allows you to define multiple lanes for flow items to move along. It is often used in bottling lines. Help files are included in the FlexSim User Manual to assist you. This beta version must be installed with FlexSim 2017 Update 2. 32-bit and 64-bit installers can be downloaded through the downloads section in the Modules tab of the FlexSim website: FlexSim Downloads The following are known issues: Acceleration implementation is not complete. Crossline Multiplier implementation is not complete. MFC.Motor property 'sections' is not working. Please post any feedback or bug reports either as a comment to this article or you can email them to dev@flexsim.com

FlexSim 2023 Update 1 is now available for download. You can view the Release Notes in the online user manual. FlexSim 23.1.0 Release Notes For more in-depth discussion of the new features, check out the official software release page: FlexSim 2023 Update 1: Mass Flow Conveyor Improvements, Table Validation, and more 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.

One of the most powerful uses of a Fixed Resource Process Flow is to unify a set of machines and operators as a reusable entity. For example, many factories have several production lines. Simulation modelers often wonder what would happen if they could either open or close more production lines. If you were to open a new line, would the increased output be worth the cost? Or if you were to close a line, would the factory still be able to meet demand? These are the kinds of questions modelers often ask, and by using a Fixed Resource Process Flow, you can answer this question. This article demonstrates how to use a Fixed Resource Process Flow (or FR Flow) to coordinate several machines and operators as a single entity. The example model represents a staging area, where product is staged before being loaded on to a truck. However, most of the concepts that are discussed could be used in any Fixed Resource Process Flow. Creating a Collection of Objects When you set out to build a reusable FR Flow, it is usually best to start by making a single instance of the entity you want to replicate. Often, it is convenient to build that entity on a Plane. When you drag an object in to a Plane, it is owned by the Plane, which makes the Plane a natural collection. If you copy and then paste the Plane, the copy will have all the same objects as the original Plane. This makes it very easy to make another instance of your entity: just copy and paste the first. If the Plane is attached to an FR Flow, then the copy will also be attached to the same Flow, and will then behave the exact same way. In the example model, you will find a Plane with a processor, five queues, and two operators. This makes up a single staging area. The Plane itself is attached to the FR Flow, meaning an instance of the FR Flow will run for the Plane. It also means the Plane can be referenced by the value current . (You may find it helpful to set the reset position of any operators, especially if they wander off the plane at any point during the model run.) Using Process Flow Variables In order to drive the logic in your entity using an FR Flow, you will need to be able to reference the objects in each entity, so that they will be easily accessible by tokens. For example, if items are processed on Machine A, Machine B, and Machine C, in a production line, then you would want an easy way to reference those machines in each line. This is where Process Flow Variables come in. In the example model, you will find the following Process Flow Variables: Every staging area has a Packer, a Shipper, and a Palletizer, each referenced using the node command. Remember that current is the instance object, which is the Plane. Once these variables are in place, you could create an FR Flow like the following: If you ran this model with the Plane shown previously (complete with correctly named objects) and this flow with the shown variables, then the Packer operator would travel to the Palletizer. If you then copied the Plane, you would see that all Packers go to their respective Palletizers, as shown below: Using Variables and Resources Together Sometimes, you may want to adjust the number of operators per line, or even the number of operators in a specific role. To do this, you can again you Process Flow Variables. The sample model includes these variables: The sample model also includes these resources; the properties for the Shipper Resource are shown: Because this resource is Local, it is as if each attached object has its own version of this resource. Because it references a 3D operator, it will make copies of that operator when the model resets. The number of copies it creates will depend on the local value of the ShipperCount variable. To edit the value for a particular instance object, click on that object in the 3D view, and edit the value in the quick properties window. Disabling Entities Often, modelers simply want to "turn off" parts of their model. If that part of the model is controlled by a fixed resource flow, then you can easily accomplish this task. In the example model, you will find the following set of activities: The Areas resource is numeric, and it is global. The Limit Areas activity is configured so that any token that can't acquire the resource immediately goes to the Area Disabled sink. If the token that controls the process dies, then the area for that token is effectively disabled. The example model uses a Process Flow Variable to control how many areas can be active at a time: The Areas resource uses this value to control how many shipping areas are actually active. If this number is smaller than the number of attached objects, then some of the areas won't run. Note that the order the objects are attached in matters. The first attached area will be the first to generate a token in the Init Area source, and so will be the first one to acquire the area. Using Process Flow Variables in the Experimenter/Optimizer Currently, only Global and User Accessible variables can be accessed in the Experimenter. In the sample model, the only variable that can readily be used in an experiment is the TotalAreas variable, which dictates how many areas can be active. This allows the Experimenter or Optimizer to disable lines. To make it possible for the Experimenter or Optimizer to vary the number of Shippers or Packers per Area, the ShipperCount and PackerCount could be changed to Global Variables. You could put labels on the instance object (the Plane) that are read by the variable, like so: Then the experimenter could set the label value on the Plane object that is attached to the FR Flow. The Experimenter would set the label, which would affect the value of the Variable, which would affect how many copies of the Packer were created by the Packer resource. You could do the same for the ShipperCount variable. Sample Model The attached model (usingfixedresources-6.fsm) provides a working model that can demonstrate the principles in this article. It comes with only one Plane object attached to the FR Flow. Here are some things to try with the model: Reset and run the model to see how it behaves with a single area, where that single area has only one Packer and one Shipper. Create a copy (use copy/paste) of the Plane. Reset and run the model again to see how a second area is automatically driven by the same flow. You may need to adjust the TotalAreas variable if the second doesn't run. Adjust the number of Packers and Shippers (using the Process Flow Variables) on each Plane. Reset and run the model to see how adding more packers and shippers affects it. Create many copies of the first Plane (it is best to set the PackerCount and ShipperCount to 1 before copying). Reset and run the model, to observe the effect. Add or remove some staging areas (queues) to an Area. This model handles those changes as well (in the Put Stations On List part of the flow). Try to set up an experiment or optimization, that varies how many lines are active, and how many Packers and Shippers are in each. In general, play around with the sample model, or try this technique on your own. Other Applications This technique can be used to create production/packaging lines, complex machines, or any conglomerate of Fixed Resources and Task Executers. If you follow the methods outlined in this article, you will be able to create additional instances of complicated custom objects with ease. You will also be able to configure your model for use with the experimenter or optimizer.

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.

If you have a contiguous conveyor network you can just route items using Conveyor.sendItem() and FlexSim will guide the item to the destination, passing through inline and side transfers as required for the shortest path. If between some conveyors you use exit and entry transfers, perhaps to easily add elevators and shuttles as transports between them - then you'll normally be faced with adding logic to figure out which exit transfer to go to and which port to take from that transfer - and in a large model that logic can be extensive and hard to maintain. The attached model and library provides commands for automated routing through multiple conveyor sub-sections connected through exit/entry transfers, to conveyor points and to connected fixed resources. This means that you may no longer have to write sendTo code with case statements on each exitTransfer to determine which port an item should exit through – nor possibly need to have decision points with case logic to decide the destination for Conveyor.sendItem(). In the example model three sources create items with random destinations which are routed through the conveyor system, transfers and port automatically to arrive at the correct destinations – some of the ports having transport to perform the move. To make this work in any model you should load the user library which will auto-install a set of user commands and a General Process Flow. The first step is to run the user command ‘createAllTravelMaps()’ which will calculate all the reachable destinations (decision points, stations, pes, attached fixed resources and transfers) from all the conveyor points and entry/exit transfers) along with estimates of the conveytime (from the conveyor class). This information consolidated to create the shortest routes and is stored in a label ‘travelMap’ on each decision point, station, pe and transfer. To make use of the travelMap data there are three additional user commands supplied that are intended to be used directly by the modeller: getNextConveyPoint(thispoint, destination) – returns the next point to send an item to from this point in order to ultimately reach the destination. getConveyExitPort(exitTransfer, destination) – returns the port through which an item should exit the exitTransfer in order to reach the destination. getConveyItemsNextConveyPoint(item, destination) – returns the next point to which an item should travel to reach the destination from its current position on a conveyor. The simple process flow in the example and library is set to listen to the Group members of EntryTransfers and ExitTransfers in order to lookup the ‘destination’ label and either sends the item to the next point or in the case of the exit transfers, overrides the sendTo port with the value from the map. I’ve added some documentation to the user commands which you can access easily via the command helper: ConveyorTravelMaps_0.3.fsl ConveyorTravelMapExample.fsm You may find createTravelMaps() takes a while which is why a progress bar has been added. You may not need all points to be evaluated exhaustively so the option to pass in a flag indicating to only start evaluation from Entry Transfers is given, which will create somewhat incomplete maps for intermediate points. A future refinement would be to account for transport time from exit transfers either by recording the times or providing port list with the expected times. Clearly if you make changes to your transfer positions or conveyor layout you should rerun createAllTravelMaps.

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.

En este video aprenderán a crear diferentes layouts en un modelo de simulación de FlexSim usando la herramienta Model Layout. Para más videos tutoriales pueden suscribirse al canal de YouTube de FlexSim Andina y acceder a nuestra lista de reproducción de FlexTips.