First, I use RTI monitor to show this is the datatype of the subscriber (not LabVIEW) that I need to talk to:
enum IDL::Common::Message_type {
@default_literal
status_issued = 0,
command_issued = 1,
command_success = 2,
command_failure = 3,
command_pending = 4
};
//@Extensibility EXTENSIBLE_EXTENSIBILITY
struct Message_header {
IDL::Common::Message_type type; //@ID 0
unsigned short dest_id; //@key
//@ID 1
unsigned short dest_idx_major; //@key
//@ID 2
unsigned short dest_idx_minor; //@key
//@ID 3
unsigned short source_id; //@key
//@ID 4
unsigned short source_idx_major; //@key
//@ID 5
unsigned short source_idx_minor; //@key
//@ID 6
short action; //@ID 7
unsigned long percentage_complete; //@ID 8
unsigned long timeout_us; //@ID 9
long error_code; //@ID 10
};
//@Extensibility EXTENSIBLE_EXTENSIBILITY
enum IDL::Waveform::Receive_or_transmit {
@default_literal
receive = 0,
transmit = 1
};
//@Extensibility EXTENSIBLE_EXTENSIBILITY
enum IDL::Waveform::Frequency_type {
@default_literal
IF = 0,
RF = 1,
TRACKING = 2
};
//@Extensibility EXTENSIBLE_EXTENSIBILITY
struct Frequency {
IDL::Common::Message_header header; //@ID 0
IDL::Waveform::Receive_or_transmit direction; //@key
//@ID 1
IDL::Waveform::Frequency_type type; //@key
//@ID 2
long long frequency; //@ID 3
};
//@Extensibility EXTENSIBLE_EXTENSIBILITY
I also can see in RTI monitor that this is the datatype that LabVIEW creates:
enum typeEnum {
@default_literal
status_issued = 0,
command_issued = 1,
command_success = 2,
command_failure = 3,
command_pending = 4
};
//@Extensibility EXTENSIBLE_EXTENSIBILITY
struct headerType {
typeEnum type; //@ID 0
unsigned short dest_id; //@key
//@ID 1
unsigned short dest_idx_major; //@key
//@ID 2
unsigned short dest_idx_minor; //@key
//@ID 3
unsigned short source_id; //@key
//@ID 4
unsigned short source_idx_major; //@key
//@ID 5
unsigned short source_idx_minor; //@key
//@ID 6
short action; //@ID 7
unsigned long percentage_complete; //@ID 8
unsigned long timeout_us; //@ID 9
long error_code; //@ID 10
};
//@Extensibility EXTENSIBLE_EXTENSIBILITY
enum directionEnum {
@default_literal
receive = 0,
transmit = 1
};
//@Extensibility EXTENSIBLE_EXTENSIBILITY
struct Frequency {
headerType header; //@key
//@ID 0
directionEnum direction; //@key
//@ID 1
typeEnum type; //@key
//@ID 2
long long frequency; //@ID 3
};
//@Extensibility EXTENSIBLE_EXTENSIBILITY
Can someone tell me why they don't match? I do see that Frequency.header is a @key in LabVIEW and not in the subscriber. Could that cause it? If so, how do I fix it? Is there anything else that could cause it? Here is the "key name" input string from LabVIEW (notice that "header" is not listed, only its subvalues):
direction;type;header.dest_id;header.dest_idx_major;header.dest_idx_minor;header.source_id;header.source_idx_major;header.source_idx_minor
Have you tried adding @key to "IDL::Common::Message_header header" in your IDL? All members in the hierarchy from the top to the desired key member must have the @key label.
Thanks for the reply Ismael!
I have not tried that. I am a LabVIEW developer. I can only change the LabVIEW side. Why is LabVIEW putting @key on "headerType header"? And how do I remove it?
Hi Kenny,
LabVIEW Toolkit marks "header" as a key because there are members in "header" that are keys. So it marks as keys the whole path from the top level member to the one marked as key in your key string. You cannot remove it if one of its sub members is a key. Actually this is the correct way of doing it.
Can you verify that the keys of your type in the subscriber (non LabVIEW application) are working correctly? Probably is not taking any member of "header" as key.
Can you try as a test if by removing header.dest_id;header.dest_idx_major;header.dest_idx_minor;header.source_id;header.source_idx_major;header.source_idx_minor from your keystring in LabVIEW they match?