FlexSim 2019 Beta is available. (Updated 21 December 2018) To get the beta, log in to your account at www.flexsim.com, then go to the Downloads section, and click on More Versions. It will be at the top of the list. 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 Added support for importing JT files. Added a way to directly animate 3D shapes with bones. Added a way to parent subcomponents to a bone on a 3D shape. Updated calculated tables and chart templates to be able to save their data during an experiment. Added support for SQL keywords UNION, UNION ALL, INTERSECT, and EXCEPT. Updated the time table's weekly and daily modes to use a graphical display. Improved the time table's user interface. Added options for stacking bars on a histogram and added more bar modes. Added a Column Sets feature to statistics collectors. Added more options for event listening in statistics collectors. Added an option to statistics collectors and calculated tables for object path display depth. Added an option to statistics collectors to stop tracking row values after specified events. Added an option to milestone collectors to start new entries on the next milestone. Added options to record more data in additional columns on a milestone collector. Added enable/disable right-click menu options to statistics collectors in the toolbox. Improved the performance of calculated tables in certain configurations. Fixed a bug with Always Leave Entries on List when reevaluating multiple back orders. Fixed a bug with color spilling from one mesh to another when using shape data overrides. Fixed scaling issues and a crashing bug when loading certain STEP and IGES files. Process Flow Improved the Token.create() method to be able to create child tokens. Added a new Person Flow type of Process Flow. Fixed a bug with a resource connected to a global list deleting the list when the resource was in an instanced flow. People Added a Process activity. Added a Remove Person activity. Added various activity sets to quickly create common groups of activities. Added a priority value to resource objects that is used for acquiring and preempting resources. Added advanced options to the Process activity for handling preemption. Added functionality for simulating shift schedules with time tables and down behaviors. Improved the UI for how people objects are added to groups. AGV Improved control point selection on paths in the 3D view. A* Added a way to draw a heat map based on a node's percentage of total traversals. Added a Two Way option to preferred paths and dividers. Added a Condition option to A* objects to optionally disable them under certain circumstances. Added a Mandatory Path object used for defining sets of paths where certain connected objects can travel. Updated the Barrier object to be able to specify patterns to determine how it affects the grid. Added a FlexScript API for A* objects and data. Backwards Compatibility Note: the following changes may slightly change the way updated models behave. Fixed a bug with A* barriers blocking space larger than their actual size.

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.

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 [email protected] or create a new idea in the Development space.

Here on Answers it's often helpful to post code in a question or an answer. When you do so, there are certain steps that should be taken to avoid being blocked by Answers' internal security mechanisms. This article describes the proper way to submit code without arousing suspicion from our threat detection software. Some of our customers are all too familiar with the screen below after asking a question or adding a comment that includes code. What is Cloudflare? Cloudflare is a 3rd party threat detection software specifically designed to detect malicious code/software that may threaten a website. Once you've seen this screen above, there is no way for us to un-block you, as it is an automated 3rd party software. Unfortunately, at this point you have to wait a variable amount of time until Cloudflare decides your IP address is no longer a threat and you will again be allowed access to answers.flexsim.com. What am I doing wrong? This warning usually presents itself when code has been typed or pasted directly into the body of your post, like this: How do I properly format my code? First paste or type your code into the body of your post. Then, highlight your code and click the Code button in the toolbar. It looks like this: < > How can I tell if my code is properly formatted? After highlighting your code and clicking the code < > button, you will see that your code now has a border and light background: Remember, if you have multiple blocks of code, you can select just the code you want to be grouped together in the first block, hit the code button in the toolbar, and then select the second group of code and again hit the code button to make the second code block, etc. After you submit your post, you will see your code formatted with syntax highlighting, a mono-spaced font, and the lines numbered, like this: Conclusion Adding code to your post is an essential task for many of our customers. If you follow these guidelines, you should be able to avoid being blocked and ensure you have uninterrupted service on our answers site. If you feel you have properly entered code and are still being blocked, please inform us and include the code and method of formatting you were using when you were blocked. We'll gladly look into it. As a fallback, you can take a screenshot of your code and add it to your post as an image, but still let us know there was an issue, and we'll look into it. Finally, if you're in a hurry and Answers troubles are keeping you from getting the help you need, remember to contact your local FlexSim representative directly by phone or email.

