Unable to change GUID for VxWorks participants

4 posts / 0 new
Log in or register to post comments
Last post
Tue, 05/28/2013 - 14:07
#1
mkruse
Offline
Last seen: 11 years 6 months ago
Joined: 03/22/2013
Posts: 7
Unable to change GUID for VxWorks participants

Hi,

We are trying to use the advice found here:

 http://community.rti.com/kb/why-my-vxworks-application-unable-discover-other-rti-connext-applications-after-restart

to generate unique GUIDs for our VxWorks applications (both C++ and Java based code).  However, no matter what I do, I never see any impact on the actual GUIDs generated (and observed using RTI's Analyzer).  The rtps_host_id is always the IP address of our target board, the rtps_app_id is always the VxWorks task ID (one for the C++ portion or the code and another for teh Java portion of the code), and the rtps_instance_id is always 1, 2, 3, etc. depending upon how many participants are running.

What am I doing wrong?  Or is this something to do with the use of the _exp() functions for creating the particpants?

Thanks,

Mark
==============================================================================================

// C++ example...

DDS_ReturnCode_t retVal;
DDS_UnsignedLong randomValue;

DDSDomainParticipantFactory *f = DDSDomainParticipantFactory::get_instance();

struct DDS_DomainParticipantQos p_qos;
retVal = f->get_default_participant_qos(p_qos);


// p_qos.wire_protocol.rtps_auto_id_kind = DDS_RTPS_AUTO_ID_FROM_IP;
p_qos.wire_protocol.rtps_host_id = 0xDEAD;
p_qos.wire_protocol.rtps_app_id = 0xDEADDEAD;
p_qos.wire_protocol.rtps_instance_id = (0x44 << 8) | (0x55);

retVal = f->set_default_participant_qos(p_qos);

DDSDomainParticipant *p = f->create_participant_from_config_exp(
  xmlQualifiedParticipantName.c_str(),
  localName.c_str());

==============================================================================================

// JAVA example...

DomainParticipantQos p_qos = new DomainParticipantQos();
DomainParticipantFactory.TheParticipantFactory.get_default_participant_qos(p_qos);

// p_qos.wire_protocol.rtps_auto_id_kind = WireProtocolQosPolicyAutoKind.RTPS_AUTO_ID_FROM_IP;
p_qos.wire_protocol.rtps_host_id = 0x8888;
p_qos.wire_protocol.rtps_app_id = 0x9999;
p_qos.wire_protocol.rtps_instance_id = (0x22 << 8) | (0x33);

DomainParticipantFactory.TheParticipantFactory.set_default_participant_qos(p_qos);

........... later in the code in another module...

DomainParticipant p = DomainParticipantFactory.get_instance().create_participant_from_config_exp(
  xmlQualifiedParticipantNamem,
  localName);

Organization:
Top
Tue, 05/28/2013 - 17:21
rip
rip's picture
Offline
Last seen: 3 days 5 hours ago
Joined: 04/06/2012
Posts: 324

Hi Mark,

The _exp() means experimental. Any commentary in this thread, that comes from "official" RTI people, is offered purely as 1:1 help, it should not be considered to be authoritative.

The docs don't say where the created entity will get its QoS from.  Can you check the XML config and see if you are explicitly setting the configuration in there?  I would expect the default behavior is supposed to be "1: take the default qos, 2: alter it based on downstream supplied alterations".  I'll try to set up a comparable test case and experiment.

rip

 

Top
Tue, 05/28/2013 - 20:50
rip
rip's picture
Offline
Last seen: 3 days 5 hours ago
Joined: 04/06/2012
Posts: 324

Interesting.  It appears that using create_participant_from_config_exp is ignoring both the default DomainParticipantFactory default dp QoS settings, and the settings supplied by "is_default_participant_factory_profile" attribute, if supplied, in the USER_QOS_PROFILES.xml file.  The factory loads the default participant factory profile/participant_qos profile, but the wire_protocol settings in the participant_qos are ignored in favor of the auto-generated values...

(it looks like it is using the underlying, compiled-in QoS settings for the participant factory, regardless of external stimuli).

There doesn't appear to be a way to modify the "BC" (before creation) QoS settings (wire_protocol, resource limits, a few others).  To test this I tried to change the default entity_factory.autoenable_created_entities from true to false for the participant, and this failed also.

We'll take this up internally. 

rip

 

Top
Wed, 05/29/2013 - 07:10
Gerardo Pardo
Gerardo Pardo's picture
Offline
Last seen: 3 weeks 5 days ago
Joined: 06/02/2010
Posts: 602

Hi,

Rip is right the default QoS settings are being ignored. This is a known issue.

In order to define the wire protocol settings that will be used by the create_participant_from_config_exp you should specify that QoS in the XML definition of the DomainParticipant itself using the <participant_qos> tag as shown in the XML snippet below:

       <domain_participant domain_id="0" name="PubDomain" domain_ref="MyDomainLib::MyDomain">
            <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>
            <data_writer topic_ref="HelloTopic" name="MyWriter" />
        </domain_participant>

If you have the settings already in an XML profile you can also specify that the ParticipantQoS should inherit from it as in:

       <domain_participant domain_id="0" name="PubDomain" domain_ref="MyDomainLib::MyDomain">
            <participant_qos base_name="Hello_Library::Hello_Profile"/>
            <data_writer topic_ref="HelloTopic" name="MyWriter" />
        </domain_participant>

Either way it must be explicitly defined in the XML definition of the domain participant.

Gerardo

Top