LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

How to communicate between LabVIEW and NXG?

Solved!
Go to solution

Hi all,

 

I'd like to know how I can send messages between LabVIEW 2019 and LabVIEW NXG in a Producer-Consumer style.

 

So far I've tried the following.

 

Named Queues: Both ends get created, but they don't see each other. That makes a lot of sense since they exist in different memory pools. Is there an option I missed somewhere?

 

Network streams: The second application that gets started throws Error -314350, which I interpret to mean: They see each other, but something went wrong. My program is valid because the exact same program works when communicating between two LabVIEW 2019 VIs.

Also, why are the network streams under "compatibility"? Is there something better now?

 

SystemLink: I read in this thread that SystemLink Messages are another option, but from what I read it seems to be overkill to use an intelligent systems and data management software platform to send a message between each other. In addition, I had some trouble getting the examples to run.

 

I'm open to any and all suggestions. Thanks!



Remember Cunningham's Law
0 Kudos
Message 1 of 8
(814 Views)
Solution
Accepted by topic author PeterFoerster

Hi Peter,

 

what about simple UDP or TCP communication?

Best regards,
GerdW

using LV2011SP1 + LV2017 (+LV2020 sometimes) on Win10+cRIO
Message 2 of 8
(802 Views)

Yeah, I thought about that. I guess the main reason is that I've never implemented both sides of TCP communication and wanted to stick with the stuff I know. Can I queue messages with TCP?

 

Edit: Yes, you can.



Remember Cunningham's Law
0 Kudos
Message 3 of 8
(796 Views)

Hi Peter,

 

I usually use even more simple UDP to communicate between PC and cRIO targets, but also between several PC-based executables.

 

You can queue messages with TCP, while UDP behaves more like notifiers…

Best regards,
GerdW

using LV2011SP1 + LV2017 (+LV2020 sometimes) on Win10+cRIO
Message 4 of 8
(792 Views)

OK, this works well and I now have a solution that works.

 

The question remains: Why don't the network streams? They're based on TCP with all the bells and whistles, that I'd end up implementing anyway.

 

Another thing that would be nice for this use-case is sharing typedefs between NXG and LV...

 

 



Remember Cunningham's Law
0 Kudos
Message 5 of 8
(778 Views)

Hi Peter,

 


@PeterFoerster wrote:

Another thing that would be nice for this use-case is sharing typedefs between NXG and LV...


I guess you know the IdeaExchange board for (classic) LabVIEW?

(AFAIK NXG has it's own feature to provide feedback to NI.)

 


@PeterFoerster wrote:

The question remains: Why don't the network streams? They're based on TCP with all the bells and whistles, that I'd end up implementing anyway.


You should escalate this to your NI support! (Do you have an active SSP?)

Best regards,
GerdW

using LV2011SP1 + LV2017 (+LV2020 sometimes) on Win10+cRIO
Message 6 of 8
(775 Views)

Yeah, I do. I also have another whopper to help them pass the time in all of this. 😆



Remember Cunningham's Law
0 Kudos
Message 7 of 8
(773 Views)

OK, just in case someone has a similar problem and finds this thread.

 

In the Simple Network Streams example, the endpoint addresses are specified as: //<IP>/<context>/<name>

 

For it to work between NXG and 2019 (or between different instances of LabVIEW) they need to be:

//<IP>:<context>/<name>

Additionally, the <context> needs to be different for reader and writer and you might have to specify the full path including IP.



Remember Cunningham's Law
0 Kudos
Message 8 of 8
(632 Views)