These instructions are to be performed on a license server hosting FlexSim licenses. You will need the license server files. If you do not already have a copy of those linked files on your license server, download them to your license server then extract the entire archive to a convenient location. Run flexsimserveractutil.exe as an adminstrator by right-clicking the .exe and selecting Run as Administrator. Go to the main menu, Tools > View License Rights. Scroll through the displayed license information. Find any activated licenses that indicate they are broken. Find each broken license's Fulfillment ID (starts with FID_). Copy the Fulfillment ID to the clipboard (highlight including the FID_ prefix, through to the end of the line. Ctrl-C to copy). Go to the main menu. Select Tools > Manual Activation > Generate Request. Select the Repair option. Paste the Fulfillment ID into the field (Ctrl-V). Delete any spaces that may have been included before or after the pasted Fulfillment ID. Browse to a location where you will save the XML repair request. Choose a file name for the saved file. Press the Generate button. Repeat steps 4-10 for any broken licenses. Transfer the XML repair request files to an Internet connected computer. The files are plain text XML and can be manually examined in any text editor if necessary for security purposes. Be sure not to modify the files, including line endings. If the file is modified in any way, the various hashes in the file will register the change and the request will fail. Log in to your FlexSim Account. Click the Licenses link in the top navigation menu, 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. Transfer the XML response files back to your license server. In flexsimserveractutil.exe (your instance opened above in step 1 using Run as administrator), from the main menu, choose Tools > Manual Activation > Process Response. Process each response by browsing to an XML response, then pressing the Process button. The license should be successfully repaired. 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.

FlexSim 2022 introduced a Reinforcement Learning tool that enables you to configure your model to be used as an environment for reinforcement learning algorithms. That tool makes connecting to FlexSim from a reinforcement learning algorithm easier, but that tool is not absolutely necessary for this type of connectivity. The same socket communication protocols that are used by that tool are available generally in FlexScript. Attached (ChangeoverTimesRL_V22.0.fsm) is the FlexSim 2022 model that you build as part of the Using Reinforcement Learning documentation that walks you through the process of building and preparing a FlexSim model for reinforcement learning, training an agent within that model environment, evaluating the performance of the trained reinforcement learning model, and using that trained model in a real production environment. Also attached (ChangeoverTimesRL_V6.0.fsm) is a model built with FlexSim 6.0.2 from 2012 that does the exact same thing, but with custom FlexScript user commands instead of the Reinforcement Learning tool. You can use this model with the example python scripts and FlexSim 6.0.2 in the same way that you can use the other model with those same scripts in FlexSim 2022. I'm providing this FlexSim 6 model as an example that demonstrates how you can communicate between FlexSim and other programs. The Reinforcement Learning tool certainly makes this type of communication easier and simpler, with a nice UI for specifying RL-specific parameters, but the fundamental principles of how this works have been available in FlexSim for many years using FlexScript. Hopefully this example can help teach and inspire those who wish to control or communicate with FlexSim from external sources for purposes other than just reinforcement learning. FlexSim is flexible, and the possibilities are endless.

FlexSim 2022 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 [email protected] or create a new idea in the Development space.

A.Hello everyone, Some people we very impressed by FlexSim in a logistics fair and they asked me why are we using Plant Simulation in stead of FlexSim ? I've never heard about this software before, so I had a look on youtube. And to be honest I was impressed by the 3D view and how easy was constructing an automated storage in few seconds without code. I'd like to ask if anybody have used this software ? And what do you think about it ? Thank you very much.

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.

Neste Tutorial iremos demonstrar como funciona a ferramenta Model Layouts no FlexSim. Esta ferramenta permite que você crie e edite diferentes Layouts para um mesmo modelo. Você pode modificar a posição dos objetos e criar uma nova opção de Layout. Por exemplo você pode salvar um Layout inicial de seu processo e após montar propostas a serem estudadas, como um Layout com diferentes posições, redução de transporte, etc... O Model Layouts permite que você possa fazer isso. modellayouts-example-model.fsm Ferramenta útil para estudar comparativamente os resultados gráficos dos Layouts criados apenas rodando o modelo para cada um dos Layouts, e ou para criar a variável Layout para inclusão das opções de Layouts em um experimento. As informações de Layout são armazenadas em cada um dos objetos individuais. Um nó é adicionado aos atributos de objeto chamados Layouts. Para cada Layout criado, uma cópia das informações espaciais atuais do objeto (posição, tamanho, rotação) é armazenada. Janela Model Layout Esta janela pode ser acessada em: View Menu / Model Layouts Layout List - Exibe a lista de Layouts atuais. Selecione um layout para atualizar imediatamente o modelo desse Layout. Você pode renomear um Layout digitando um novo nome neste campo. Add Layout - Adiciona um novo Layout. Quando você adiciona um Layout, ele salva o Layout atual do modelo. Delete Layout - Remove o Layout selecionado. Set - Opção para atualizar o Layout do modelo selecionado para corresponder ao Layout atual do modelo indicado na lista (Layout List).

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.

