FlexSim 2021 Beta is available. (Updated 19 November 2020)
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 dev@flexsim.com or create a new idea in the Development space.
Backwards Compatibility Note: the following changes may slightly change the way updated models behave.
fireFlexsimEvent("myEvent", param1, param2, function(result) { alert("result: " + result); });
Backwards Compatibility Note: the following changes may slightly change the way updated models behave.
You can use those web pages in conjunction with the FlexSim Web Server to create a custom website of multiple pages as the web interface to your model.
The Web Page tool makes it easier to define and test those pages within your model.
I and my customers hope each items in the release note will be written more detail including screen capture and usage examples and what's the benefit when using the new released edition.
We should make and need the current customers to understand the benefit of using the upgraded new edition flexsim. But the most customers can't understand it via a only the one row explained feature.
Hello @SudheerReddy,
FlexSim releases 3 major updates per year:
Many customers are sending feature requests all year long. Some customers don't want to wait 1 year before the next year release to get new features. These users can be satisfied with the releases of Updates 1 and 2 during the year.
In parallel, for those who might not need the latest features, FlexSim maintains the year release for more than 1 year. The year release is called the Long-Term Support (LTS) version. If you prefer using the LTS, that means you only need to update once a year to get new features.
If you want to know more about the release schedule, I recommend this post:
https://answers.flexsim.com/articles/60173/flexsim-version-numbering.html
@Seung Yong Seo The release notes are linked to the documentation for the various new features. There will be more marketing material made before the new version actually releases in December.
Bugfix releases are also produced regularly, both for the latest update, as well as the LTS release.
We always recommend using the latest bugfix release, in order to take advantage of the various fixes that may solve problems you could encounter. Keeping up to date with bugfixes will mean that you should download and install multiple times per year.
This is just the nature of software. It is always improving. You can always choose to remain on an older version, but to take advantage of the latest features and fixes, stay on the current release.
Removing conveyor types is a major problem. Will it be possible to retain them for this release, to give us time to phase them out? Will you phase out all kind of types ? Transfer Type is retained for now?
What is approximately the expected date for the final 21.0 relase ?
First week of December
What issues are you having with the removal of conveyor types? Do you have a particular model or situation that is not being updated properly?
What time do you need to "phase them out"? What are you planning on doing in order to "phase them out"?
Conveyor transfers that are created and deleted simply by dragging conveyors around have retained their Transfer Types in order to avoid losing that data. You can still use Transfer Types to configure these types of transfers so that if they are accidentally deleted by moving a conveyor, it is easy to set them back when you reconnect the conveyor.
We removed conveyor types to bring consistency to FlexSim's object library. We do not have this type mechanism for other objects in the library (processor types?, rack types?, operator types?, transporter types?). Why should conveyors be different? The conveyor types were inconsistent with the general FlexSim design. That said, we do have visualization types for racks. This is what we've consolidated the conveyor types to now, namely shared visualization properties. We've realized that shared behavior properties bring with them just as many problems as benefits. For example, conveyor types prevent users from using the new property tables, and the new Object.setProperty() mechanism for defining behavior properties on a conveyor. Also, if you have a conveyor that is the same as other conveyors of its type in all aspects except one, you still have to create a new conveyor type. This defeats the purpose of the shared behavior of conveyor types. If I have 15 conveyors with 15 different max speeds, with all other conveyor type attributes being the same, I still have to create 15 different conveyor types.
By moving conveyor behavior properties to being owned directly by the conveyor instance, we are bringing more consistency, and hence learnability, in allowing users to define object properties. You can still view and edit the properties of large numbers of conveyors using property tables, or by selecting multiple conveyors and editing properties in the properties window. This is consistent with how you do it with other library objects. If a user learns this mechanism with processors, that user will automatically know how to do it with conveyors. For example, you can use groups to essentially replace conveyor types. Add the set of conveyors that were previously part of a conveyor type into an object group, then create one or more property tables that filters by that group. Adding/removing conveyors from that and other groups is automatically reflected in the property tables that are filtering by the group.
The transfer types will remain, specifically because conveyor transfers are so ephemeral. Simply moving a conveyor will delete and create new transfers, which would be very frustrating if the user just spent significant time defining the properties of the transfer that they subsequently deleted.
The issue is that it takes some time to upgrade 2020.2.3 models, as they don't run in version 2021.0.0. It is not a problem for new models or small/simpel models. So I will get on with it.....
Why don't they run in 21.0? Have you opened these models in the beta? They should still work after the model update script runs in 21.0. If you have a model that's not working you should send it to us and we'll make sure it works.
Lars,
There are only a few potential updating issues that I have encountered in updating models. First, if you have code that is accessing/changing the conveyor types in the tree, then obviously this is not supported and breaks forward compatibility. This unsupported customization is one reason why we have introduced properties, property tables, Object.setProperty(), etc., because they provide a forward-compatible mechanism for changing object properties. Second, there was a shift in the parameter numbers for photo eyes, decision points, and stations. We have tried to provide update scripts that automatically update these triggers, but in some cases (namely if you use param() directly in your custom code), then it may not update properly.
Please let us know why your model is not updating properly, or send us your model so that we can fix this issue with the update. We want models to update easily (at least, models that haven't broken forward-compatibility rules).
Anthony,
In my OnModelReset trigger, I am updating the conveyor speeds based on the conveyor type:
Model.find("ConveyorSystem>variables/conveyorTypes/ConveyorTypeXXX").subnodes["speed"].value = some parameters;
resulting in "exception: FlexScript exception: MODEL:/Tools/OnModelReset".
It is not a problem changing it, it is just that it is a fairly comprehensive model so it takes time creating Groups of conveyors instead of using the conveyor type. But as a shortcut I can use the Visualization type to identify the conveyors and to create groups. And then I have to re-validate the model....
I appreciate Visual Studio Code's release notes. Here is one example:
Visual Studio Code October 2020
They always have lots of images, animations, and links to fully demonstrate highlighted changes. I don't think every single little change or bugfix is highlighted in this way, but I've always been impressed at the depth they go to.
@Markus Cueva, if that is something worth pursuing, as dev team makes these changes and tests them seems the logical time to capture these animations, screenshots, and summaries - they're the ones that know exactly what changed, and how to demonstrate it - but if they don't think that is a good option, maybe it would be something that could be farmed out to the company via assignments on a Google sheet. But it does seem a little counter-intuitive to do it that way, since we'd have to go to dev team to find out exactly what changed and how to demonstrate it 😉
FYI, you can also use Table.query() and the properties SQL mechanism, to update conveyor speed properties:
Table.query("UPDATE Objects() SET ConveyorSpeed = 4.2 WHERE 'Conveyor::Conveyor' IN Classes AND ConveyorVisualization.name = 'BeltConveyor'");
Or you can update the group membership (for example adding conveyors with the belt conveyor visualization to the 'BeltConveyors' group:
Table.query("UPDATE Objects() SET Groups = Groups.push('BeltConveyors') WHERE 'Conveyor::Conveyor' IN Classes AND ConveyorVisualization.name = 'BeltConveyor'");
The 21.0 release notes are linked to their documentation pages that show this type of detail. It's redundant to put it into the release notes themselves.
Thanks @anthony.johnson. Property tables are great. I just have to work more with them to get the full benefit (you know, breaking old habits can take time :))
There was an issue with the Nov-5 installer of the beta version that is causing it to not upgrade properly to the new Nov-19 version. You should uninstall the old version of the beta via Add or Remove Programs before installing the new version.
@anthony.johnson I don't understand the :: syntax. Sometimes it is for defining a method outside a class, but I guess that is not the case here?
It is a scope resolution operator please search the web for "c++" and "::".
@Lars Christian J2 Yes, you use the :: operator to define a method outside of a class in C++. As Jörg explained, it is a scope resolution operator. In terms of defining a method, you specify the class to the left of the :: operator and the method to the right. When using a class in a namespace, you specify the namespace to the left of the :: operator and the class to the right.
https://docs.microsoft.com/en-us/cpp/cpp/scope-resolution-operator
In terms of FlexSim class names, we use this syntax for classes added by modules, similar to namespaces. The Conveyor class is defined in the Conveyor module so its class string is Conveyor::Conveyor, as you can see by looking at the object's classes node in the library:
@Lars Christian J2, yes all of the previous explanations by @Phil BoBo and @Jörg Vogel are correct, but in the end it just comes down to what you can glean directly from a property table's filter. If you click on a conveyor in your model, then press the button in its Conveyor Behavior properties pane, then choose some option like Basic Conveyor Properties, you'll notice the filter at the top of the property table.
This says that the property table should only show objects whose Classes field (which happens to be an array field) includes the string "Conveyor::Conveyor". You can also see the array of classes that model objects are instances of by adding the Classes field as part of the table's fields.
I've taken off the filter in the screenshot below, so you can see the Classes field of all objects in the model.
Each property table has a filter, sorting rule, and set of fields that can all be represented as a SQL query. By pressing the SQL button in the property table, you can see the full query that corresponds to this table.
This SQL query can be directly passed into Table.query(). This means that you can use property tables to help form the queries that you pass into Table.query(). This is exactly what I did to help me figure out how to create the UPDATE query I gave you. In the end, it doesn't really matter what the double colon :: syntax means. The more important point is that the property tables say that the Classes array value of a conveyor instance includes the string "Conveyor::Conveyor", so I use that.