Support of SimulationX wanted? about modelica_devicedrivers HOT 24 CLOSED

Of course, supporting the library in SimulationX would be great!

In Dymola it is the most portable way to just include the whole source code, since this avoids all the linking issues that arise when using a model with different compilers and platforms.

So, is it possible to keep the "include the whole source code" style and introduce the "__iti_dll" vendor annotation in an orthogonal way?

from modelica_devicedrivers.

Yes, the Include annotation is ignored for built-in BDF simulation, instead a library must be provided, either by Library or __iti_dll annotation.

Currently I have three libs (SpaceMouse not yet done) as I do not want a lib for each file.

• canL2_ for SoftingCAN
• X11 for the InputDevices
• rt for all the rest (even though it has nothing to do with real-time)

from modelica_devicedrivers.

I need to guess a bit.

I suppose you chose the names of the libraries, so that SimulationX is loading this DLLs instead of trying to link against the static (system) libraries as declared in the external function annotations?

Note that I provided "rt" and "X11" as dummy (empty) libraries for Windows. This systems libraries are required to be linked against in Linux, however they are not required for Windows. Since I can't state that logic in the Modelica external function annotation I provided dummy "rt" and "X11" libraries so that the linker finds s.th. to link against when translating on a Windows platform.

Would it be possible to use different (less misleading) names for the DLLs and the "__iti_dll" annotation and let SimulationX then just "ignore" the static dummy libraries specified in the "Library" annotation?

from modelica_devicedrivers.

I created a new branch for experimenting with the DLL wrapper (see comment above). I added code to create a DLL called MDDWrapper.so (using the Cmake build tool). If needed, I think one could provide dummy DLLs for "rt" and "X11" and use a more meaningful name for the library that wraps the whole thing into a DLL.

Do you think this is a reasonable approach to get in support for SimulationX?

I noticed that in your forked repo you use a static lib called "ModelicaExternalC.lib", in order to allow compilation of files using "ModelicaFormatError(..)" and alike functions to DLLs. I preliminary added that library in https://github.com/modelica/Modelica_DeviceDrivers/tree/dllwrapper/Resources/thirdParty/ITI

What is the legal status of that library. Is it an (open-source) Modelica License 2 library or is it an ITI-library with another license?

from modelica_devicedrivers.

Thanks for considering this.
Actually I do not like the names rt and X11 even though they are dummies which I was not aware of. I propose to create a library ModelicaDeviceDrivers that contains all the modules that do not require special driver dependencies. So basically it is rt + X11 + MDDUtilities like you proposed in MDDWrapper.

#include "../../Include/MDDBeep.h"
#include "../../Include/MDDJoystick.h"
#include "../../Include/MDDKeyboard.h"
#include "../../Include/MDDRealtimeSynchronize.h"
#include "../../Include/MDDSerialPackager.h"
#include "../../Include/MDDSharedMemory.h"
#include "../../Include/MDDUDPSocket.h"
#include "../../Include/MDDUtilities.h"

You then can remove the rt and X11 Library annotations and replace it by the new ModelicaDeviceDrivers Library annotation.

MDDSpaceMouse and MDDSoftingCAN should go to extra libs since they require special drivers at run-time (like canL2). I propose to call the libs ModelicaDeviceDriversSpaceMouse and ModelicaDeviceDriversSoftingCAN (or similar).

If a Library annotation is not set (see getDataSize above) an appropriate __iti_dll annotation must be set. Actually I would prefer to also have the Library annotation here (instead of a vendor specific one) but since both are Modelica conform I can live with either way.

ModelicaExternalC.lib is required to build a DLL (which unless a LIB has all external symbols resolved). As soon as you link to ModelicaExternalC.lib from ITI the built DLL is SimulationX specific of course. I am not sure about the license. I guess it is similar to ModelicaExternalC.lib from Dymola which needs to come with the installation. But since SimulationX built-in simulation requires a compiled DLL for external code we must provide ModelicaExternalC.lib. In the MSL we provide some source of ITI_ModelicaUtilities.cpp. But I do no longer recommend to use this ITI_ModelicaUtilities.cpp but rather link to ModelicaExternalC.lib (from ITI) which is the better solution for creating external DLLs for SimulationX. Maybe I should update it in the MSL too.

from modelica_devicedrivers.

Alright, I will go on in that direction and try to provide a library that uses DLLs such that also SimulationX can use it. However, since it must use an SimulationX-specific "ModelicaExternalC.lib", I will change the naming of the wrapper-DLL to reflect that it is ITI-specific.

Completely removing the rt and X11 library annotations is not so easy for three reasons:

