Type mismatch

7 posts / 0 new
Last post
Offline
Joined: 08/24/2018
Posts: 6
Type mismatch
AttachmentSize
Package icon readrequest.zip8.43 KB

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.

Data Difference

Any ideas on what is causing the mismatch and how to alter my controls to match? Thanks in advance.

Ismael Mendez's picture
Offline
Joined: 07/03/2017
Posts: 17

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.

Advanced DataReader Configuration

 

Regards

Ismael

 

Offline
Joined: 08/24/2018
Posts: 6

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)

Read Request Type Mismatch

Offline
Joined: 08/24/2018
Posts: 6

Match analysis

Here is the match analysis. Before adding the key, I only had the same type mismatch shown in the picture.

Ismael Mendez's picture
Offline
Joined: 07/03/2017
Posts: 17

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.

 

 

Offline
Joined: 04/23/2014
Posts: 45

Hi Josh,

There are a few things here:

  • LabVIEW:
    • The LabVIEW type is not keyed, therefore C/C++ application and LabVIEW won't match. Sections "4.5Lesson 5—Using Keyed Types (RTI Shapes Demo)" and "4.6Lesson 6—Used Nested and Multiple Keys" of the Getting Started Guide explain how to set up keyed types. Note: we should generate an Advanced 'Type of Generation' in the 'Complex Type Generator'.
    • As you can see, the type of m_meta is "m_metaType" in the LabVIEW part and RWMeta in the C/C++ part. As we cannot modify the LabVIEW type name, we should do this in the idl file:

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.

Offline
Joined: 08/24/2018
Posts: 6

Yes, thank you both. The keys existance was causing the type mismatch.