modelica-3rdparty / modelica_devicedrivers Goto Github PK

Support of SimulationX built-in simulation requires a vendor specific annotation in case of a missing Library annotation for external functions.

This is OK:

  encapsulated function write
    import Modelica_DeviceDrivers.Communication.SharedMemory;
    input SharedMemory sm;
    input String data;
    input Integer len;
    external "C" MDD_SharedMemoryWrite(sm,data,len)
    annotation(IncludeDirectory="modelica://Modelica_DeviceDrivers/Resources/Include",
           Include = "#include \"MDDSharedMemory.h\" ",
           Library = "rt");
  end write;

But this needs to be changed from

  encapsulated function getDataSize
    import Modelica_DeviceDrivers.Communication.SharedMemory;
    input SharedMemory sm;
    output Integer length;
    external "C" length=  MDD_SharedMemoryGetDataSize(sm)
    annotation(IncludeDirectory="modelica://Modelica_DeviceDrivers/Resources/Include",
           Include = "#include \"MDDSharedMemory.h\" ");
  end getDataSize;

to either

  encapsulated function getDataSize
    import Modelica_DeviceDrivers.Communication.SharedMemory;
    input SharedMemory sm;
    output Integer length;
    external "C" length=  MDD_SharedMemoryGetDataSize(sm)
    annotation(IncludeDirectory="modelica://Modelica_DeviceDrivers/Resources/Include",
           Include = "#include \"MDDSharedMemory.h\" ",
           __iti_dll = "rt.dll");
  end getDataSize;

or

  encapsulated function getDataSize
    import Modelica_DeviceDrivers.Communication.SharedMemory;
    input SharedMemory sm;
    output Integer length;
    external "C" length=  MDD_SharedMemoryGetDataSize(sm)
    annotation(IncludeDirectory="modelica://Modelica_DeviceDrivers/Resources/Include",
           Include = "#include \"MDDSharedMemory.h\" ",
           Library = "rt");
  end getDataSize;

If wanted I can send pull request on it. Please comment.

Is it right to have the header files licensed under Modelica License 2? Usually only the Modelica files of a package use Modelica License 2 whereas C source and header files use some more appropriate license like BSD3.

As written in c273fe6 I noticed that most of the communication example models are awkward due to the missing I/O causality of the communication source and sink block being both in the same model. Thus it is not defined if a source reads the data from the current or the previous sample step.

This can be solved if the source blocks get some kind of causality input (which would be the pkgIn.dummy of the corresponding sink block). Shall we do this? @bernhard-thiele Please advise if I can do it.

By the way, if I remember correctly TLC (code generation from Simulink models) has some strategy to send as early as possible and to read as late as possible.

@tbellmann: Can you please verify that recent M_DD v1.4.2 works on DLR together with SimVis? Otherwise there might be need to add some defines in same way as DLR-SR/Noise#34 (comment) for the C code of the Noise lib.

@MartinOtter: For reference.

The documentation string of package Utilities reads This package contains auxiliary packages and elements to be used in context with the PowerTrain library. Really?

Windows compilation is restricted to MSVC. It should be straight forward to relax Windows compilation to also support MinGW and Cygwin.

There is a comment @TODO Not sure whether memcpy to data is possible in external Modelica functions. Check. on function MDD_socketCANRead in MDDSocketCAN.h. According to the Modelica Language Specification (MLS) input arguments of type String map to const char* C type. If doing so the memcpy operation is no longer legal. New memory for the return buffer needs to be allocated by the ModelicaAllocateString function. See also c94ae5c for #23 and #27 where it was fixed for MDDSoftingCAN.h.

My branch add-TCP/IP-support at tbeu/Modelica_DeviceDrivers contains a not yet final implementation of a TCP/IP socket client (for Windows).
@bernhard-thiele Can you please test and estimate if you want to have this in the library? In Incubate?

I just noticed that the changes of #10 result in error when trying to compile on my windows machine:
16>C:\Program Files (x86)\Microsoft Visual Studio 10.0\VC\include\ctype.h(41): error C2485: '__declspec': nicht erkanntes erweitertes Attribut
16>C:\Program Files (x86)\Microsoft Visual Studio 10.0\VC\include\ctype.h(41): error C2059: Syntaxfehler: '('

Reverting to the version before the fix, fixes the bug for me.
@tbeu Since I don't work so much with Windows and Visual Studio I wonder if you have any comments on that. For the moment, I'm going to revert this change.

