Hi,
I’m relatively new to the whole DDS world so I’m hoping someone more experienced will know this off the top of their head. I mostly work in python on various data science topics. Recently there has been need for one of our pyrton scripts to communicate via DDS with embedded hardware.
Therefore the python library provided as part of the rticonnextdds-connector package looks quite appealing.
I got the basic read.py / write.py examples setup and running on my primary windows box as well as a Raspberry PI. However, in both cases while the reader.py file works fine the writer.py file seems to only be able to publish a limited number of times before the reader stops receiving it. The exact number of publishes seems to be 296. if I then ctrl^c my way out of the writer.py and restart it the reader will again receive 296 publishes by the writer before the reader stops receiving it.
Other information:
The writer.py script does not seem to throw an error at any point as far as python is concerned. However, some of my experiments show that past the 296th publish the runtime for the outputDDS.write() goes from ~0.0003 seconds to ~5 seconds. This said even if I allow the writer.py to continue to past the 296th publish with the delayed outputDDS.write() no further publishes will be received by the reader.
This seems to happen no matter the paring of writer host / reader host I use. Windows Writer:Windows Reader (same computer), PI Writer:Pi Reader (same computer), Pi Writer:Windows Reader, Windows Writer:PI Reader
Code is attached:
Code was originally based on examples found here: https://github.com/rticommunity/rticonnextdds-connector
Any help would be appreciated
| Attachment | Size |
|---|---|
 pycode.zip | 2.27 KB |
Hi,
You're seeing this problem because the XML configuration file creates the reader and the writer inside the same participant, so your writer.py script is not only creating an output to write; it's also creating an input that is receviing the samples, but never taking them. This causes the writer to block after it reaches its resource limits.
The solution is to split the reader and the writer into 2 different participants in the XML configuration file.
We will fix this example in the upcoming Connector release.