Errors when adding components to Module

[joe_s2]

[ FlexSim 20.2.3 ]

I been constructing a module in FlexSim 2020.2 and I've recently been finding that sometimes when I update user created objects in a Custom Module that FlexSim will periodically exhibit strange behavior. So far I've seen objects disappearing from a tree or toolbox, object icons changing in the 3D viewer and label values failing to update during simulation or even referencing onReset overrides when reset hasn't been triggered.

I was wondering if there is maybe something wrong with how I update my Module. I generally will use "Add as Replacement" on a parent node from the changes made. However if I make significant changes, I will select remove and then "Add as Addition."

Are there any best practices to prevent this strange corruption from periodically occurring or could the be something else going on with FlexSim?

[JordanLJohnson · Accepted solution]

Hi Joe,

I'd say that we don't typically see the behavior you're talking about. Can you provide more detail about your workflow? In general, we don't use the "Add as Replacement" option in modules, and I'm curious why or how you are using it. If all you are doing is modifying an object that the module added (say, in the library), all you need to do is save defaults; you wouldn't need to add or remove the node at all, even if the changes are significant.

Do you see the issues after you save the defaults? I have sometimes noticed issues after I save the defaults, but closing and reopening FlexSim seems to resolve the issue.

[joe_s2]

The specific module I'm working with has the requirement of needing to be distributed throughout the workflow (mainly so other team members can construct and use the models generated. I've found that the save defaults will only save changes consistently with the exact version of FlexSim I used to make the changes on. If I switch to a different version on my PC or if I push the module to a team member to use then the changes don't hold.

Since then I've found "Add Addition" works well for keeping the changes to the module and not to the workspace as Save defaults but it seems to be more prone to errors.

Reworking through this process development again, I've seem to have found a third option that works quite well on both fronts (module transfer bonuses of "Add Addition" and stability of Save defaults). The new process is to...

1. Save changes to the .fsl for the object/flexscript updates
2. "Remove" the library
3. Close the library
4. Save defaults
5. load the library
6. "Add as Addition" to the module

This works and fulfills my needs for the project but seems to be very cumbersome. So while this does solve the problem I'm not going to click "Accept Answer" because I'm still unsure if I'm using FlexSim properly to get the end results I'm looking for.

[JordanLJohnson]

You are correct that modules only work with the major version of FlexSim, such as 21.0 or 21.1. It should work between bug fixes, such as between 21.0.5 and 21.0.6, for example.

It sounds like you're using a .fsl file to add a custom object. If that object is just a configuration of a FlexSim object (different shape, custom pickoptions, etc.) then a .fsl file is probably easiest. Then the .fsl file adds the object.

My guess is that you have a module dll for supplying commands, which your custom object uses. To build a module dll, you will need to compile it for each version of FlexSim, as explained above. Using a module dll compiled for one version will probably not work, or introduce instability, if used in another version. To compile a dll for each major version, you can get the header files and .lib files from the version you compile against as explained here:

https://docs.flexsim.com/en/21.2/Reference/DeveloperAdvancedUser/ModuleSDK/QuickStart/

Since you have a module that must be compiled for each version, you could, in theory, just use the module, and not use the .fsl file. You could add your library as an addition to your module, then remove your .fsl file completely. The object you add to the library would probably just work in newer versions, since you are just adding a node there.

If you want a custom workspace for your module in addition, then you would probably need to upgrade that part of your module from version to version. Usually, that just means opening your module in a new version (assuming the dll has been compiled for that version), create the workspace you want, and save that workspace as the default.

So your steps technically work. I think if you moved to a single module, rather than a .fsl file and a module, then your workflow would be simpler. But it's hard to say without seeing your exact setup. It could be that your solution is the solution you need, given your circumstances.

[ryan_c10]

Hi @Joe S2, was Jordan Johnson's answer helpful? If so, please click the "Accept" button at the bottom of their answer. Or if you still have questions, add a comment and we'll continue the conversation.

If we haven't heard back from you within 3 business days we'll auto-accept an answer, but you can always unaccept and comment back to reopen your question.