Two questions on MDD_udpReceivingThread of MDDUDPSocket.h.

1. Why are there two different functions MDD_udpReceivingThread?
2. Is it really necessary to have DllExport on first function MDD_udpReceivingThread? It is not referenced from Modelica files.

There actually is no need to have sampled RNG in Blocks.OperatingSystem.RandomRealSource. I propose to add a conditional external trigger port for the block. In case this trigger is off the RNG should happen in every step (which matches also the block icon). Do you agree?

I stumbled accross the following lines in the add and get functions of the SerialPackager, e.g.

    when pkgIn.trigger then
      pkgOut.dummy =
        Modelica_DeviceDrivers.Blocks.Packaging.SerialPackager.Internal.DummyFunctions.addRealAsFloat(
          pkgOut.pkg,
          u,
          pkgIn.dummy,
          byteOrder);
    end when;

addRealAsFloat takes a scalar SerialPackager as first argument and returns a scalar Real variable. However pkgOut is not a scalar PackageOut connector but of dimension nu.

What is the reason of having nu in PartialSerialPackager?

There are 5 occurences like caller_function=="CANL2_write_signals" that compare a string literal with a pointer variable in MDDSoftingCAN.h. Did you intend to use strcmp() instead?

Branch release has different directory structure (with top level directory Modelica_DeviceDrivers 1.2) than branches master or dllwrapper. This is not compatible when switching branches.

I propose to also add this top level directory (available with release branch) to other branches.

Customer uses UDPSend to send data (double, float, int32) to external tool. He noticed that only little endian is supported whereas external tool expects big endian.
It would be nice if byte order layout could be chosen in UDP (and similar) blocks. Or should it go to Packager or Add/Get blocks? I can do it but would like to know where it belongs best?
@bernhard-thiele Please advice quickly since customer askes for it.

Can't be added to this repo, because my newly created account can't be found.

MDD_realtimeSynchronize uses static variables which is no good programming since it is not thread-safe. Therefore it would be better to implement Modelica_DeviceDrivers.Blocks.OperatingSystem.SynchronizeRealtime as an external object.

The package icon of Modelica_DeviceDrivers.Blocks looks old-style compared to all other icons visible in the library browser. Should the icon of Modelica.Blocks be reused here?

As @sjoelund reported: External objects are not allowed in records

[HardwareIO.mo:9:5-31:21:writable] Error: Ignoring record component:
  ExternalObject Modelica_DeviceDrivers.HardwareIO.Comedi dh;
when building record the constructor. Records are allowed to contain only components of basic types, arrays of basic types or other records.

Modelica_DeviceDrivers\Resources\Library\win64\ITI_MDDSoftingCAN.dll links against Debug Version of MSVC runtime (MSVCR100D.dll). Please adapt to use release version.

See title. Could be

parameter Integer n=1 "Package size";

Bernhard, can you please rebuild and update the binaries of the master branch. Thank you.

I almost forgot this one to report: I installed CAN Layer2 V5.17 where in CANL2.H the struct CANL2_CH_STRUCT is commented out:

/*
typedef struct canl2_ch_s {
    CAN_HANDLE     ulChannelHandle;
    unsigned char  sChannelName[80];
} CANL2_CH_STRUCT;
*/

However, CANL2_CH_STRUCT is referenced by MDDSoftingCAN.h.

I propose to define and use an own struct based on the commented type.

Do you know the UDPLib?

Some commercial tool are only available as 32-bit application for Linux. Also the compilation of the simulation binary is done for 32-bit. Consequently, system libraries required by some devices need to be available as 32-bit libraries in these cases. This is sometimes a difficulty for users to figure out.

Notably, the keyboard interface needs the X11 library, and it must be available as 32-bit version if compilation is done for 32-bit.

Might think of writing a guide for a specific combination of tool and linux distribution (e.g., Dymola + Ubuntu).

In the documentation users are pointed to the Modelica Trac issue tracker instead of the GitHub one. Wouldn't it be better to point them to GitHub instead?

The libraryinfo.mos file says version 1.2 and MSL version 3.2. Should this be updated?

Any plans to release a new version? v1.3 was released one year ago and many fixes where added since then.

I also propose to switch to semantic versioning, i.e. 1.4.0 would be a proper name according to https://github.com/mojombo/semver.

Translation of Modelica_DeviceDrivers.Blocks.Examples.TestSerialPackager_UDP:

The DAE has 102 scalar unknowns and 102 scalar equations.

