[MBDyn-users] fork & simulink & sockets

Pierangelo Masarati masarati at aero.polimi.it
Fri Oct 12 15:18:39 CEST 2007

Rudi Jaeger wrote:
> Dear  Alessandro,
>> ... if you like, maybe you can help us to make the 
>> mbdyn-start block work correctly and make it more portable :-)
> Maybe you can help me a little bit.
> As far as I can see, MBDyn (as a server) fails to stop.
> The stop-time provided in the MBDyn-input file does not matter in case
> of a Simulink-run. Stop-time seems to be determined by the setting in the
> Simulink configuration. 
> Did you program it this way? Is this a feature of the MBDyn-Simulink interaction?
> If yes: what is telling MBDyn that it can stop (being a server)?


I can't debug things right now, but I can tell you the rationale of what
MBDyn does.  I assume you're using 1.3.1, BTW (please, always specify
the version to help troubleshooting).

There should be nothing preventing MBDyn from checking the final time
provided in the input file.  In fact, what MBDyn (and supposedly the
Simulink connectors) does is:

- before performing a solution step, read any input from driver connectors
- after performing a solution step, send any output to output elements

If any of the connectors fail (i.e. the socket is closed by the peer),
stop, unless "no signal" is set.  In case it is set, no SIGPIPE is sent
if the socket is closed by the peer, and thus MBDyn does not realize the
socket is invalid and continues.

However, MBDyn keeps checking, after each time step is completed, if the
final time is exceeded or not, and thus it is supposed to exit if it is,
causing the Simulink connectors to be notified of socket closure.

If the behavior you observe differs, then there must be a bug.  In that
case, can you tell (e.g. by adding some debug statements into the
mbdyn/base/socketstreamdrive.* and/or mbdyn/base/socketstream_out_elem.*
files) what error or abnormal behavior you see?

Cheers, p.

More information about the Mbdyn-users mailing list