Issue with rticonnextdds-connector: Python only able to write 296 times

2 posts / 0 new
Last post
Last seen: 4 years 9 months ago
Joined: 09/04/2019
Posts: 1
Issue with rticonnextdds-connector: Python only able to write 296 times


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 / examples setup and running on my primary windows box as well as a Raspberry PI. However, in both cases while the file works fine the 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 and restart it the reader will again receive 296 publishes by the writer before the reader stops receiving it.

Other information:

The 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 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:


 Any help would be appreciated


Package icon pycode.zip2.27 KB
Last seen: 1 month 3 weeks ago
Joined: 04/02/2013
Posts: 195


You're seeing this problem because the XML configuration file creates the reader and the writer inside the same participant, so your 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.