Can't create Network Stream connections between Win and RT

[David_Staab]

In the attached example, why can't I get all four links to connect without errors? Here's a representative example of the result I'm getting:

[Bob_Schor]

Error -314004 is the "Failed to Connect" error.  You only get this if (a) you have a timeout enabled (which you do) and (b) your endpoints fail to connect (which is probably what is happening).

I suspect the problem is the URL.  The structure is a little unusual.  The format is \\<Host name>:<Context Name>\<Endpoint Name>.  You only need the Host name part on one of your applications -- I usually put it on my "host", so the <Host Name> is really the name of the "Remote".

The <Context Name> is the name of the application running the program.  Notice there is a colon, not a slash, that separates <Host name> from <Context name>.  The Context Name, if not specified, seems to default to ":LabVIEW.exe", i.e. by default it specifies the LabVIEW Development System (this is probably why the Examples included in LabVIEW don't have a Context name in their URLs.  If you deploy an executable, then the Context Name will be the name of the executable (preceded by the colon, of course).

Hope this proves helpful.  I'm just beginning to "play" with Network Streams, myself.  Seems like a very flexible and powerful tool.

[David_Staab]

Hi Bob -

Yes, one pair of the streams failed to connect. That's what I'm asking about. 🙂 The timeout is more than enough for them to connect if they will, as evidenced by the pair that did successfully make a connection. (I've also used Network Streams in a couple of applications already, and even across subnets they normally connect within 1 second, so a 10 second timeout isn't an issue here.)

Yep, I'm aware of the Context Name. But as the Network Streams whitepaper says, and as you reiterated, the default context is assumed when it's ommitted from the URL. That's why one pair of the stream was able to connect in my screenshot. And I'm running my example  in the dev environment anyway, so contexts shouldn't be necessary in the URL at all.

If you like, you can grab the example I attached and run it yourself to help me investigate. 😉 Do all the endpoints connect successfully on your Win/RT setup?

On a side note, can anyone tell me how to query the current VI's context? I'm certain there's a Server or Scripting node somewhere that does it, but I can't find it at the moment...

[Bob_Schor]

To get the Local Context, wire a VI Server Reference ("This VI") to a Property Node, get the Owning App property, wire that to a Property Node and get its Name.  Put this after the colon.

[Bob_Schor]

Found your bug.  Reader and Writer names do not start with a slash -- the slash is the separator.  When you format the "full url", use a format string of //%s/%s (put the slash in the format), and have your reader and writer be "Link2/RTWriter" and "Link2/HMIReader".

[David_Staab]

Hi Bob -

Thanks for the node to get the context. And good catch on the leading '/' in the endpoint names, but that didn't fix the connection issue. I'm still getting the same result: one pair of connections is created without a problem, but the other pair fails with a timeout error. (This time, the "link1" connections worked and the "link2" connections failed: the opposite of the result in the original post.)

[Bob_Schor]

That's strange -- wonder if (some of) the problem is your RT device.  When I tried it out, I didn't, of course, have your device, so I ran both pieces on my PC, and it worked.

One "gotcha" that has bitten me more than once when dealing with RT devices is that you need to enable TCP on them, similar to what you do in LabVIEW on the Options tab.  One way is to right-click the RT Device in Project, choose Properties, and look at VI Server to make sure TCP/IP is enabled.

If everything else seems OK, try running both pieces on your host PC (use the name LocalHost instead of an IP address).

[David_Staab]

Bob -

The point of the exercise is to figure out why it doesn't work between a Windows machine and an RT. It definitely works with all the endpoints on Windows, but I'm writing RT applications. (For those interested, I'm using CompactRIO units: a 9073 and a 9012.)

"Enabling TCP" is an action you have to take on VI Server, not on Network Streams or basic TCP/IP VI functionality. I'm not using VI Server in this example.

[Bob_Schor]

Sorry for trying to be helpful -- didn't realize it was only failing on RT system.  [Did it work with the slashes in place on your PC?].

I was curious enough that I tried it on my LabVIEW 2010 system connected to a PXI.  I built a Project, deployed the RT code (with the slashes fixed), and (before I tried to run it) wondered idly why you make both the Host and the Target have both active and passive endpoints.  [I was noticing that this means there are two IPs you need to worry about, whereas if, say, the Host had all the active endpoints and the Remote all the passive, the Remote wouldn't need to know anybody's IP, including its own].

Then I ran your code, and saw (as you did) that the Link2 errors all lit up.

So I put all the active endpoints on the Host, all the passive ones on the Remote, removed the HMI IP from the Remote, and everything runs just fine on this RT system.  No errors -- it connects and (appropriately) stops within a few hundred milliseconds of starting the Host (having started the Remote a second earlier).

[David_Staab]

Yep, as a workaround, I ended up doing the same thing: all active endpoints on the host. However, that doesn't fit my ideal communication paradigm, so I'd like to know (from someone at NI, hopefully) why the example I posted doesn't work.

I do appreciate your responses, by the way. It's just that I've already investigated this issue on my own time and have boiled it down to the ciritcal ingredients before posting here. What I want to know is exactly what's posted at the top, and I want to keep the conversation from straying in another direction (like "Why don't you just do it another way?").