FlexSim 2022 Update 2 is now available for download. For more in-depth discussion of the new features, check out the official software release page: Official Software Release Page - FlexSim 2022 Update 2: AMR Modeling, AI with Bonsai, and more You can view the Release Notes in the online user manual. FlexSim 22.2.0 Release Notes If you have bug reports or other feedback on the software, please email [email protected] or create a new idea in the Development space.

Neste Tutorial iremos demonstrar em um exemplo como funciona a biblioteca AStar Navigator no FlexSim. O AStar Navigator, também conhecido como A*, é um algoritmo de busca usado para encontrar um caminho entre pontos, e serve para determinarmos o trajeto pelo qual os executores de tarefas podem se movimentar pelo modelo. Esta biblioteca permite que você crie e defina barreiras físicas para a correta movimentação dos executores de tarefas em seu modelo. Nós iremos usar o seguinte modelo para mostrar como o A* Navigator pode ser usado em um modelo simples. astar-example-model.fsm Crie o A* Navigator Primeiro, um objeto AStarNavigator deve ser adicionado ao modelo. Somente um objeto AStarNavigator faz-se necessário e permitido por modelo. Crie um objeto AStarNavigator ao clicar e arrastar da biblioteca para qualquer posição na superfície de simulação em 3D. Conectando os Membros Neste modelo, existe apenas um objeto executador de tarefa (TaskExecuter), no entanto, nós também queremos incluir o Rack como uma barreira. Faça um conexão com o 'A' entre o AStarNavigator e o operador. Isto pode ser feito mantendo a tecla A pressionada e clicando/arrastando do AStarNavigator para o operador, ou do operador para o AStarNavigator (não importando a ordem ou sequência de onde tem que partir a conexão). Um círculo em azul irá aparecer abaixo do operador. Faça uma conexão com o 'A' entre o AStarNavigator e o Rack. Um retângulo em azul irá aparecer abaixo do Rack. Adicione um Source e um Queue próximo ao operador conforme você pode visualizar em outra imagem mais abaixo. Criando Barreiras (Barriers) Junto com o Rack, vamos também criar um par de barreiras para representar paredes ou obstáculos que o operador não pode caminhar através. Clique no ícone do Divider na biblioteca para entrar no modo de criação. Clique em algum lugar ao lado direito do Queue (buffer) para criar um novo Divider. Clique duas vezes mais próximo dos pontos para mostrar a imagem abaixo para finalizar o Divider. Clique com o botão direito do mouse para sair do modo de criação. Adicione os Processors e um Sink conforme imagens abaixo. Faça a conexão deste o Source até o Sink usando a conexão com “A”. Clique sobre o ícone Barrier na biblioteca para entrar no modo de criação. Clique uma vez onde o canto esquerdo inferior do Barrier estará como mostrado abaixo. Clique novamente no canto direito superior para completar a configuração do Barrier. Clique com o botão direito para sair do modo de criação. Coloque o Barrier abaixo do Rack. Execute o Modelo Você pode agora resetar e executar o modelo para ver como será a performance do operador. Lembre-se, se você fizer qualquer mudança nas suas barreiras, o modelo obrigatoriamente deve ser resetado antes de ser executado novamente. Note que o operador encontrou o menor caminho para movimentar-se por cima e por fora do Divider. Embora exista diversas formas de alterar os caminhos do operador (por exemplo, estender ainda mais o tamanho do Divider), nós iremos modificar o caminho percorrido pelo operador, usando o Preferred Path. Crie Preferred Paths Preferred paths não são caminhos “configuráveis”, em vez disso, dará aos nodes associados com o caminho preferido, um peso maior no algoritmo de busca. Isso vai nos afetar, e puxar o operador para o caminho preferido. Clique sobre o ícone Preferred Path na biblioteca para entrar no modo de criação. Crie os dois seguintes Preferred Paths conforme mostrado na imagem abaixo. Preferred paths são unidirecionais e além do mais precisa ser posicionado no layout na ordem correta. Clique com o botão direito do mouse para sair do modo de criação. Execute o Modelo Resete e execute o modelo. Se o seu operador continuar a movimentar para cima e fora do Divider, você pode ou movimentar o Preferred Path ou alterar o Preferred Path weight na janela de propriedades do objeto AStarNavigator. Os Resultados do seu modelo podem variar deste exemplo conforme você posiciona suas barreiras e objetos, o que pode fazer a diferença no cálculo dos caminhos do operador. AStar Navigator Library O AStar é acessado na Biblioteca principal a esquerda: View Menu / Drag-Drop Library Existem 5 tipos de barreiras usada pelo A* Navigator. Estas barreiras modificam a grade usada no algoritmo de busca. Nota: Uma vez que as barreiras são criadas ou modificadas, o modelo precisa ser Resetado para recalcular o node table. Solid Barrier A mais simples das barreiras, a barreira sólida modifica a grade para remover uma área retangular, prevenindo os membros de viajar e (travel members) se movimentarem dentro da barreira. Divider Dividers desconectam os nodes ao longo de seu caminho, prevenindo os travel members de atravessarem o divider. Dividers podem ser modificados na superfície de simulação 3D ao arrastar o ponto final e intermediário. Qualquer número de pontos pode ser adicionado ao divider. One-Way Divider O One-way divider funciona de forma muito similar ao divider, no entanto, travel members são permitidos se movimentarem através do divider na direção das flechas em verde, neste caso, em direção ao topo da página. O one-way dividers pode ser modificado na superfície de simulação em 3D ao arrastar os pontos finais ou intermediários. Qualquer número de pontos podem ser adicionados em um one-way divider. Preferred Path Embora o preferred path não é uma barreira real, ele funciona da mesma forma que as barreiras fazem para modificar a tabela de nodes do A* Navigator. Em vez de modificar os nodes removendo os seus indicadores de direção, o caminho preferencial dá um peso maior a todos os nós associados com o percurso. Este valor de Path Weight pode ser alterado através da janela de propriedades do A * Navigator. O Path Weight tem de ser maior do que 0 e menor que 1, a fim de funcionar adequadamente. Valores acima ou abaixo deste podem causar resultados não intencionais. Os preferred paths podem ser modificados na visualização em 3D, arrastando os pontos do fim ou do meio. Preferred paths são unidirecionais. Qualquer número de pontos pode ser adicionado a um preferred path.