1. Packing several (static) libraries in one (static) convenience wrapper-library using the gcc toolchain seems not so easy as with the VS toolchain. It can be done easily if using a shared library, however I don't like the shared library approach. You can't just copy around and execute a binary that has this shared library dependencies (always need also to think of copying the shared libraries and some users will be puzzled about that). This is a bit inconvenient and I try to avoid it if possible.
2. I'd like to ensure that the linker uses the rt and X11 libraries that come with the distribution on which the whole thing is compiled. To me that seems to be the most robust way.
3. There are no supported pragmas in GCC that would allow linking in the VS style "#pragma comment(lib, "mylib.lib")", so this is no option for Linux.

from modelica_devicedrivers.

What is next? ITI_ModelicaDeviceDriversSpaceMouse.dll?

from modelica_devicedrivers.

The most simple way to solve that seems to change the static library target into a DLL target.
The drawback is, that in this case the simulation binaries generated by Dymola get a dependency to the DLL and can't be used as convenient as "standalone" executables.
However, I'll change it in a moment and we will see if this could be at least a preliminary solution.

from modelica_devicedrivers.

But this is not different to SoftingCAN where there is and was a dependency to canL2.dll.

from modelica_devicedrivers.

That's true, but I didn't like it either. In the canL2.dll case it is inevitable, since the DLL comes from a third party that just doesn't distribute a static lib version.
The Modelica_DeviceDrivers library is quite popular at our institute to build up interactive simulations for demonstation purposes. In that case people just want to create an executable and start it without needing to start Dymola. Dependencies to DLLs make this procedure a bit more complicated for users and also less robust. Just imagine that the demonstrator executable uses another DLL version when the development PC: this can lead to hard to find bugs ...

from modelica_devicedrivers.

Thanks. Very nice. Do you plan to re-integrate dllwrapper to master again and make a new release version?

from modelica_devicedrivers.

As a compromise: You could add a static lib MDDSpaceMouse.lib (like you had before) and a dll MDDSpaceMouse.dll. Luckily there is no dependency on ModelicaExternalC. SimulationX solvers do not require the static lib since it calls LoadLibrary on the dll file. This way of providing external librararies is already tested.

Maybe we should rename ModelicaDeviceDrivers in the library names to MDD, e.g. ITI_MDD.dll (to make it short and consistent).

from modelica_devicedrivers.

You could delete the four lib files ITI_*.lib thar are not required by SimulationX. SimulationX built-in and external solvers use the DLL files and SimulationX external C code feature is able to use the source code.

from modelica_devicedrivers.

• I implemented your proposal to have a static lib and a DLL for MDDSpaceMouse. This is a very nice compromise and I hope it works (no possibilities to test it in the moment).
• I also like the proposal to shorten the names and implemented it.
• I merged the dllwrapper to master again.

In any case, I need to check if things still work well in Dymola before cutting a new release. I may have the chance to do that at Thursday (need the hardware to test).

If in addition you could confirm me that things work for SimulationX, this would be really cool and warrant a new release!

from modelica_devicedrivers.

And another important point before a new release:

• I'd like to give a statement / link about the license of the ITI ModelicaExternalC.lib
  It does not necessarily need to be Modelica License 2, but at least there need to be a clear written statement that it is OK to distribute the ModelicaExternalC.lib binary together with the MDD library, etc.

from modelica_devicedrivers.

I asked ITI's SW Manager who told me that (binary) ModelicaExternalC.lib is public domain.

from modelica_devicedrivers.

About SimulationX:

• Everything that is based on Blocks.Packaging.SerialPackager is currently not working in SimulationX 3.6. There is some destructor called too early.
• InputDevices is working as expected.

from modelica_devicedrivers.

Do you mind if I provide a VS 2010 project file for ITI_ModelicaDeviceDrivers? I do not have/use Cmake and VS makes debugging pretty simple.

from modelica_devicedrivers.

ITI_MDD.dll needs to export function MDD_utilitiesLoadRealParameter which is currently missing,

from modelica_devicedrivers.

Regarding VS 2010. You can use Cmake to generate VS project/solution files (that is what I do). These files can be opened with VS and debugging can be done as usual.
Of course, using Cmake is basically a matter of taste. I like to have the build logic for Windows and for Linux at one place and thus there is no "redundant" support of two build systems.

Having both, Cmake and VS 2010 in one project seems a bit odd. Maybe you can give it a try to use Cmake to generate a VS project for MDD and see if it works for you?

from modelica_devicedrivers.

OK, did not know that cmake generates VS project files. Thanks.

You might delete the dllwrapper branch since it is merged and no longer maintained.

from modelica_devicedrivers.

I guess this can be closed.

from modelica_devicedrivers.

Alright, does that mean that we can state now that Modelica_DeviceDrivers works also with SimulationX? And if so, with which version?

from modelica_devicedrivers.

Except the above mentioned problem of Blocks.Packaging.SerialPackager. But this is nothing I can do.

from modelica_devicedrivers.