Translate Module in IDL to LabVIEW typedef for DDS Toolkit

[Confuzzled]

Hello all,

To keep my question short, if my IDL file uses modules to organize type definitions, how do I translate that naming to LabVIEW? For instance, my IDL might specify something like:

module A {

     module B {

          typedef string Type;

     };

};

Then later they'll refer to that type as below:

struct MyStruct {

     A::B::Type MyString;

     <etc.>

};

Do I need to capture the "A::B::" portion of the naming when creating my LabVIEW type definitions somehow? If so, how?

[ismaelrti · Accepted solution]

Hi,

Modules are not supported by the DDS LabVIEW toolkit. You can only use flattened data types.

You can try to disable sending the TypeCode or TypeObject. If you have the same structure in your data type in both the IDL and the CTL files, you can configure your DDS Application to be able to communicate even if your data types don’t exactly match. Use the following QoS for avoid sending the TypeObject or TypeCode:

<domain_participant_qos>

<resource_limits>

<type_code_max_serialized_length>0</type_code_max_serialized_length>

<type_object_max_serialized_length>0</type_object_max_serialized_length>

</resource_limits>

</domain_participant_qos>

Once it is disabled, check the DataReader’s and DataWriter’s registered type names that must match exactly.

[Confuzzled]

Thanks, Ismael.

This definitely works for me and I was able to get the Admin Console to successfully subscribe to the complex data type that I created in LabVIEW. 

On a somewhat related note, I'm using an IDL file in which there are different modules that define enums with the same name. LabVIEW will not allow you to use two type definitions with the same name in a VI unless those type definitions are part of separate libraries. The libraries create different namespaces, so even though the enums have the same name, the libraries place them in unique namespaces, allowing them to coexist in the same VI without conflict.

I would have avoided this if I created the IDL, but in my case I'm inheriting the IDL and can't change it due to customer requirements. If anyone runs into a similar problem, just create separate libraries for your type definitions that share a name. I discourage this architecture though; avoid needing to do this if possible.