sticky rmi integration errors

We once tested the Intland Codebeamer requirements integration to Matlab/Simulink. Later we decided to use other tools for requirements management. With the Matlab-Release we installled it to there are no problems, but on more recent release installations we get warnings and errors like

Warning: Failed to register requirement link type "intland_codebeamer_rmi".

Error message: Undefined variable "linktypes" or class

"linktypes.intland_codebeamer_rmi".

Warning: Failed to resolve link type by registration name:

intland_codebeamer_rmi

> In rmiml.selectionLink

even though the integration has never been installed there. Any suggestion how to get rid of it?

[Robert Lummert]

On my inquiry at Intland on how to remove their integration I finally got the answer, that they currently do not support the (their own) Matlab/Simulink Integration. Thus I think the "intland_codebeamer_rmi" should rather be considered a free prototypic addon that you run completely at your own risk and that's not likely to be debugged in any way.

[Robert Lummert]

While the rmi integration does not come with any deinstallation routine, the Codebeamer client does. Anyway, after uninstalling the whole Codebeamer client I was left with the same error messages in R2019a. The only difference is that the same error messages now also turn up in other release installations as well.

[Artem]

previous registration for custom document type is stored in user preference under your prefdir.

Usually you get a new prefdir when you install a newer version of MATLAB, but if your previous settings where copied, you will get the old registration.

To cleanup all custom document type registrations in your user preferences, run the following command in MATLAB:

>> rmi.linktype_mgr('reset')

[Robert Lummert]

Hi Artem,

thanks for the answer. Actually I was asked by Mathworks staff (Joshua) to remove the prefdir for 2019a already, but this didn't help. Accidentally I just now ran rmi.linktype_mgr('reset') on R2018b (where - magically - the warnings never occurred, anyway). When I opened R2019a the warnings were already gone. Does this mean R2018b installs with a virgin set of preferences, while 2019a installs with a copy of some patchwork of older installations' preferences without asking me? And does running rmi.linktype_mgr('reset') on one installation modify ALL installations?

Best regs,

Robert

Answer 1

[Robert Lummert]

As it seems

>> rmi.linktype_mgr('reset')

will solve the problems (thanks again to Artem, see comment above).

But one should be careful when having multiple Matlab installations on the same machine (e.g. when doing toolchain engineering), as this command seems to influence not only the Matlab installation it is executed in.

[Artem]

This is true in general: All user settings accessed via Requirementns > Settings dialog, or via rmipref() API are stored in rmi_settings.mat file under user's prefdir. If you are experimenting with mutiple installations of MATLAB and reusing the same prefdir content, you will notice that settings you change in one installation will show up when running the other installation. May be the workaround is to use different usernames (tester1, tester2, ... that sort of thing).

[Robert Lummert]

If your job is to maintain model based toolchains using simulink, you need to have different versions of matlab installations available, I wouldn't call this experimenting.

The different user approach then has major drawbacks as many network resources (net shares, email, different company portals) won't be available like that. And even worse: I would need as many sets of licenses as users, or I would have to switch all licenses to machine licensing, meaning they can't be swapped with other users anymore.

For many years parallel installations of Matlab were care free, but now it seems to become a real pain in the ass. Is there any reason for messing up the preferences of different installations where it comes to rmi? I mean, you still have seperate sets of preferences in the roaming data folder and some other settings still seem to be handles independently...