OpenModelica System Documentation is OpenModelicaUsersGuide.pdf. It's included in your installation of OpenModelica. If the chapter does not exist in it, you probably don't have a recent enough version of OpenModelica installed (it's a new library).
You can read the latest version of the documentation from http://openmodelica.org/svn/OpenModelica/trunk/doc/ (user/pass from http://www.openmodelica.org/index.php/d … rce-code).

Sending data to a device should be done analogous to acquiring data.
For example you create:
data = readData() and writeData() functions or a single function dataToReceive = readWriteData(dataToSend)
The second is probably easier since Modelica doesn't allow function calls without return value in when-equations.

Anyway, I changed the runtime to use the architecture specified by CFLAGS.
If you want to test it, the build should be generated at 11:30 Paris time assuming nothing is broken.

It might be that it's using SSE2, but any semi-modern machine has access to it. The simulation runtime does not look at CFLAGS from the configure script, but only the CPU that the system is running on. So it always builds with -msse2...

What is your "uname -m" output?

Hmmm... what version of omc are you running (apt-cache show omc)?

You could probably also provide better information by running gdb:
gdb ./BouncingBall
> run
< Program stopped. Illegal instruction
> bt
< GDB shows a backtrace

If you run the executable manually, what does it say? And what does output.log contain (should be the executable output when called from simulate()).

Yes. Since you cannot match with guards in MetaModelica, you need to break the loop like that.

No. That's what I was referring to earlier. It will always evaluate both branches of the if-expression, which means you can't use it to break loops (it will try the other branch anyway).

Instead, start two cases like this:

case (_, (dep::lst_1), _) 

      equation

         true = inInteger == counter;

case (_, (dep::lst_1), _) 

      equation

         false = inInteger == counter;

And if you have trouble getting the exercises running, updated ones exist in subversion (trunk/testsuite/meta/MetaModelicaDev/).

OpenModelicaMetaProgramming.pdf is the only document I know of. It covers the language, but the RML implementation is sometimes a bit different. For example the document states that listGet() is indexed from 1, but in RML MetaModelica we instead have listNth(), which is indexed from 0.

The appendix has both grammar and the builtin functions.

if ... then ... else ... does not exist in RML MetaModelica. You can use Util.if_(cond, if_exp, else_exp), but it always evaluates both expressions.

Not much support for Modelica.Media (that is to say: nothing works). This release is more focused on Modelica.Mechanics.MultiBody (which flattens code but can not yet simulate all models).

Still... The actual code failing is:

file = fopen(filename,"w");

  if (file == NULL) {

    char *c_tokens[1]={filename};

    c_add_message(21, /* WRITING_FILE_ERROR */

      "SCRIPTING",

      "ERROR",

      "Error writing to file %s.",

      c_tokens,

      1);

    RML_TAILCALLK(rmlFC);

  }

So it really can't open files for writing in that directory. Can you manually create a new file (touch abc.txt) in that directory? Does root own some of the files that omc tries to overwrite?

The double slashes are not a problem. I have them myself.

/usr/share/doc/omc/testmodels$ omc +showErrorMessages +d=failtrace

There's your problem. You do not have write rights to /usr/share/doc/omc. Only root does. OpenModelica really should put all files in a temp directory instead, but that's for the future
Swedish locale settings also use comma, and most of the developers are from there so I expect that's not the issue here.

Why you have the same problem in XP I don't know though. Maybe you installed OpenModelica in a path containing a space.

If copying the testmodels to a directory you can write to does not solve the issue, use the command checkSettings() in OMShell and paste the result.

It's certainly possible.

Reading a sensor would require an external function (probably C). See chapter 9 in Fritzson's book or chapter 12 in the Modelica Language Specification 3.2.

I would suggest that you use sampling to synchronize the input/output calls, as you probably want to take simulations steps more often than you sample the sensor.

Using SimForge should probably be fine, but if you want real-time capabilities you might want to read chapter 6 of the OpenModelica System Documentation - Interactive Simulation Facilities. I suspect that's simpler than making the DAQ functions synchronize the clock, but it can't be used within SimForge yet from what I understand. I might be wrong though

Nothing is wrong with the code. OpenModelica just has problems with counting equations for array assignments in algorithm sections.

Works on my Ubuntu machine now. Let's hope my script won't rebuild packages that already exist and thus change checksums again...

Bah, I'll fix the script and post an update when I get a hold of a Linux machine. It might be working now since I cleared the apt-ftparchive cache.

Try updating and install again. I switched the makefile to use relative paths instead (I guess when I tested it on my machine, the files were already cached and never actually downloaded from server).

The 1.5.0 release should be once the documentation has been updated, hopefully this week.

https://openmodelica.org/index.php/deve … ource-code - check out a version and read the instructions on how to compile it (README-OMDev-MINGW.txt). Or wait a few days and hope Adrian has pushed a new OpenModelica release.

There is no Windows binary release after RC3 (the Linux one is from May14 though).
The source in the subversion trunk is always up to date.

Ah. RC3 is from April 22. Jens Frenkel fixed derivative annotations after that release.

What version of OpenModelica are you using? The code runs fine in the trunk.

1. You create a .so or .a file. GCC will link using -lpackageName, so if you use annotation Library="abc", you should name your file libabc.a or libabc.so. The file should be on the linker path (same directory as the model, or /usr/local/lib for example).
2. There is no files required to call the external FORTRAN file, but you need to compile it before simulation.
3. Which examples? The examples directory doesn't contain the string FORTRAN anywhere.

From testsuite/mofiles/ExternalFunction4.mo (testcase based on MSL 2.2):

function dgetri
  input Real LU[:,size(LU,1)];
  input Integer pivots[size(LU,1)];
  output Real inv[size(LU,1),size(LU,2)]=LU;
protected
  Integer lwork=min(10,size(LU,1))*size(LU,1);
  Real work[lwork];
  Integer info;
  external "FORTRAN 77" dgetri(size(LU,1),inv,size(LU,1),pivots,work,lwork,info) annotation (Library="Lapack");
end dgetri;

Did you load MSL first?

loadModel(Modelica)

Make sure that the loadModel() and loadFile() commands both return true. Note that the testmodels is installed into /usr/share/doc/omc/testmodels/dcmotor.mo on Linux.

Look into the Modelica standard library: Modelica.Blocks.Sources.Pulse

nhuytan wrote:

i can not verify username and password .

http://www.openmodelica.org/index.php/d … ource-code

You used a command simulate(... stopTime = 100 ...) it seems. Simply change that to 400.

I tried to change the problem a bit, but it only worked using pre(x) in the when-equations. But that changes its semantics a lot.
I opened up a bug report for this as I have had similar problems in the past: https://openmodelica.org:8443/cb/issue/ … ation=true

For me, the first one succeeds and the second one fails.
If I make M,m and D constant, it succeeds. So something in initialization seems to go wrong. Note that using simulate(rocket, method = "euler") works fine regardless.

It all depends on the license used by external code:
For example, if you use annotation(Library = {"myLibrary", "someGPLLib"}) your model needs to be GPL (but not necessarily myLibrary).
If you use annotation(Library = {"myLibrary"}) , your model AND your library needs to be GPL if and only if myLibrary links to GPL code.

So if you write the model and the library yourself, you're good.

In Java, varargs is an array of objects. I'm 100% sure our external Java interface does not handle that; the signatures will be wrong.

I have one little suggestion regarding a generic interface though: Passing strings. It's slow, but should work.
PythonInterface.callReal("myPythonFunction(" + PythonInterface.realArrayToString(arg1) + ")")

You need to create one "call" function for every return type you want to have anyway, but you can have varargs.

If you use a GPL library in your model, your whole model is a work based on that library and needs to be published as GPL (but only if you distribute it to others; GPL says it's fine for internal use).
If you use LGPL libraries (which many of them are), you only have to publish your modifications of the library as GPL.

./rocket
DASSL--  AT T (=R1) SOME ELEMENT OF WT
      In above message,  R1 =   .2220446049250E-15
DASSL--  HAS BECOME .LE. 0.0
Error, simulation stopped at time: 2.22045e-16 with idid: -3


It's simple. It can't solve the equation because you made it unsolvable. You set x(start = 0), which means for the first steps:
der(y)*((D-x)^2)*x =  (-1)*G*M*((D-x)^2) + G*m*x ;
der(y)*((D-0)^2)*0 =  (-1)*G*M*((D-0)^2) + G*m*0 ;
0 = -5.8874703126643202e+29

Clearly you can't solve this.

There is no way to have a varargs-style function in Modelica. And there may be problems calling C++ functions as well (external C is pure C; no overloaded functions).

If you execute your PHP application and it sets an environment variable, like OPENMODELICAHOME, it should not be set in the terminal.
The new Linux releases don't even use omc-start script. http://openmodelica.org/index.php/downl … load-linux

They simply set OPENMODELICAHOME in /etc/profile.d/ so you that the environment is properly setup.

You could either use the Java interface (modelica_java.jar, distributed with OpenModelica). There are examples on how to use it in the testsuite:
http://openmodelica.org/svn/OpenModelic … uite/java/

Else you could connect directly using CORBA (since the java interface doesn't contain special functions for simulate(), etc anyway). There is an example on how to do that in the testsuite (which modelica_java.jar is based on):
http://openmodelica.org/svn/OpenModelic … _advanced/

Use external C functions:
Described in Peter Fritzson's book, section 9.4.
Or http://www.modelica.org/documents/ModelicaSpec32.pdf section 12.9 (and 12.9.7 for external objects if using those is simpler for you).

You can either declare it as parameter and read an array that you use in the simulation. Or open a file and read more data during some samples; depends on the problem.

Defining what OpenModelica supports or not is complicated, because everything is divided into frontend and backend. We can flatten most code since the people funding the project think that's most important (but this means we can't simulate all code we support).
You could try looking in: http://openmodelica.org/svn/OpenModelic … istration/ (login using the subversion password http://www.openmodelica.org/index.php/d … rce-code).
The simple answer is: Modelica.Media, Multibody 3.1, Multibody 2.2, enumerations have the poorest support.

As for SimForge, I think you're on the right track but since I find command-line OpenModelica works better, I'm not really qualified to answer questions regarding graphical model editors.

There is no correct way to use Modelica.Fluid in OpenModelica as it doesn't yet support the whole of Modelica.Media.
As for SimForge, I have no clue

I know how to generate flattened code, but nothing about stateselect:

If you run omc from a terminal, simply give it a mo-file as argument and it will flatten it.
If you run omc through OMShell, call instantiateModel(className).

./rocket
DASSL--  AT T (=R1) SOME ELEMENT OF WT
      In above message,  R1 =   .2220446049250E-15
DASSL--  HAS BECOME .LE. 0.0
Error, simulation stopped at time: 2.22045e-16 with idid: -3
Result written to file.

Modelica can't give you an analytical solution.
You need to specify what x is (add x = time for example).

Yes, it should work. I added a bug report for this: https://openmodelica.org:8443/cb/issue/ … ation=true

Modelica.Interfaces.InPort was part of Modelica Standard Library 1.6 but never any later version of the library.
So it's possible some parts of ModelicaAdditions won't work.

That probably means you are missing a newline before the simulate command?

Unix doesn't do COM Objects
There are more ways to get simulation data though. But reading the file is probably easiest; else you could always convert it to gnuplot with a python-script and let gnuplot output the image

While trying to reproduce your problem I came up with something like:

function takesMatrix
  input Real[:,:] myInput;
  output Real out;
algorithm
  out := 3.0;
end takesMatrix;

class MX
  constant Real[:,:] mx = {{1.0,5.0},{2.0,6.0},{3.0,7.0},{4.0,8.0}};
  Real r = takesMatrix({{time,mx[1,2]},mx[2,:]});
end MX;


It doesn't give the same kind of error message, but your also has to do with matrices
MX.cpp:367: error: ‘$mx$lB2$c1$rB’ was not declared in this scope

Mine were constant though. I have no clue how you got evaluated constants into the code... Anyway, if that constant is no longer constant... It should start working. And that's probably the bug introduced.

Ooops... It seems I read the error message a bit too fast... I thought it was line 477 that was weird... But 483 is 6 lines below that. Quite a bit.

I probably need to check the generated C-code to see what's wrong.

Sort of. You can start the interactive session before you start OMShell, and then OMShell will use that session instead.

$ omc +d=interactiveCorba,failtrace +showErrorMessages

Then start OMShell and type something silly like a+b into the prompt and see some error messages in your console.

I've seen the following used before:

package myAlmostEnum
  constant Integer a = 1;
  constant Integer b = 2;
  constant Integer c = 3;
  constant Integer d = 4;
  constant Integer e = 5;
  constant Integer f = 6;
  constant Integer numberOfElements = 6;
end myAlmostEnum;

Actually, it seems like the index becomes an integer. It works if you remove the call to Integer()... Really weird. For-loops don't work properly with enumerations. Or something like that.

Ah... The first error message is:
Error: Variable labels not found in scope C.find

And enumerations are weird in OpenModelica. It really should work, and I know Per has been poking around with enumerations the last week.

class A

  type T = Integer;

  function find

    input T t1;

    output T t2 = t1;

  end find;

  T t1 = find(1);

end A;

Seems to work fine. The types do exist.

However, that error messages can sometimes be bad:
* Either it failed to create a record constructor. Then it will say this type exists, etc...
* Or it fails to instantiate the function.

Run omc with +d=failtrace to see what weird things fails.

Could you provide the Modelica function header of the code that fails?
Algorithm section not important.

Well, it's not a solver problem. It's more of a problem with Modelica events (if an event is triggered, you can't take a larger timestep).

One way to solve it would be to use a different kind of controller. I'm not a modeller myself, so I wouldn't know what kind to use though (discrete PI or PID comes to mind; we have some testcases that use those in the testsuite).

I will give you an implementation hint:
when sample(0.0,0.1) then ... will only trigger events every 0.1 seconds. So if you only check the velocity during these samples, you will ensure 0.1 seconds of engine-off state.
It also models real-life systems a lot better, since we tend to sample at given intervals and not infinitely small intervals

I think the problem is that you give the train 0 power when it is higher than the limit. When you do that, its speed instantly drops. This means it will then give full throttle in the next timestep, because its speed is now lower than the limit. This means that it will again be higher than the limit and trigger an event.
The result is a stiff system, that will basically take forever to solve.

I checked the deb file today and /usr/bin/omc-start is a script that sets OPENMODELICAHOME. I think the omshell, etc scripts also set it.
So either use the script or put "export OPENMODELICAHOME=/usr/lib/omc" in your ~/.bashrc file.

It does for me, so yes it should. I might try to build a deb-package soon anyway.

Which reminds me... The deb package is weird. It doesn't set OPENMODELICAHOME env variable. You need to call omc-start for that to happen.

What is "env | grep OPENMODELICAHOME" ?

If not even root will create the files... Something must break sooner.
I have two ideas. One is the old omc server is still running... To shut it down for sure, use exit() in telnet.
The other would be to run "omc +d=interactive,failtrace +showErrorMessages" as the server. That will produce some extra error messages that might help.

Can you run the following commands and paste the output?

ls -l heli.makefile heli heli_res.plt

make -f heli.makefile && ./heli

1. mkdir ~/omc-tmp
2. cd ~/omc-tmp
3. /use/lib/omc/bin/omc +d=interactive &
4. telnet 127.0.0.1 29500
5. ??
6. profit

Well, of course you'd need to create the temporary folder
You can name it anything you want. You will just have problems running it from /usr/lib since your user doesn't have write rights to it

Hmmm... Are you running ./omc from the install directory (I assume /usr/bin)? omc will put all temporary files in the directory you launch it from, so go to "~/omc-tmp/" and launch $OPENMODELICAHOME/bin/omc and maybe it will run better?

Ah yes, we don't build Linux packages very often, so you would probably have to compile it yourself or use RC1.
I did run the code you used under RC1 and it seems to work fine there. So I guess you should try it.

For Windows I would say wait until RC3 is released. But since you use Linux I would say the trunk version is best (we made lots of changes since RC1, so waiting isn't really needed).

{heli} is the output we get in the new versions of OpenModelica. Why it wouldn't work in the terminal, I do not know
Have you tried the newer OpenModelica releases?

>>> class heli input Real alfa; Real x1(start=0); Real x2(start=0); Real x3(start=0); Real x4(start=0); equation der(x1) = x2; der(x3) = x4; der(x2) = -0.65*x2 - 0.02*x4 + 5.4*alfa; der(x4) = -1.57 - 0.03*x4 + 9.8*x1 + 9.8*alfa; end heli;
{heli}

>>> simulate(heli)
record SimulationResult
    resultFile = "heli_res.plt"
end SimulationResult;

class heli input Real alfa; Real x1(start=0); Real x2(start=0); Real x3(start=0); Real x4(start=0); equation der(x1) = x2; der(x3) = x4; der(x2) = -0.65*x2 - 0.02*x4 + 5.4*alfa; der(x4) = -1.57 - 0.03*x4 + 9.8*x1 + 9.8*alfa; end heli;

It reached the end of the string without finding the semicolon that always follows "end XXX".
I added a trailing semicolon and the class seemed to load fine.

Ah. This is working in the trunk version, but not rc2. I remember fixing some things regarding boolean arrays/etc after the modprod workshop (which was the week after rc2 was released).

Those are the latest binaries for Linux. Source code can be found on:
Directions for obtaining rc2 sources can be found on: http://www.openmodelica.org/index.php/d … ource-code
Or you could try the very latest version (trunk) if you'd rather use that.

You can compile the simulation with the -pg flag. And then run gprof afterwards.

That's what the compile omc with when we need to figure which functions take most time anyway. It's probably applicable to simulation code as well.

Yes, parameters and constants should. But the backend can't handle it properly yet.

When you start adding parameters into the picture things get more complicated, since you can no longer constant-evaluate the function call (since it depends on some parameter that may be changed at initialization). I'm pretty sure parameters are used inside functions (see Modelica.Media), so it will be fixed sometime in the future (when we can actually flatten Modelica.Media).

Well... The flattened model doesn't seem to use a function like the one you describe (or in fact any Boolean values).

The problem probably has to do with the fact that boolean values are stored as doubles in the simulation runtime, however...

If you are not going to use MODPAR, you could just disable it in the configure script. I never enabled it, and so I haven't fixed warnings on 64-bit platforms for those files... I did however fix some warnings on 64-bit OSX for trunk/Compiler/runtime now. Maybe that will help some.

The problem is (of course) that RML uses (void*) in order to store an integer (shifted 1 bit, so 31 or 63-bit integers in OpenModelica).

I'll assume it contains the line "extern void *mk_scon(char*);", which just leaves... g++ version?

Try to run the command verbose (g++ -v) and post the log.

g++ -DPACKAGE_NAME=\"\" -DPACKAGE_TARNAME=\"\" -DPACKAGE_VERSION=\"\" -DPACKAGE_STRING=\"\" -DPACKAGE_BUGREPORT=\"\" -DYYTEXT_POINTER=1 -DSTDC_HEADERS=1 -DHAVE_SYS_TYPES_H=1 -DHAVE_SYS_STAT_H=1 -DHAVE_STDLIB_H=1 -DHAVE_STRING_H=1 -DHAVE_MEMORY_H=1 -DHAVE_STRINGS_H=1 -DHAVE_INTTYPES_H=1 -DHAVE_STDINT_H=1 -DHAVE_UNISTD_H=1 -DHAVE_SYS_TIME_H=1 -DHAVE_VPRINTF=1 -DHAVE_GETCWD=1 -DHAVE_SELECT=1 -DHAVE_STRDUP=1 -DHAVE_STRERROR=1 -DHAVE_SCANDIR=1 -DUSE_CORBA -O3 -I/usr/local/include/plain -I../../c_runtime  -I../../c_runtime/superlu/include -I../ -I. -I/usr/local/include -I../ -Ilpsolve   -c -o unitparserext.o unitparserext.cpp -v

And rml.h exists in /usr/local/include/plain, right?

What g++ line did it use? And did you get a "Warning: Could not find rml.h" at the top of the line?

And `find $RMLHOME -follow -type d -name plain |grep include/plain` returns what? If it just returns one line, re-run ./configure and it should work.

Edit: I think I see why. The find command someone thought was good to use will break if you can find two rml installations in the same path... Anywhere in the same path... Should be fixed in the subversion trunk.

Hi,

The Makefile.in in trunk/Compiler/runtime uses the macro:
RMLINCLUDE = @rmlinc@

The configure script uses the $RMLHOME environment variable, and if that contains several directories, I suppose it is possible to get these weird lines in the Makfile that the configure script generates (it uses "find $RMLHONE [...]" to find the directory).

I can't help you with the Windows errors, however.

As far as I can tell, -O rather than -O3 is needed because of bugs in the g77 used on Windows. And we used to use -O way back as well (even back in 2006).
Could you post the code you load in the compiler and the error messages (I only compile the command-line tools)?

I've updated the trunk of OpenModelica to add the following to the generated Makefiles (with SENDDATALIBS set to the same as omc would normally use on your platform):

ifndef SENDDATALIBS
  SENDDATALIBS=-lsendData
endif

The environment variable SENDDATALIBS is probably not defined in your usual shell, and the paths are different if QT clients are used or not (and different on other OS's).

Compiler martin$ grep SENDDATALIBS runtime/systemimpl.c
    _putenv("SENDDATALIBS=-lsendData -lQtNetwork-mingw -lQtCore-mingw -lQtGui-mingw -luuid -lole32 -lws2_32");
        "SENDDATALIBS=-L%s/lib -lsendData -framework QtNetwork -framework QtCore -framework QtGui -lz -framework Carbon",
        "SENDDATALIBS=-L%s/lib -lsendData -lQtNetwork -lQtCore -lQtGui",
        "SENDDATALIBS=-lsendData");

Yes, it does work in Windows 7 64-bit (it's what I used to use). It will run the code in 32-bit mode.

As for the error message, it's a bit hard to understand what went wrong from such a brief description. Does omc.exe work fine for example? Or is this a problem with firewalls?

sudo apt-get install build-essential

Yes, it is.
Also, there is more development on SimForge than MDT if you want a more complete modeling environment (it also uses OMC as its back-end).

Fonte wrote:

I am interested in using OMC as interpreter to correct the errors in the code

MDT will use OMC to find syntax errors. If you want to find semantic errors (type checked, etc), I'd recommend using OMShell and the checkModel(), instantiateModel() or simulate() commands.

What is your use case for this? Are you trying to build OpenModelica from source code? Are you running the MetaModelica exercises? Or are you trying to make simulations?
Build project only makes sense for MetaModelica code, not Modelica.

$ omc +d=interactive &
$ telnet 127.0.0.1 29500
> 1+2
< 3

Works fine. I'll add text when launching "omc +d=interactive":
print("Opening a socket on port " +& intString(29500) +& "\n");

Since it doesn't say anywhere which port is actually opened...

There is a major problem with mingw and using spaces in path names.
So installing in C:\Program Files\ will not work. It's too bad the installer won't detect this and scream. Maybe we should look for spaces in OPENMODELICAHOME and generate better error messages...

I am assuming you want to optimize parameters.
When you create a simulation, you will create an executable file and a file containing parameters. When the executable is run it generates a .plt file containing all of the results.
So if you want to optimize parameters, you could write a program that changes the _init.txt file containing parameters, run the program and fetch the relevant result.
I'm not sure if anyone has already made such a tool, but it is possible.

It is also possible to call OpenModelica through a CORBA interface. Then you could use the simulate() and val() functions to do the things above in a simpler manner. It would be a bit slower, however (it will recompile the model for each simulation).

It sounds like maybe you are using a firewall software that blocks the OpenModelica process from communicating with OMNotebook. If so, OMShell will give you the same kind of errors.

If you kill the process manually, the omc.exe process will still be alive in the background. You also need to shut that down if a tool crashes.

I use the latest development version on 64-bit OSX 10.6 and 64-bit Ubuntu 9.10.

As for enumerations being buggy... I would love to see some more models using enumerations that do not work on the development version of OpenModelica. Whenever we fix a bug, we also add a testcase so it will keep on working.

I didn't know Adrian made an rc2 so recently. Sadly, I don't really think downgrading to 1.4.5 will help much since we barely supported enumerations back then.

I also checked the nightly builds (http://www.ida.liu.se/~pelab/modelica/O … y-builds/), but it seems to have the same date stamp as rc2.

Edit: On second thought, try rc1. rc2 was made right after a large commit that changed function generation - there might be some issues with it.

I fixed the spelling of algorithm and it started working fine.

Note that 1.5.0 is not released yet, and the release candidates are about 6 months old. I am using the latest version and don't have access to the old ones.

What program are you using to call the mos-file? If you're running OMShell, I don't think we redirect stdout, so you won't see that printf statement.

Add a getErrorString() after the simulation and loadFile() commands.


model mysocket
m_startup( );
end mysocket;

Is invalid syntax. getErrorString() after loadFile() should catch this.

model mysocket
equation
when initial()
  m_startup( );
end when;
end mysocket;

Would probably be better. Or possibly encapsulating the socket in an external object.

It's hard to tell without seeing some code or error messages, but here goes:

function myExt
  ....
external "C" ... = myExt(...) annotation(Library = "myExt.o"); // Note the required .o, not present in Dymola... We really should fix this
end myExt;

model A
  TypeA myType = myExt(...);
end A;

myExt.cpp:

... C++ code ...

extern "C" { /* Export the function as if it was a C function */
... myExt (...) {
  ...
}
}

Yes, .a's also work. The way it works (if I recall correctly) is the Library annotation is used as arguments to the gcc command used to compile the simulation file.
Thus, any gcc command will work (for example -L/usr/local/mypackage/lib/ mypack.o, if you want to link mypack.o and search /usr/local/mypackage/lib when looking for object files).
You can even specify C files in the annotation. But if g++ is used by OpenModelica (the svn trunk does) you have to use extern "C" {} in order to make the external function accessible.

Hi, libraries should preferably be compiled using the same compiler you are using to compile OpenModelica (mingw-gcc by default). If you mix MSVC and GCC, you run into problems because they use different C runtimes.

If you wish to link more libraries with your simulation, add those libraries to the annotation(Library = "myext.o postgresql.o"). You could also load dll's from your external function without linking to those using LoadLibrary (Windows) or dlopen (Unix).