Network Stream "Warning" 314050

[Southern_Cross]

Attached is a project the reproduces a Network Stream "warning" 314050. Since this warning stops my network communcation on the afflicted stream it has crippled my application. I classify this as a nasty bug. I've been unsuccessful in resolving this bug for many days now and therefore turn to the community for help. Hopefully I'm just doing something stupid...

I'm using LabVIEW 2014 SP1 in an application that uses 5 network streams going between a host PC (Win7) and a cRIO-9082 (Phar Lap). One (or more) of the streams is throwing a warning 314050 from the "Read Single Element From Stream" function on the reader endpoint. The explanation of this warning is "The Network Streams Engine does not exist." However, the other streams are communicating just fine so the Stream Engine does in fact exist. And, if I read the stream properties (in a parallel loop), "Is Connected" equals TRUE on all streams (including the stream with the warning). 

The attached project includes a PC and RT VI. As long as your VI Server is active and you have deployed the RT VI the only thing that you need to do is enter the appropriate IP address for your RT target in the "Target IP Address" control on the PC VI. Then run.

I have seen a few runs where the error is not reproduced. Run it for a few seconds multiple times and you will see the "warning" show up in one or more of the error clusters on either the PC or the RT front panel. You'll also notice that all communication stops on the afflicted stream (as verified by the "Total elements Read/Written" for that stream saturating at the buffer size of '10'). 

I've reproduced the bug on a VxWorks based cRIO-9022 as well. I can only reproduce this error when I have 5+ streams (although I have not exhaustively investigated this point). This is the minimal number of streams for my application.

Another point, there is a single private network switch (D-link, DGS-105) between the PC and the RT system(s).

Any insight you can provide would be greatly appreciated.

[Bob_Schor]

I'm going to try to take a look at your Network Stream problem.  I use 4 streams for an RT Project using a PXI controller (so I'll port your code to my PXI):  two Streams are Message Streams from Host to Remote and Remote to Host (both running the Queued Message Handler), a third streams sampled data (16-24 channels at 1KHz) from Remote to Host, while the fourth streams Events (asynchronous Time-stamped and "identified" things such as Digital signal changes, State Machine "state" changes, Errors).

One immediate problem that I have is I do not have 15 monitors hooked up in a 5 by 3 grid, which is necessary to see your Block Diagram.  If I can't get it to fit on a single 1280 x 1024 monitor, I'll give up (but if I can get my code to fit, I can probably do it for yours, but be warned -- there will be "extra" VIs present).

Bob Schor 

[Bob_Schor · Accepted solution]

Aha, I may have found it without having to do "surgery" to your code (shudder)!  I notice that you start with the Remote IP Address, then "tell" the Remote the Host's IP Address, using both addresses in setting up your Network Streams.

When I built my 4 streams, I only use the Remote IP Address -- the Host Address never appears in the code.  Here, in summary, is how I connect:

• The RT code starts first (it is set to auto-run when the PXI turns on).  There's a While loop that attempts to connect four Streams, one Reader (Messages from Host) and three Writers (Messages to Host, Samples to Host, and Events to Host) -- when all the connections are established, the While loop exits, allowing the main Remote code to proceed (and to use the now-created Network Streams).  Here's a Snippet of the Remote Initialization routine:

• The sub-VIs "Reader Stream Name" and "Writer Stream Name" basically make names in the form "RT/%s/Reader" (or Writer).
• The Timeout on the Create Stream Endpoint functions is 15 seconds.  Since these are all running in parallel, if the Host isn't running or doesn't connect within 15 seconds, the loop will repeat until the connection is made.
• The process on the Host is almost identical, with several important exceptions.
• Where there's a Reader on the Remote, there's a Writer on the Host (and vice versa).
• The sub-VIs that create the Stream Names have an additional input, the RT IP, and make both Writer and Reader names.  For example, Writer Stream Names creates "UI/%s/Writer" and "//%s/RT/%s/Reader" (where the first String is the RT IP, the second is the Stream Name).
• The four Streams are created sequentially, not in parallel.
• The Stream-creation sequence uses the same 15-second timeout for each Stream (but now they are in series).  If the Streams fail to connect three times, the process exits with an Error (causing the Host to "sound the Alarm", otherwise the Host now starts with Streams established.

On the Host and Remote code, initializing the Network Streams takes up a 32 x 32 pixel space on the Block Diagrams (the size of the Initialize Network Stream Icons.  As you can see here, the VI's, themselves, easily fit on a single monitor screen (due, in part, to having the code for creating Reader and Writer Stream Names also encapsulated into sub-VIs).  In addition to saving valuable Screen Real Estate, "shrinking" LabVIEW code by encapsulating repetetive functions in sub-VIs makes it easier to create the code, test the code, and maintain the code.  I recommend you do some of this with your code.

Let me know if simplifying the creation of multiple streams using the techniques I've suggested here (Remote creates Endpoints in parallel, without specifying Host IP, while Host creates Endpoints in series, always specifying the Remote IP) fixes your 5-Stream problem.  It works very nicely for my 4-Stream situation, and I can't see why adding another Stream will necessarily change that behavior.

Bob Schor

[Southern_Cross]

Bob, thanks for the help.

You just helped me learn that I had a lack of understanding of how streams are supposed to be established. Even though I've successfully used them in the passed I had been creating the stream incorrectly all along and have just been lucky until now.

The issue was that only one endpoint needs to know how to link to another endpoints to make the stream.

All I had to do was delete wire for the remote URL on the endpoint create functions on the RT side and everything started working as expected. Thanks again.

[Bob_Schor]

My pleasure.  It took me several weeks of "hacking" and trying various things before the Light Dawned ...

BS

[Hooovahh]

You deserve way more than the kudos I can give for that advice.  The structure is exactly what I would want.  Each RT system doesn't need to know about where the host is they just need to startup and do their thing.  The host however should have the address of each RT it connects to.  This can be done dynamcially and ping what addresses return data, which would make for a very modular design if you have it create 2 streams for each RT system, one to the host and one from.  I would have spun my wheels for a long time to get this to work so well.  Thank you.