Provide number of received bytes in UDPReceive block as output

[bernhard-thiele]

Sometimes one would like to know how many new bytes were received. Particularly, one would like to know if a new package has been received at all (hence, received bytes > 0).

The idea is to introduce an additional integer output nRecvBytes to the UDPReceive blocks. This output will be 0 if no new package was received, otherwise its value will be the number of received bytes.

[bernhard-thiele]

Additionally, there could be an output nRecvbufOverwrites which allows to check whether the receive buffer was overwritten with new data before the last data was retrieved by the Modelica simulation.

[tbeu]

Do you want me to update the SimulationX-specific ITI_MDD.dll already now?

[bernhard-thiele]

Yes that would be fine, since I don't have another PR in the pipeline. Could also be good idea to integrate a SimulationX target in the CMakeLists.txt file so that a user of the master branch can easily recompile for SimulationX, if needed.

[tbeu]

Could also be good idea to integrate a SimulationX target in the CMakeLists.txt file

We have it already, don't we?

[tbeu]

The commited changes actually break the API for the UDP send functions, both on Modelica and C level. Should we rather add (and utilize) new functions and keep the existing functions (as obsolete), in order to not break custom models relying on the function layer?

[bernhard-thiele]

I don't think this will be an issue since existing code should still work. Since there had been no return value, existing code will not check for any return value, hence it should be backwards compatible, shouldn't it?

[tbeu]

It can be an issue for copied code (for example, https://github.com/RWTH-EBC/AixLib/blob/a4b2a05dcf0f6db46341851ef3ea4957cfcb2e8c/AixLib/Controls/HVACAgentBasedControl/BaseClasses/Internal/sendTo.mo)

[tbeu]

To be on the safe side and in compliance with semantic versioning I'd recommend to introduce new/extended functions or to label the new version 2.0.0.

[bernhard-thiele]

Hm, in general I don't see the signature of external C functions as part of the public API of a Modelica library, but rather as a part of the internal implementation. However, it's not a big deal to add some functions to maintain backwards compatibility of the C layer in this case, so I will do it.