I've been able to create a reader that subscribes to the ping topic created by RTI's utilities.
However, I keep failing at recreating the data types within LabVIEW. I keep getting met with type mismatch in the RTI admin console. The participant will show up, but not be able to join.
This is the IDL for one of the topics in question.
typedef unsigned long Address;
typedef unsigned short ByteCount;
struct RWMeta {
Address m_baseAddress; //@key
ByteCount m_byteCount;
};
struct ReadRequest
{
RWMeta m_meta;
};
The LabVIEW control that I'm using to generate the complex functions using your tool is attached. (note: I have tried them both with and without the nested typedefs... this was just the latest shot-in-the-dark. It use to be a simple cluster with the two normal controls within it)
When I switch to the data shown in the DDS Data Type tab in the admin console I see the following difference. Top is the data type created by our developers in real time using the above IDL. The bottom is LabVIEW's.
Any ideas on what is causing the mismatch and how to alter my controls to match? Thanks in advance.
| Attachment | Size |
|---|---|
 readrequest.zip | 8.43 KB |
Hi jwils112
If you want your type to be keyed you have to add the //@key directive to the top level struct like:
struct ReadRequest
typedef unsigned long Address;
typedef unsigned short ByteCount;
struct RWMeta {
Address m_baseAddress; //@key
ByteCount m_byteCount;
};
struct ReadRequest
{
RWMeta m_meta; //@key
};
So the key directive can be tracked from the top level to the nested field. Please have a look at User's Manual section 3.3.9.1 "The @key Directive".
Then in LabVIEW in the Advanced Reader Configuration, you have to set the keyName field with m_meta.m_baseAddress. This way you indicate to use the field m_baseAddress of the struct m_meta as a key. You can have a look at the section "Adding Internal Cluster Fields as Keys (Nested Keys)" of the RTI DDS LabVIEW Toolkit Getting Started Guide for more information.
Regards
Ismael
Thanks for the reply. I got the key to recognize and show up in the admin console.
However, it seems that wasn't the source of my mismatch. Doing this also added a key mismatch error on top of the type mismatch (it's claiming the writer doesn't have a key)
Here is the match analysis. Before adding the key, I only had the same type mismatch shown in the picture.
It says the DataWirter is not keyed. Both need to be keyed. Did you add the key directive to your DataWriter top level struct in the idl and regenerate the code?
struct ReadRequest
{
RWMeta m_meta; //@key
};
Remember the if you only add the key directive to a nested member, but not in all the way through the top level struct to the nested member the resulting type won't be keyed.
Hi Josh,
There are a few things here:
struct m_metaType {Address m_baseAddress; //@key
ByteCount m_byteCount;
};
struct ReadRequest {m_metaType m_meta; //@key
};
Attached the IDL and a LabVIEW compatible writer.
Angel.
Yes, thank you both. The keys existance was causing the type mismatch.