The initial conditions for variables of type Real are not fully specified.
Dymola has selected default initial conditions.

Assuming fixed default start value for the discrete states:
getFloat.y[1](start = 0.0)
getFloat.y[2](start = 0.0)
getReal.y[1](start = 0.0)
getReal.y[2](start = 0.0)
getReal.y[3](start = 0.0)

The initial conditions for variables of type Integer are not fully specified.
Dymola has selected default initial conditions.

Assuming fixed default start value for the discrete states:
getInteger.y[1](start = 0)

Statistics

Original Model
Number of components: 33
Variables: 137
Parameters: 31 (31 scalars)
Unknowns: 106 (112 scalars)
Equations: 47
Nontrivial: 47

Translated Model
Constants: 30 scalars
Free parameters: 18 scalars
Parameter depending: 23 scalars
Time-varying variables: 26 scalars
Alias variables: 46 scalars
Assumed default initial conditions: 6
Number of mixed real/discrete systems of equations: 0
Sizes of linear systems of equations: { }
Sizes after manipulation of the linear systems: { }
Sizes of nonlinear systems of equations: { }
Sizes after manipulation of the nonlinear systems: { }
Number of numerical Jacobians: 0

Selected continuous time states

Finished

// experiment StopTime=5 StartTime=0

WARNING: 2 warnings were issued

Finished

Should this be fixed in the Get blocks or in the example model?

What is the schedule for a new version?

Dialog annotation

input String data = "A mostly harmless String" annotation(Dialog=true);

is invalid according to MLS 3.3 rev 1 section 18.7. Should it be one of the following ones?

input String data = "A mostly harmless String" annotation(Dialog(enable=true));

or

input String data = "A mostly harmless String" annotation(Dialog);

According to the Modelica Language Specification chapter 12.9.4 the annotations for external libraries and include files should be placed on the external function declaration (and not on the Modelica function).
So instead of

encapsulated function constructor "Claim the memory"
    import Modelica_DeviceDrivers.Packaging.SerialPackager;
  input Integer bufferSize = 16 * 1024;
  output SerialPackager pkg;
  external "C" pkg = MDD_SerialPackagerConstructor(bufferSize);
  annotation(IncludeDirectory="modelica://Modelica_DeviceDrivers/Resources/Include",
             Include = "#include \"MDDSerialPackager.h\" ");
end constructor;

better have

encapsulated function constructor "Claim the memory"
  import Modelica_DeviceDrivers.Packaging.SerialPackager;
  input Integer bufferSize = 16 * 1024;
  output SerialPackager pkg;
  external "C" pkg = MDD_SerialPackagerConstructor(bufferSize)
    annotation(IncludeDirectory="modelica://Modelica_DeviceDrivers/Resources/Include",
               Include = "#include \"MDDSerialPackager.h\" ");
end constructor;

Note the missing semicolon after the external function declaration.

In the Library include files we find includes like this

#include "ModelicaUtilities.h"
#include "../src/include/CompatibilityDefs.h"

in case of MSVC. But ModelicaUtilities.h is located in same directory as CompatibilityDefs.h is. Thus ModelicaUtilities.h is not found without explicitly adding src/include to the include path. Thus I propose to get either rid of the extra src/include directory by adding all files to the main Include directory. Or alternetively the include directives should be made consistent.

Currently the communication is cyclic only.

Proposal: This is taken from a trigger type implementation we once did for CAN and where more trigger options are available.

type trigger_type=enumeration(
  event_trig "Event",
  cyclic_trig "Cyclic",
  cyclic_event_trig "Cyclic + Event",
  initial_trig "At Start only",
  terminal_trig "At Stop only") "Use as trigger";

I tried to connect arduino uno board with Openmodelica and Modelica_DeviceDrivers ,but couldn't succeed.Could you plz how to perform the communication between Openmodelica and arduino by using Modelica_DeviceDrivers package.

Function setProcessPriority is only called at the start of the simulation but not reset at the end of the simulation.

Also it would be nice if there would be an option to not set the process priority in Modelica_DeviceDrivers.Blocks.OperatingSystem.SynchronizeRealtime.

Apply the following patch to the master branch

 Modelica_DeviceDrivers/Blocks/Interfaces.mo | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/Modelica_DeviceDrivers/Blocks/Interfaces.mo b/Modelica_DeviceDrivers/Blocks/Interfaces.mo