These instructions are to be performed on a license server hosting FlexSim licenses. You will need the license server files. If you do not already have a copy of those linked files on your license server, download them to your license server then extract the entire archive to a convenient location.   Run flexsimserveractutil.exe as an adminstrator by right-clicking the .exe and selecting Run as Administrator. Go to the main menu, Tools > View License Rights. Scroll through the displayed license information. Find any activated licenses that indicate they are broken. Find each broken license's Fulfillment ID (starts with FID_). Copy the Fulfillment ID to the clipboard (highlight including the FID_ prefix, through to the end of the line. Ctrl-C to copy). Go to the main menu. Select Connect > Repair. Paste the Fulfillment ID into the field (Ctrl-V). Delete any spaces that may have been included before or after the pasted Fulfillment ID. Press the Repair button. The utility will attempt to contact FlexSim's license server in order to repair the license.   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.

This article explores creating Fluid Tanks from a Basic FR and Process Flow. This turned out to be a lot more complicated than I thought. If you need fluid objects in FlexSim, use the standard fluid objects in the library or buy FloWorks. The approach in this article requires a lot of up-front work just to get started, and you probably want to spend that time configuring well-tested objects instead of cutting your own path. This article is directed at two audiences: Those who don't want to use the fluid library or FloWorks (they have elected the way of pain) Those who like learning from example models If you are still interested, read on! TankDemo_10.fsm Kinetic Tracked Variables Tracked Variables hold a number. As you change the value, the Tracked Variable tracks the min, max, average, etc. You can optionally track the history of the value over time (this history) or the amount of time spent at specific values (the profile). You can also listen to when a Tracked Variable changes. A special kind of Tracked Variable is a Kinetic Tracked Variable (KTV). A KTV lets you set a rate. The rate is the ratio of the change in value divided by the change in model time units. If you set a rate, the KTV records when you set the rate and the initial value. In this way, you can as a KTV for its value at any point and get the exact continuous value. KTVs are the heart of this model. You can use a KTV as a label value. Each tank has a label called "Level" that is a KTV that holds the level of the tank. They are also used to represent the progress of a transfer of fluid between tanks. Custom Draw The fluid tanks you see in the model are BasicFR objects. The shape of the object is set to a cylinder. The color of the object determines the color of the fluid. To draw the changing fluid level, the OnDraw trigger of the tanks use the Level label to determine the height of the fluid. Then the OnDraw trigger draws a cylinder covering the remainder of the tank. Because the draw code accesses the Level label's value, the cylinder will change as the value of the Level label changes. Tank: An Object Process Flow Most of the logic in this model is defined in an Object Process Flow called Tank. I used an Object Process Flow so that it would be easy to attach other objects to the flow to imbue them with fluid tank logic. In a way, it's like defining a programming class. When you attach an object, you create an instance of that class. The Tank flow defines behavior for a general fluid tank: A Tank can have fluid transferred in, out, or both A transfer indicates a source tank and a destination tank, and amount, and a rate. If the source tank is null, then the fluid is generated in the tank. If the destination tank is null, fluid is consumed in the tank. A tank can have as many active transfers as the user adds to it. There's not an accompanying concept of "pipes" in this setup. Each transfer changes the rate of the Level KTV for each tank. If the tank gets full, input transfers are paused until the the tank empties below a threshold (95% of its capacity). If the tank gets empty, output transfers are paused until the tank fills above a threshold (5% of its capacity). If the tank is stopped, both input and output transfers are paused until the tank is resumed. The Model Logic The model logic is contained in the process flow called Process Flow. It picks a random recipe from the Recipes table and uses that to create transfers into the Mixer tank. Once those transfers are complete, the Mixer tank empties itself. When it's completely empty, the tank produces an item. Then that process repeats. By using an Object Process Flow, the logic for "how to tanks work in general" is separated from "what are the tanks doing." Pros and Cons The main con is that you would need to implement this logic yourself rather than starting with an object. This includes finding and fixing bugs. I have found and fixed many bugs in this demo model, but I'm fairly confident there are more. It turns out creating an object is tricky. However, there are a few pros: Compared to the fluid library, there is no ticker. The fluid library relies on a ticker to handle changes in level. This approach uses KTVs instead. KTVs are newer than the fluid library. A ticker adds a frequent event to the model and loops through fluid objects checking for changes. It is possible that the approach in this article is more accurate and faster to run. It's also possible that it's slower, due to the number of process flow activities. Compared to FloWorks, there is no monetary cost. This may actually be a con as time spent developing logic is an expense. This approach will take 10x longer or worse to get right. Your future self will thank you for just buying it. You have full control over the behavior. If you don't like how something works, or you want to add additional logic, the logic is all available for you to edit. Again, this might be a con, because you have to fix bugs as you make them. Conclusion Overall, this demo model shows lots of FlexSim features working together. That is valuable in itself. As a replacement for fluid objects, this demo model isn't a great route, unless you have very specific needs. As I built this model, I realized that I was probably solving the same set of issues that the developers of the fluid library were solving. What I thought was going to be somewhat simple turned out more complicated. I still think this is doable, but I'd look at other options very carefully first.

