Keep read data instead of discarding on receive #119
Conversation
This partially fixes modelica-3rdparty#117 (there is still the problem that reading data discards the entire buffer).
|
Hm, just looked at the master branch code. I think it has the issue that if a datagram is only partially read by the However, what is intended is that it overwrites old data. The code was written with typical digital control application in mind. In control applications you are typically only interested in the most recent sensor readings. Imagine a closed-loop control system with periodic sampling. What you would like to have are the sensor values at the exact time instant when the instantaneous equations of the control law are active. If you have no tight synchronization between gathering the sensor values and the activation times of the instantaneous equations, the best you can do is to simply take the most recent values that are available. Hence, you don't care about the old values. Of course, there is also the use-case in which you need to ensure that every datagram is reliably received, e.g., if you communicate a (single) start or stop message to a device. However, this approach is currently not supported (was not needed for the applications that we had, e.g., start or stop of a device can also be encoded as a "flag" within a periodically sent datagram). The questions is of course, shall we also support a "reliable" receive mode, and if so, how to do that best? |
|
The thing with serial port communication is that it is sent 1 byte at a time and when interfacing we can't just say "we synchronize the start/end of a package by sending 3 zeroes" since we might need to communicate with hardware. For serial communication I think you cannot know which is the last datagram unless you know that all datagrams have the same size, in which case you can discard one if a full second one has been transferred. If the transfer was always reliable, it would be rather simple to have a read function that takes a boolean which strips the |
|
@bernhard-thiele bump |
|
I had the issue as well, that external hardware wasn't synchronized perfectly with my PC so I got wrong messages in regular intervals. Under Windows, I keep a duplicated buffer and take the last result if a message is incomplete. See vwaurich@5bbfdc6 |
|
@vwaurich It seems that If the message is incomplete you simply drop it and you take the last one. I didn't look much at the Windows code since I don't know the API. But is the issue that sometimes messages are only partially transmitted and a mechanism is needed to recover from that? In the linux version it only starts reading from the serial port if there is new data. If there is no new data, it will not update the buffer and thus the old values will be read by Modelica. If there is new data, but it is incomplete data, then there might be some need to recover. But maybe I miss something. |
Related to #117, #119, #127, #129 - Deprecating serial port function "getReceivedBytes" #129 - Mutex is used to protect access to "serial->nReceivedBytes" - Fixed buffer types void* -> unsigned char* - The Modelica interface functions will only see new values if a complete message is available - Incomplete messages are written in an internal buffer which grows until it contains a complete message which is then copied into the buffer that the Modelica interface functions access.
|
Okay, I guess I can close that due to 3c0a9da |
This partially fixes #117 (there is still the problem that reading
data discards the entire buffer).