Do Simscape Multibody Link settings in SolidWorks affecting anything?

I have been familiarizing myself with the Simscape Multibody Link program in tandem with SolidWorks, and I have had only few issues during this process. Now however, I have ran into a wall with trying to figure out what the Simscape Multibody Link settings on the SolidWorks side do, because at the time when dabbling with them, I have not noticed almost any difference in my model regardless of what settings I use in the exporting process.

I am using MATLAB version R2020b and SolidWorks version 2019. These should be supported versions to use Simscape Multibody Link.

First is the Solve Subassemblies Using setting, which has options Component Properties and Flexible Settings.

The image is from SolidWorks

It doesn't matter which option the user chooses, as this setting has absolutely no effect on the generated .xml-file. I generated few test .xml-files with this setting toggled between them and compared their contents with several programs, and the only difference in these files were the time of day they were generated. The Simscape Multibody will always solve the subassemblies with the Component Properties option.

The imported Simulink Models were also identical, even though the documentation promises that all the subassemblies would be changed into flexible and have joints if that was possible.

The image is from SolidWorks

The other option that doesn't seem to affect anything is the Assembly Tolerance. I tried to see if this affects anything within the exported .xml-file, but the only thing changed was some numbers on the scale that didn't correspond to the tolerance scale I requested in the settings. I also didn't see any difference in the imported Simulink Models behavior.

The main reason to ask, this is that I'd just like to find out if this is done on purpose or is this a bug that I should report? These settings would make the usage of the Simscape Multibody Link so much smoother, as the CAD models I'm dealing with are massive. I'd really appreciate the ability to just change all the subassemblies flexible for the Simscape Export without going through every single subassembly and make them flexible manually. I'd also very much use the ability to lower the accuracy tolerance on my exported models, as the default 1e-12 is absolutely too accurate for the models I'm exporting. This, of course, in the hopes that it will make the export process a bit shorter and the Simulink Model run smoother.

Thank you for reading. I hope to get answers soon.

Answer 1

[Steve Miller]

Hi Aatu - this documentation page covers many of the settings you are exploring.

1. Solve Assemblies Using - this enables you to ignore the joints within a SOLIDWORKS subassembly and treat everything as a set of rigidly attached bodies. It cannot, however, override the properties of the component within the assembly. If you are seeing a subassembly always being exported as a rigidly connected set of bodies, you need to adjust a setting within SOLIDWORKS. Right click on the subassembly and go to Properties. A screenshot of the dialog box in SOLIDWORKS is shown below.
2. Assembly Tolerances - the export process checks for spacing and alignment to ensure that the model you obtain in Simscape Multibody is kinematically viable. If, for example, you have a kinematic loop of parts, but stackup error of all elements going around the loop would prevent the loop from being closed, that is physically not possible and the model will not run. A common place this is an issue is a chain of revolute joints. All z-axes must be aligned within tolerance, otherwise it is physically impossible to assemble the system. If your CAD model is well-built, the tolerances will have no effect on the result.

The export process is probably most dependent upon the number of parts and constraints in your model. Treating subassemblies as rigid may save some of the assembly tolerance calculations, but the export process still needs to produce the geometry. You could try testing exporting STL or STEP files, one or the other may be faster.

--Steve