FlexSim 2018 Update 2 Beta is available. (Updated 26 July 2018) To get the beta, log in to your account at www.flexsim.com, then go to the Downloads section, and click on More Versions. It will be at the top of the list. 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 Added an interface for running experiments and optimizations on the cloud. Added a mechanism for adding new charts as experimenter performance measures. Added a Sankey Diagram to the dashboard charts. Added a Milestone Collector statistics tool and chart templates. Added a way to customize how objects draw their 3D shape meshes. Added {} syntax to specify FlexScript expressions in SQL queries. Added a Down Behavior tool that can be used by Time Tables and MTBF MTTR objects. Added a message() method to the Object class to replace sendmessage() and senddelayedmessage(). Added a varchar bundle field type for variable-length strings. Added status bar updates to the table view. Updated the bar and pie charts with more options and data formats. Added duration settings to the gantt chart. Added new task sequence classes to the FlexScript API. Added a getCategoryName() method to the TrackedVariable class. Added getEntryFromValue() and reevaluateBackOrders() methods to the List class. Added padStart() and padEnd() methods to the string class. Added an option to sort back orders independent of entries when reevaluating back orders. Added an option to configure a list to always leave its entries on the list. Added events to the Statistics Collector. Added options for sorting rows in statistics collectors. Added dot syntax label access to List.BackOrder. Added a backOrder keyword that is available in a list back order queue strategy. Added a new overload to List.pull() that takes both an array and a query. Updated user library functionality to better handle conveyor types and containers. Updated Move into Highlighted code to preserve global position and rotation. Improved sampler options in various places. Improved drop-down options with label values in several places. Updated the Ctrl+W keyboard shortcut so it correctly closes the window that has keyboard focus. Updated the query() command to re-throw exceptions. Fixed a bug with updating bundle indexes when using certain commands. Fixed a performance bug with pasting into bundle tables. Fixed a window docking bug. Fixed a bug with the robot not drawing collision spheres or its stopped indicator. Backwards Compatibility Note: the following changes may slightly change the way updated models behave. Changed Variant math operations on non-numbers to throw exceptions. Updated the Source to automatically attach task executer flowitems to the DefaultNavigator. Updated dumpquery() to use bundle varchar fields. Fixed an issue with the Z-axis being inverted for screen-locked shapes in perspective 3D views. Process Flow Added stop() and resume() methods to the Token class. Updated global shared assets so they now have a separate global block instance. Updated Edit Mode so you can no longer move activities when it is off. Added a check box to quick properties to turn off all trace histories. Updated Wait for Event to handle listening to arrays of objects. Updated Pull from List so you can use it with a Resource shared asset. Updated the Resource so you can point it at a global List or a List shared asset. Added a way to sample shared assets in certain fields. Updated the naming convention for Resource object copies. Added an error message when trying to rename a shared asset the same name as another. Improved the performance of the Wait for Event activity. People Updated the multi-location to allow people to enter without an available sub-location. Conveyor Added a max count slug building property to the conveyor type. Added a catch condition to the power and free functionality to customize whether a given dog will actually catch an item. Added the capability to reverse conveyors under certain conditions. Changed the roller skew kinematics to be based on item travel distance instead of time. Changed the conveyor's belt repeat distance to sync to the adjusted dog interval. Fixed a bug with decision points snapping to grid when added with a conveyor from a user library. AGV Updated path transfers to prioritize their requests. Fixed an issue with accumulating path allocations causing AGVs to get stuck. Fixed various issues with AGVs having different deceleration values. Backwards Compatibility Note: the following changes may slightly change the way updated models behave. Improvements to AGV proximity detection on accumulating paths. Emulation Fixed Modbus polling for changes. Fixed the Modbus panels in the Variable shared asset so they show the associated object now.

