Jump to content
OpenSplice DDS Forum


  • Content Count

  • Joined

  • Last visited

About rowen

  • Rank

Profile Information

  • Company
  1. Yes OpenSplice_PythonDCPSAPIGuide.pdf is missing a lot of important information, including how to specify DDS partitions and how to specify QoS overrides. It is also full of TODO notes,, including "TODO change description the code is wrong". I ended up using your manuals for other languages and trying to adapt as best I could. I did not have access to your python examples when I was doing my work (though I have since found them -- in tools instead of examples) Several things I think the dds library cannot do that I really wish it could: Support content-filtered topics. I am using a QuerySet instead (but not in the example) but would much prefer to do the filtering before the data gets into my read queue. Obtain QoS settings from the dds.QosProvider (or even do a dump to a string so I could see what settings are being used, even if I can't easily query for individual settings). Get the dds.Reader from the dds.ReadCondition, so the read conditions returned from dds.WaitSet.wait could be used to actually read the data. The license is GNU General Public License v3.0. You are welcome to use the examples as you see fit, and if you need a different license please let me know. However, I doubt you will find you can adopt anything "as is", as I have created a few convenience classes.
  2. I recently started using the OpenSplice dds Python library and found the documentation less than clear. Having fought my way to working code I am making a simple set of example files available in hopes of helping others: https://github.com/r-owen/ddsexample In addition to reading and writing a topic, this code demonstrates: Specifying DDS partitions Specifying custom quality of service values programattically Reading data using asyncio Suggestions for improvements are welcome. I am not very comfortable with the QoS XML file and would appreciate a pointer to good documentation on which settings should be specified under which categories and the defaults (since I suspect much of that file can be omitted).
  3. Yes. My use case just doesn't fit the OpenSplice data model as well as it might. I care about the difference between late joiner data (samples written before I created my reader) and current data (samples written after I created my reader, though I may not have actually read them yet). Most readers only want a single sample (the most recent) of late joiner data. (I am trying to avoid the term "historical"). So I call `wait_for_historical_data` on the reader after creating it, then discard all samples except the most recent before I start processing samples. It means I may discard some current data (especially since `wait_for_historical_data` can take a shockingly long time) but it's good enough. It may well be better than trying to process the 5+ seconds of current data that accumulates while I am waiting for `wait_for_historical_data` to finish. In any case I see no alternative, since I have found no way to tell the difference between late joiner data and current data in the reader.
  4. To clarify what I tried: I made a topic with a normal and reasonable history_length and made a writer from that. Then I tried to make another topic instance (using the same domain participant) with a history_length of 1 for my reader. Creating that second topic failed. No big deal, just a minor disappointment. Note: I have no desire to limit the read queue length itself to a length of 1 because I need to be able to handle bursts of data without losing any. Again, not a big deal. I'll just throw out the historical data I don't want.
  5. When my domain participant and readers start up I call wait_for_historical_data (which takes 6.5 seconds on my machine for the first reader, alas) but writers may be producing new data during that time. I'd like to be able to tell the difference between historical samples and new samples (where the latter might be defined as "written since I called wait_for_historical_data", unless some other similar definition is easier). I was hoping for a flag in the dds.SampleInfo that told me if this was historical or new, and/or a read condition that would only return historical data, but I have not found either. There are timestamps in the dds.SampleInfo associated with each sample that might help, but the obvious choice is source_timestamp and I would have to know the clock offset to use that reliably. reception_timestamp seems to use the local clock, but there is no obvious break between historical data and new data. Any suggestions?
  6. Thank you very much. For the record: this works great if I set history_length in my default QoS file, and the way to do it in dds Python is to use a dds.DurabilityServiceQosPolicy However, I was hoping to have writers offer more history than most readers read. One reader wants the extra, but the rest do not. So I tried to create one topic for writing and one for reading, with the latter using a shorter history_length (but otherwise identical policy). Unfortunately, creating the second topic fails. Sounds like I'll just have to discard the extra history. I wish readers supported history_length separately from topics.
  7. I would like to configure a DDS topic reader as follows: - a read queue with at least 100 entries, so I can occasionally fall a bit behind and not lose data - on startup read only the single most recent historical (late joiner) value for that topic The only relevant setting I have found is KEEP_LAST_HISTORY_QOS which seems to control both the size of the read queue and also how many historical values are read. I realize I can simply ignore the extra historical data, but it takes time for DDS to copy it. I hope I am missing something simple. In case it matters, I am using the VOLATILE settings because I only care about historical data if the writer is still alive.
  • Create New...