Hi ,
I am using rticonnextdds-connector-py from pip. https://pypi.org/project/rticonnextdds-connector/ 1.0.0
I am trying to add on participant_qos for on domain_participant in the config xml file:
<domain_participant name="TestToolParticipant" domain_ref="DomainLibrary::MyDomain">
<!-- Version not working participant_qos base_name="DDS_SUPPORT_QOS_LIBRARY::QOS_PROFILE_EMPTY"></participant_qos-->
<participant_qos>
<wire_protocol>
<rtps_host_id>0x11111111</rtps_host_id>
<rtps_app_id>0x22222222</rtps_app_id>
<rtps_instance_id>0x33333333</rtps_instance_id>
</wire_protocol>
</participant_qos>
</domain_participant>
</domain_participant_library>
Using one profile is not working. Error Failed to create Connector:
Using directly, <participant_qos><wire_protocol> ... is not working Error Failed to create Connector: (it should see https://community.rti.com/forum-topic/unable-change-guid-vxworks-participant)
The only working way to define some participant_qos is to used one profile like qos_profile name="Logging" is_default_participant_factory_profile="true". But then the participant_qos seems not to be used. I can create the connector, I have more logging but the host_id is not set according to the participant_qos
Can you please help me? Thanks.
</domain_participant> </domain_participant_library>
Hi Mathieu,
So, why do you want to set the GUID for the participant? This isn't typically needed nor recommended. The main use case is when RTI's GUID generation algorithm isn't able to generate unique GUIDs when the application restarts. This was an issue on real-time OS's where the same process id is deterministically assigned to the same applications when the real-time OS reboots. But I think that the latest GUID generation algorithm doesn't rely on the process id anymore and now works without the need to manually change the GUID.
Having said that, theoretically, setting the GUID for a participant via the XML file should work. I've never tried with RTI Connector, but is there any error output other than "Error Failed to create Connector"?
I'm not sure what you mean by "The only working way to define some participant_qos is to used one profile like qos_profile name="Logging" is_default_participant_factory_profile="true"."
First, defining a participant via
<domain_participant name="TestToolParticipant" domain_ref="DomainLibrary::MyDomain">
is not the same as defining a qos profile via,
<qos_library>
<qos_profile name="myqosprofile">
RTI Connector requires you to define a domain participant so that you can instantiate it in the python script. But the QOS file can also define <qos_profile>s that are may or may not be used by the domain participant.
You can define a qos_profile and use "is_default_participant_factory_profile="true"" to have it applied to the DomainParticipantFactory which is used to create the domain participant. And the main reason for doing that is to enable logging, which I assume you were successful in doing based on your comments.
However, using "is_default_participant_factory_profile="true"" does NOT apply that profile to any DomainParticipants that are created and you should be able to have both a <domain_participant> definition that sets the QOS for the domain participant as well as a <qos_profile> that sets the default qos for the factory.
Fundamentally, there's something wrong in your XML file. Having more debugging output to figure out the GUID issue is needed to understand that problem. It would be useful for you to attach your entire XML configuration file to see the big picture.
Finally, RTI will be releasing a full Python API. The RTI Connector for Python provide Python users a way to use DDS through a limited API. However, we found that Python users wanted to have access to the full features of Connext DDS and thus, we are working on producing a full Python API.
We have released a "beta" version that you can access via these instructions:
https://community.rti.com/static/documentation/connext-dds/current/api/connext_dds/api_python/
Hi Howard,
Thanks for your answer. And happy new year!
I am not setting the GUID but because i am using the python connector (DDS6) with older applications (DDS5), i have to add this in the qos_profile
<qos_profile name="QOS_PROFILE_BASE" is_default_qos="true">
<participant_factory_qos>
<logging>
<verbosity>ALL</verbosity></logging>
</participant_factory_qos>
<participant_qos>
<wire_protocol>
<rtps_auto_id_kind>RTPS_AUTO_ID_FROM_IP</rtps_auto_id_kind>
<rtps_host_id>RTPS_AUTO_ID</rtps_host_id>
<!-- Starting in 6.0.0, the default value of DDS::DomainParticipantQos::wire_protocol::rtps_auto_id_kind
has changed from DDS_RTPS_AUTO_ID_FROM_IP == 0 (which caused the rtps_host_id to be the IP address by default)
to DDS_RTPS_AUTO_ID_FROM_UUID == 2 -->
</wire_protocol>
Thanks for explanation with the participant factory. Now i am using is_default_qos="true"
Thanks for the link. I am still using DDS 5.2.3.0, So i think it could not work (See requirement Connext DDS 5.3.1, 6.0.0, or 6.0.1)
Indeed i TestToolParticipant have to read with python samples sent by one application using DDS 5.2.3. I think it is possible with some settings that i have found in documentation about migrating (like the rtps settings)
For now, i am to resolve this
PRESParticipant_checkTransportInfoMatching:Warning: the message_size_max, 65487, for shared memory of the remote participant (TestToolParticipant), does not match the message_size_max, 65536, of the local participant (key: c0a8286f,2938,1). These two participants will not communicate over shared memory.
The both applications are on the same computer.
65487 is computed by pytho, from 65536 minus i think some header size. (49)
I will try to change the setting of the old application because it is not possible to set message_size_max to 65585 (65536 + 49) (I have one exception)