Optional forward output package in communication sinks

[tbeu]

I again was faced with issue #81 and I noticed that if the communication sinks (i.e., SharedMemoryWrite, UDPSend, SerialPortSend, LCMSend, SoftingCAN.SoftingWriteMessage and SocketCAN.WriteMessage) optionally forward the output package, it could be used to solve the multiple sender issue (#122).

This is a demonstrating patch for LCMSend only ...

--- a/Modelica_DeviceDrivers/Blocks/Communication.mo
+++ b/Modelica_DeviceDrivers/Blocks/Communication.mo
@@ -454,10 +454,16 @@ sudo route add -net 224.0.0.0 netmask 240.0.0.0 dev lo
       annotation (Dialog(group="Outgoing data", enable=provider==LCMProvider.UDPM));
     parameter String channel_send="" "Channel name"
       annotation (Dialog(group="Outgoing data"));
+    parameter Boolean forwardPackage = false
+      "true, if input package is forwarded as output package" annotation(Dialog(group="Outgoing data"), choices(checkBox=true));
     Interfaces.PackageIn pkgIn annotation (Placement(transformation(
           extent={{-20,-20},{20,20}},
           rotation=270,
           origin={-108,0})));
+    Interfaces.PackageOut pkgOut(pkg = pkgIn.pkg, trigger = pkgIn.trigger, dummy = dummy) if forwardPackage annotation (Placement(transformation(
+          extent={{-20,-20},{20,20}},
+          rotation=90,
+          origin={108,0})));
   protected
     parameter Integer receiver = 0 "Set to be a sender port";
     LCM lcm = LCM(

... with multiple LCMSend on the same serial package.

[tbeu]

For the record, pkg = pkgIn.pkg is not Modelica compliant as long as mo:#1669 is not fixed.

[bernhard-thiele]

Yes, that could enable multiple senders. I just wonder what sort of constructions this allows, e.g., one might have other "AddXXX" block after the "lcmSend". Also we have the "autoBufferSize" and the "trigger" logic which can be modified in the send blocks and distribute through the connected blocks. Might get increasingly difficult to use the blocks and understand the consequences of certain settings.

I don't have a feeling for how strongly this feature is required by various users. Supporting it will add complexity and maybe also allow combinations of settings which lead to rather unexpected behaviour. There is a trade-off, and we would need to investigate it before adding such an extension.

[tbeu]

I am also not sure how strongly this feature is requested by users. Probably none. For LCMSend the above example worked indeed, when tested. I only noticed by accident when once again stumbling across #81 (with every test of the communication examples I do). Hence, it is not of high priority for me, though #81 is really awkward.