The attached model draws a heatmap based on the total time AGVs are blocked in a particular location.   Approach Outline This model creates the output graphics as follows: There is a Group of all AGVs. A Statistics Collector listens to all state changes on all AGVs in the group. Each time an AGV goes into the “Blocked” state, the Statistics Collector adds a row, recording the location of the AGV and the current time. Each time an AGV leaves the “Blocked” state, the Statistics Collector updates the row for that AGV to calculate the total time the AGV was blocked. A Shape object (called CongestionHeatmap) reads the data in the Statistics Collector and draws the heatmap. All block times in the table are grouped into spatial “Pixels” based on the block location. Note: this article uses the word Pixel to mean the squares in the heatmap. For each Pixel, the shape sums the total block time in that Pixel. Pixels are colored relative to the Pixels with the most and least block time. Design Points The legend, drawn near the CongestionMap shape object, shows the numerical values for the min and max block time. To disable the heatmap, disable the Statistics Collector. To clear the heatmap, reset, then step, then reset again. Alternatively, you can call the resetheatmap() user command. The heatmap is cleared in the OnSimulationStart trigger of the CongestionMap shape. This way, the heatmap can be viewed when the model is reset. This way, the heatmap is visible without obscuring (or being obscured by) the AGVs. To change the Pixel size, set the PixelSize label on the CongestionMap shape object in the model. There isn’t  much of a performance impact to changing the pixel size. Choosing a good size is more like choosing a good bucket size for a histogram. If the Pixels are too large, it will be hard to tell where the congestion is truly happening, as a single Pixel might cover many areas of the network. If the Pixels are too small, congestion accumulation may be spread between many pixels, making the hotspots harder to see. You can change the pixel size during the model run if you change the label and call the  resetheatmap command. Performance is good. The biggest impact is from listening to the On State Change event of the AGVs. This model starts a real-time timer in the On Run Start model trigger and stops the timer in the On Run Stop model trigger. The output console shows the duration. You can compare model performance with and without the heatmap this way. This approach is most helpful with AGVs. However, it works with any object that goes in the Blocked state. AGVs just happen to go into a blocked state when they accumulate or when they can’t acquire control points/areas. The heatmap is drawn using a mesh. The mesh is more complicated to create, but is much, much faster to draw than using other draw commands. Meshes are used to draw triangles. Each Pixel is drawn as two triangles that form a square. All vertices of that square are set to the same color. Using a mesh also made drawing the legend simple. Meshes always interpolate colors between vertices. The legend draws squares where the top vertices are set to one color and the bottom vertices are set to another. Moving the CongestionMap object does not move the Pixels, so you can place it anywhere in the model. The legend won’t move until the next model run. How To Recreate in Another Model Create a group containing all the objects (AGVs) that should contribute to the heatmap. Create a Statistics Collector to record the location and duration of the block time For the On State Change event, the Statistics Collector responds twice. First, to finish the existing row and second to start a new row. When a row is added, the Statistics Collector adds a row label to record when the block started. When a row is updated, the BlockTime column is set to the current time minus the start time. Create a Shape object. Shape Object Details The shape object has the following labels: PixelSize – the size (in model units) of a Pixel. MeshZ – the height of the heatmap. If you set this to a non-zero value, be sure to reset the 3D view’s rotation and uncheck the “Perspective Projection” box. mesh – this label contains the mesh data. MeshMap – this label holds a Map (a collection of key-value pairs). Each key is an array containing the x and y coordinates of the Pixel. Each value is an array of the vertex numbers for that pixel. VertCount – the total number of vertices contained in the mesh. The mesh grows as blocks occur in more places. MaxBlockTime – the maximum block time in any Pixel MinBlockTime – the minimum block time in any Pixel The shape object as the following triggers: On Simulation Start – clears the mesh, MeshMap, VertCount, MaxBlockTime, and MinBlockTime labels. It also adds vertices to draw the legend. On Pre Draw – adds vertices (if needed) to the mesh and changes the vertex colors. This is the most complicated part. First, loop over the data in the Statistics Collector. For each “block” record: Use the exact location to calculate the Pixel location. Using a map, increment the running total of block time at that Pixel Keep track of the min and max values. Then, loop over the pixel/block time map If the MeshMap doesn’t have vertices for the desired Pixel, add them to the mesh and to the map Based on the color from the color palette, set the color for all six vertices. On Draw – draw the triangles of the mesh. Important: OnDraw should not change the mesh. OnDraw is called many times per draw to calculate shadows. OnPreDraw is only called once. Disable lighting – colors are not “shadowed” and the Pixels don’t draw shadows. Set the PolygonOffset so the mesh is always drawn above the grid.

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

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.

