LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Network Stream across different Labview versions

Out of sheer curiosity, assume I have two PCs (A and B), PC-A has Labview 2023 and PC-B has Labview 2017, I have developed a Network Stream Host & Target code on PC-A, then I saved the Target VI to save for previous version in order to run it with PC-B, now if I try my Target and Host VI will connection be established or no?

 

0 Kudos
Message 1 of 11
(853 Views)

Shared variables are.

 

Can Network Shared Variables Communicate Between LabVIEW Versions? - NI

 

I put my money on 'yes'. Just my 2 cents.

0 Kudos
Message 2 of 11
(826 Views)

I agree with @Wiebe that it should work.  I've used Network Streams for LabVIEW RT Projects for a decade, and when I migrate to a new (typically later) version of LabVIEW, the (older) code "upgrades" nicely without problems.  I don't recall going to an earlier version of LabVIEW, as you describe, but I would expect the same to be true.  At the worst, you should be able to simply print out the LabVIEW 2023 Block Diagram, open LabVIEW 2017, and manually re-code the (relatively few) VIs you need to create the Streams and manage them.

 

If it doesn't, post your 2023 VIs "saved for Previous" as LabVIEW 2021 and LabVIEW 2019 (I'm running 2019 mostly, but have a test system with 2021) and let us take a look.  Note that going back 6 years is a bit of a stretch ...

 

Bob Schor

0 Kudos
Message 3 of 11
(786 Views)

I also feel that by now it would have been less work to actually try...

 

EDIT:

So, it turns out it doesn't work.

 

I tried various combinations of host\target from the Simple Network Streams.lvproj example

 

I witched host and target between LV13, LV18 and LV20. Non worked (except between the same version).

0 Kudos
Message 4 of 11
(749 Views)

So based on Wiebe's "experiment" (that "Scientist-speak" for what an Engineer would call "test") that for Network Streams to work, the Reader and the Writer must both use the same version of LabVIEW, the "Solution" for the Original Poster is --- to have the Host and Target codes in the same LabVIEW Project, and opened with a single version of LabVIEW.  [Come to think of it, how can you have a Real-Time Project that doesn't have a Project file, which is "locked" to a specific LabVIEW "Version" (like 2019 SP1)?]

 

Bob Schor

0 Kudos
Message 5 of 11
(734 Views)

The main problem is that Network Streams are a proprietary messaging scheme that NI can very easily change every version of LabVIEW.  So I don't trust using them between versions.  Just another reason I just use the plain TCP/IP protocol, where I am the one in control of the messaging protocol.


GCentral
There are only two ways to tell somebody thanks: Kudos and Marked Solutions
Unofficial Forum Rules and Guidelines
"Not that we are sufficient in ourselves to claim anything as coming from us, but our sufficiency is from God" - 2 Corinthians 3:5
0 Kudos
Message 6 of 11
(729 Views)

@crossrulz wrote:

The main problem is that Network Streams are a proprietary messaging scheme that NI can very easily change every version of LabVIEW.  So I don't trust using them between versions.  Just another reason I just use the plain TCP/IP protocol, where I am the one in control of the messaging protocol.


Not only can they change the protocol at will whenever they wish, I'm pretty sure that there is actually a version number exchanged when establishing a stream and if the both sides don't match it is refused right away. Not because they might be actually really incompatible but more as a precaution: If you don't allow different releases to communicate together, you do not have to implement tests that this is still working!

Rolf Kalbermatter
My Blog
0 Kudos
Message 7 of 11
(706 Views)

@crossrulz wrote:

The main problem is that Network Streams are a proprietary messaging scheme that NI can very easily change every version of LabVIEW.  So I don't trust using them between versions.  Just another reason I just use the plain TCP/IP protocol, where I am the one in control of the messaging protocol.


I gave them a try once, and soon changed to TCP/IP.

 

Biggest showstopper was that a network stream reconnect caused my single cycled timed loop sync'd with the scan engine to miss cycles.

 

They look like queues, enqueueing elements, FIFO. But if there's a disconnect, all enqueued data is lost. So I needed to wrap the the data in my own queue anyway... Network streams didn't offer anything to me that wasn't easy to DIY.

0 Kudos
Message 8 of 11
(699 Views)

Are you sure Network Streams don't work?  I made Messenger Library work between versions and it is a straightforward task to negotiate the common protocol version.   

0 Kudos
Message 9 of 11
(682 Views)

I have two version of labview installed on my pc - LV2016 & LV2023. I intially had made the code in 2023. I then saved to 2016 version using save for previous version.  Then I ran my host using LV2023 and Target using LV2016. Kept the IP in the url as localhost. Did not work. 

 

I'm confused now because so of response say it should and some day it shouldn't work.  Can anyone please try it on two different systems using different version?

 

 

0 Kudos
Message 10 of 11
(678 Views)