index 76705ef..d667751 100644
--- a/Modelica_DeviceDrivers/Blocks/Interfaces.mo
+++ b/Modelica_DeviceDrivers/Blocks/Interfaces.mo
@@ -5,7 +5,7 @@ package Interfaces
   connector PackageIn "Packager input connector"
     input Modelica_DeviceDrivers.Packaging.SerialPackager pkg;
     input Boolean trigger;
-    input Real dummy;
+    discrete input Real dummy;

     output Boolean backwardTrigger;
     output Integer userPkgBitSize;
@@ -27,7 +27,7 @@ package Interfaces
   connector PackageOut "Packager output connector"
     output Modelica_DeviceDrivers.Packaging.SerialPackager pkg;
     output Boolean trigger;
-    output Real dummy;
+    discrete output Real dummy;

     input Boolean backwardTrigger;
     input Integer userPkgBitSize;

Now Dymola 2016 raises the following translation error on Modelica_DeviceDrivers.Blocks.Examples.TestSerialPackager_UDP which I do not understand.

The following real variables are declared with the prefix discrete,
but are not assigned in a when-clause, either by an assignment or an equation:
addFloat.pkgIn.dummy
addInteger.pkgIn.dummy
addReal.pkgIn.dummy
getFloat.pkgIn.dummy
getInteger.pkgIn.dummy
getReal.pkgIn.dummy
uDPSend.pkgIn.dummy

The released version v1.1 contains lots of HTML errors.
https://gist.github.com/dietmarw/c4dc5629e581702eb2d1

In addition are links to images or other packages are pointing to the wrong place (looks like the URL was typed incorrectly):

[Checking file /home/dietmarw/.workspace/gh-modelica/Modelica_DeviceDrivers/Resources/help/Modelica_DeviceDrivers.Blocks.Packaging.SerialPackager.UnpackUnsignedInteger.html]:
Not found: Modelica_DeviceDrivers.Blocks.Examples.TestSerialPackagerBitUnpack_UDP.html
[Checking file /home/dietmarw/.workspace/gh-modelica/Modelica_DeviceDrivers/Resources/help/Modelica_DeviceDrivers.UsersGuide.html]:
Not found: Modelica_DeviceDrivers.UsersGuide.Literature.html
[Checking file /home/dietmarw/.workspace/gh-modelica/Modelica_DeviceDrivers/Resources/help/Modelica_DeviceDrivers.Utilities.Icons.InternalPackage.html]:
Not found: ../Extras/Images/dlr_logo.png
[Checking file /home/dietmarw/.workspace/gh-modelica/Modelica_DeviceDrivers/Resources/help/Modelica_DeviceDrivers.Utilities.Icons.html]:
Not found: ../Extras/Images/dlr_logo.png

I edited the description from

Free (standard conform) library for interfacing hardware drivers to Modelica models. There is support for joysticks, keyboards, UDP, shared memory, AD/DA converters and other devices.

to

Free library for interfacing hardware drivers to Modelica models. There is support for joysticks, keyboards, UDP, shared memory, AD/DA converters and other devices.

thus deleting the "standard conform" which is misleading and simply does not hold as long as #1669 (= first issue of #54) and #71 aren't resolved. Once they are properly fixed it could be reverted.

There was a discussion at modelica-3rdparty/msgpack-modelica#6 if binaries belong to the the repository. The conclusion was to remove the binaries from version control and create/provide a download version upon release. (See also https://github.com/blog/1547-release-your-software where the binary assets are explicitly mentioned.). See https://github.com/sjoelund/msgpack-modelica/releases for an idea.

CompatibilityDefs.h includes winsock2.h for MSVC build. This breaks the compilation.

TestInputKeyboardKey.c
C:\Program Files\Microsoft SDKs\Windows\v7.1\Include\ws2def.h(91) : warning C4005: 'AF_IPX' : macro redefinition
        C:\Program Files\Microsoft SDKs\Windows\v7.1\Include\winsock.h(460) : see previous definition of 'AF_IPX'
C:\Program Files\Microsoft SDKs\Windows\v7.1\Include\ws2def.h(131) : warning C4005: 'AF_MAX' : macro redefinition
        C:\Program Files\Microsoft SDKs\Windows\v7.1\Include\winsock.h(479) : see previous definition of 'AF_MAX'
C:\Program Files\Microsoft SDKs\Windows\v7.1\Include\ws2def.h(168) : warning C4005: 'SO_DONTLINGER' : macro redefinition
        C:\Program Files\Microsoft SDKs\Windows\v7.1\Include\winsock.h(402) : see previous definition of 'SO_DONTLINGER'