In the attached model we use a Timetable and two MTBF/MTTR objects to define Schedule Loss, Availability Loss (breakdowns) and an element of Performance loss due to short stops (state Down). The processor sends 'bad' items to port 2 based on the send to percentage which account for QualityLosses. The processor's 'best' processing time per part (5 seconds) is stored as a label, while the processing time itself is a triangular distribution with the minumum as 5 seconds - so it also contributes to performance loss. When the Type of the item changes a setup time occurs which is the final contributor to performance loss. Two state profiles were added to the processor - one to track production time and another for availability. An object process flow on the processor detects production profile state changes (between On and off shift) and regular Flexsim state changes and determines the availability state that should prevail. A user command getOEEstat is used to access the values which it calculates on demand and stores in a label on the processor called statsMap. The syntax for this command is: getOEEstat(myMachine,"OEE") The list of stats: "ScheduleLoss","AvailabilityLoss","PerformanceLoss","QualityLoss","IdealProdTime","AvailabilityRatio", "QualityRatio","PerformanceRatio", "IdealProdTime", "RunTime", "OEE", "TEE". A group was used to indicate which objects have their OEE tracked, and a stats Collector reads the group members and adds rows at reset. Finally Performance Measures were added for the stats for processor 1. Processor_OEE_2.fsm 2023-08-22 Update: Added 'TEE' stat.