Awkward I/O causality in communication examples about modelica_devicedrivers HOT 7 CLOSED

The example models are artificial since they "misuse" the blocks for internal communication. This is handy for testing if reading and writing works, but not a practical use case. In practice we would get our input stream from external devices and the sample events are not synchronized to the Modelica simulation.

Enforcing a certain execution order for this blocks in a Modelica model is also connected to the discussion in #77. We would need to ensure that sending and receiving is triggered by the same time event in order to sort them by data-flow, or we would need to generate time events (from sending) that are used to trigger the receiving blocks.

However, even if we would sort them it might be not guaranteed that there is no delay. If we write data to some nonblocking device that writes it in an internal (transmit) buffer and we read from that device immediately after that, it might be that an internal (receive) buffer that we read from is not yet updated with the new values.

Sending as early as possible and reading as late as possible makes sense. However, this is a tool issue that probably shouldn't be solved by library developers. Still, we could try to invent something. However, so far I'm not sure whether it would provide a practical improvement or just would make things more complicated.

from modelica_devicedrivers.

I did not see the relation with #77 ad hoc. Rather I wanted to get rid of the sinks and sources by means of the dummy flag passed through. See my 0001-Fix-execution-order.patch where I added additional dummy pkgOut to UDP sink and pkgIn to UDP source. Now it is even possible to reuse the sent UDP package (due to calling resetPointer) in a deterministic way. Please test the adapted TestSerialPackager_UDP model where now the execution order is deterministic. If you agree, this should go to a new example.

from modelica_devicedrivers.

It is strange, the example is not working correctly for me.

What happens if you set sampleTime=0.2 for the sending block and sampleTime=0.1 for the receiving block and compare the signals of getInteger.y[1] and setInteger.y[1]?

For me the sending part es executed with sample period of 0.2s while the receiving part is executed with 0.1s.

from modelica_devicedrivers.

Hm, what you say ist what I would expect, if UDPSend.sampleTime=0.2 and uDPReceive.sampleTime=0.1 Which setInteger.y[1] do you mean? Can you please check again what exactly should be wrong here?

from modelica_devicedrivers.

I was referring to a simulation run of the TestSerialPackager_UDP example.

I understood the intention behind the example was to use the same event to trigger the writing and reading while using data-flow dependencies for ensuring an execution order in which the writing is done before the reading.

However, the when clauses in udpSend and udpWrite are not triggered by the same event. Even if the same sampleTime is used in both blocks the events generated by sample(0,sampleTime) count as different events and there is no guarantee in Modelica that the two events occur at the same time instant. MLS 3.3 Revision 1, p. 94:

There is no guarantee that two different events occur at the same time instant.

Hence, the data-flow dependencies won't help here to ensure the execution order. This only works if
the equations are activated by exactly the same event.

If I simulate the model in Dymola on my Linux machine using a sampleTime=0.1 I get a delay between writing and reading the signal that is two sample periods for most of the events and one sample period at a few points. Since the receiving socket is executing in its own thread and "mysterious" read and write mechanisms are used under the hood of the system calls it is not surprising that the delay is not deterministic.

But even if you would write to a shared variable the current logic won't ensure that the writing is done before the reading, because a Modelica tool may first handle the event that triggers the reading and after that the event that triggers the writing.

from modelica_devicedrivers.

Very strange. With this patch applied I can see in SimulationX (and also debugging in VS) that send is called before read. This was not the case before.

So you may close this issue and we won't get into it.

from modelica_devicedrivers.

I think the actual behavior for synchronous/asynchronous events in Modelica is a bit fuzzy. The synchronous language elements extension is cleaner in that respect.

Despite the MLS stating that there is no guarantee that two different events occur at the same time instant tools seem to be free to synchronize different events. There is a paper by Ramine Nikoukhah & Sébastien Furic that discusses that in some detail.

I just checked with some examples for Dymola and OpenModelica and it seems that they treat the events as synchronous and sort corresponding equations. But I don't know to which extend one can rely on that. In libraries like Modelica_LinearSystems2.Controller we used/use an inner event source that is accessed by all the blocks to ensure synchrony and to my knowledge this is still the recommended way to do such things.

from modelica_devicedrivers.