C:\Program Files\Microsoft SDKs\Windows\v7.1\Include\ws2def.h(212) : error C2011: 'sockaddr' : 'struct' type redefinition
...
NMAKE : fatal error U1077: '"C:\Program Files (x86)\Microsoft Visual Studio 9.0\VC\bin\cl.EXE"' : return code '0x2'

The issue can be resolved if

• winsock2.h is not included in CompatibilityDefs.h
• MDDSharedMemory.h also includes Windows.h
• MDDUDPSocket.h includes Windows.h instead of winsock2.h

I recommend to remove the whole MSVC compatibility block as it is actually not needed.

There is Library={"canL2"} set to the annotation of the external functions of the Communication.SoftingCAN. However, canL2.lib and canL2.dll are not available for 64-bit simulation tools where the appropriate Softing lib is named canL2_64.

Customer asked for UDP support in SimulationX. Thus I tried to figure out why SerialPackager fails in SimulationX. The reason is that the external objects, i.e. there constructors are used in assignments which is illegal according to the MLS 3.3 (rev 1) section 12.9.7: "Only the constructor may return external objects and external object can only be bound in component declarations and neither modified later nor assigned to."
Thus the current design of the SerialPackager and the Communication package is bad in two ways 😒

1. External objects in connectors are not legal since the connect statement is equivalent to an assignment equation.
2. Constructing the external object in when initial() is not legal at all.

Whereas SimulationX is tolerant with the first problem the second problem is a really bad design failure. I changed the construction of the external object from something like

model Packager
  Interfaces.PackageOut pkgOut;
  protected
    Integer bufferSize;
  equation
    when initial() then
      bufferSize = something;
      pkgOut.pkg = SerialPackager(bufferSize); // create external object here
    end when;
end Packager;

to

model Packager
  Interfaces.PackageOut pkgOut(pkg = SerialPackager(bufferSize));
  protected
    Integer bufferSize;
  equation
    when initial() then
      bufferSize = something;
    end when;
end Packager;

which still violates the first problem but could fix the second one. However, this now reveals the bad design of the auto propagation of the buffer size. It is not clear which external object defines the auto buffer size and which external object uses the derived buffer size.

In the need for a quick fix for the second problem I would consider to either use a fixed buffer size or refer to some global parameters like e.g. Modelica.Mechanics.MultiBody.World of the MSL holds.

@bernhard-thiele, @MartinOtter What do you think? Can we find a workaround in order to get the customer project running soon? Do you have other ideas to fix the second problem (or even the first problem to make the library really standard conform)? I am willing to contribute of course.

It is

DWORD WINAPI MDD_udpReceivingThread(LPVOID pUdp);

but MDD_udpReceivingThread does not return any value.

In Softing's download center I can see a "CAN-AC PCI V5.18 Driver for Linux Kernel 3.2 (Kubuntu 12.04 LTS)". Does this mean that SoftingCAN could be ported to Linux?

Linux implementation of MDD_joystickGetData uses static variables and never frees allocated memory for axis and button arrays. It should be turned into an external object.

Copyright notice still states 2012.

DllExport in CompatibilityDefs.h is always defined no matter if the project is compiled as DLL or EXE. I propose to add a new macro MDD_EXPORTS that needs to be actively set if MDD is compiled as dynamic library, i.e. MDD_EXPORTS has to be set in the cmake build script / VS project.

It looks like MDDSpaceMouse.lib is (and also previously was) compiled with /MD. If I am not wrong Dymola takes /MT as default. Please check and test.

TestInputSpaceMouse.c
MSVCRT.lib(MSVCR90.dll) : error LNK2005: _free already defined in LIBCMT.lib(free.obj)
MSVCRT.lib(MSVCR90.dll) : error LNK2005: _malloc already defined in LIBCMT.lib(malloc.obj)
   Creating library TestInputSpaceMouse.lib and object TestInputSpaceMouse.exp
LINK : warning LNK4098: defaultlib 'MSVCRT' conflicts with use of other libs; use /NODEFAULTLIB:library
TestInputSpaceMouse.exe : fatal error LNK1169: one or more multiply defined symbols found
NMAKE : fatal error U1077: '"C:\Program Files (x86)\Microsoft Visual Studio 9.0\VC\bin\link.EXE"' : return code '0x491'
Stop.

MDD_softingCANReadRcvData(..) needs to get revised in order to make it Modelica compliant (see Issue #23)