I have a requirement in C++ to pull fields from topics, details of which topic and which field are in a configuration file that is loaded at run time.
So Dynamic Data looks to be able to do this.
I've grabbed some sample code that monitors raw data, which I've been able to use to prove the concept. The code is mostly able to identify topics and types and extract the values, but then I can't get the actual data from my real publishers, the problem I'm having is it's getting on_requested_incompatible_qos events when I try and set up a reader for the dymanic type that has been constructed from the builtin subscriber.
The topics uses non standard QoS and the QoS used by the publisher changes based on the topic.
I think what I need to do is get the QoS for the discovered topic and use it when I create my reader, use that QoS and not DATAREADER_QOS_DEFAULT (and possibly earlier around topic creation).
Does this make sense ?
Can some one shove me in the right direction to fix this ?
Ok, so your incompatible QoS is not related to the use of the DynamicData API.
A DataWriter and DataReader (of the same Topic) must be configured with compatible QoS settings for them to connect.
QoS settings are set on the DataWriter and DataReader directly. Yes, there is such thing as a Topic QoS, but it's really fairly useless since Topics are not discovered in and of themselves...only DataWriters and DataReaders.
So at runtime, using RTI Admin Console, you can determine which QoS settings are incompatible.
I'm not sure what your use case is (what you are actually trying to do), but what should happen if the system has multiple datareaders of the same Topic with different QoS settings? Create 2 different DataWriters with different QoSes? In some cases, both DataWriters may be compatible with all DataReaders...and DataReaders would get multiple copies of the same data...in other cases there will be incompatibilities between some or all of the DataReaders for a DataWriter.
However, yes, you can determine what QoS settings (used in compatibility comparison) was used to create a DataWriter or DataReader by monitoring the builtin DataReaders for DDS discovery of "publications" aka datawriters and "subscriptions" aka datareaders.
You'll have to read through a bit of documentation and examples. I suggest you start here:
https://community.rti.com/static/documentation/connext-dds/6.1.0/doc/manuals/connext_dds_professional/users_manual/index.htm#users_manual/builtintopics.htm
and then example code can be found on the community.rti.com website here
https://community.rti.com/examples/builtin-topics
Hi Howard,
thanks for the quick response, I wasn't expecting anything until overnight.
Sorry, I didn't explain what I was doing very well.
I'm on a network with a number of sensors that publish data (think temperature and pressure), but I don't know exactly what they look like at compile time, so I can't do the regular rtiddsgen thing. So the idea is to have a configuration file that has the topic and fieldname in that topic that has these values. New sensors just need to be defined in the configuration file. There can be multiple publishers of a given topic, but they will all have the same QoS.
My PoC works fine when the publisher uses the default QoS settings, but the sensor publishers don't use the defaults.
I'm looking to derive the QoS from the publisher in the same way I'm able to derive the topic data.
All that said, I'm off to read the documentation pointers you've provided.
I think I'm close, just having trouble with incompatible QoSes.
Good luck!
I feel I'm close, but still not there.
The monitor_raw_data example I've used to get started uses the builtin topics to correctly identify the data type and create a typed reader.
What I think I need to do is get the QoS Library and Profile for the detected topic, then apply that to typed reader.
But after reading through the examples (and others) I can't see how to achieve that.
Is my understanding correct ? If so, how do I detect the QoS library and profile in use by the publisher (hopefully using the builtins) ? Or do I need to maintain a parallel configuration file that aligns a profile to a topic (there is only one library to contend with, so I can hard code that if I need to) ? Or the other possibiliy I consider is that I can reconstruct a QoS from the builtin ?
Nope, QoS Libraries/Profiles are local definitions. They are not propagated on the network. You won't be able to find what QoS Profile/Library was used to create an Entity (either locally or remotely actually).
There are only a few QoS Policies that are compared for compatibility. All are shown in the Match Analysis view of Admin Console.
All of the QoS values of the compared policies are propagated with Discovery as a part of the builtin Topic for publications and subscriptions...
https://community.rti.com/static/documentation/connext-dds/6.1.0/doc/api/connext_dds/api_cpp/structDDS__PublicationBuiltinTopicData.html
https://community.rti.com/static/documentation/connext-dds/6.1.0/doc/api/connext_dds/api_cpp/structDDS__SubscriptionBuiltinTopicData.html
So from the builtin topic data that you get from discovering a new DataReader (subscription), you should be able to create a compatible QoS structure for a DataWriter.
Thanks.
I'm lucky in that I can build a configuration file that identifies which QoS profile I need to apply to each topic and I'll do it that way for the moment. May look back later to see if pulling from the topic data is better.