Multiple netstream clients in a reentrant VI

[confra82]

Hello,

I am developing an application which has to communicate with ate least 2 remote devices (cRio) which run a netstream server. I have designed a VI which implements two netstream client (reader and writer) and a subVI in a subpanel. Firtsly I have tested it in non-reentrant mode and everything worked, then I have edited the top level and the subVI in reentrant and everything worked.

However when i attempt to run two instances of the top level (in order to read from two devices) something goes wrong: the top level continue its execution but the subVI in the subpanel start the exectution only if i stop the nestreams. I have disabled (with a disable structure) the netstream in the top level and it again works properly.

My question is: may I run two Create Network Stream Endpoint in two instances of the same VI simultaneously?

In the LabVIEW help I can see that two writer can be executed to send data toward two different computer, it seems to be similar to my situation, isn't it?

Many thanks

P.S. I cannot post my code, it is very large and counts so many VI.

[Bob_Schor]

---

@confra82 wrote:

P.S. I cannot post my code, it is very large and counts so many VI.

---

This is an excellent time to learn to develop/debug "interesting cases".  Write the World's Simplest Test Routine, consisting of a Main and two simple Clone routines.  Create a very simple Network Stream (I presume this is what you mean by "netstream") task, perhaps a Clock that ticks once per second on receipt of the next Tick number and echoes it back to the Main, with some slight alteration in the task for the two Clones so you can distinguish them.  Keep everything small and simple.

Hmm.  I suspect I know the problem, but it sure would help to have the WSTR (see Sentence #2) to demonstrate this.  If this is a LabVIEW RT issue, where you have a Host routine on a PC and a single Remote on a cRIO that needs to communicate with two Clones running on the cRIO, you should probably do the following:

• Design Network Streams to communicate between Host and Remote.
• The communication stream needs to indicate which Clone is involved.  When I've used Network Streams, I implemented them as Message Handlers -- if you do the same, one element of the Message should be the Clone involved.
• Now it's simple.  Either the Host or the Remote (depending on your Design) decides Which Clone Gets the Message.  Communication on the Remote between the Top Level code (which has the Network Stream VIs) and the Clones is handled by Queues, which are specific to whichever Clone needs to get it (recall that the recipient Clone will be specified by an element of the Network Message).

Before you start tearing apart your "very large code with so many VIs", do take the time to write a small, simple Test Suite.  It is almost guaranteed to not work the first time you try it, and it is much easier to debug a routine that consists of a dozen VIs, none of which is larger than 640 x 480 pixels, than "very large code", especially if the latter is not under some form of Source Control.

Bob Schor

[confra82]

Many thanks Bob_Shor for your suggestion,

When I have designed the network stream comunication everything was tested and it work properly.

The issue is in the double instance, I have found the why, it is my fault, I'm sorry.

By the way, never attempt to open two network stream toward the same address.

The behaviour of the VI deceived me.

[Bob_Schor]

---

@confra82 wrote:

Many thanks Bob_Schor for your suggestion,

By the way, never attempt to open two network stream toward the same address.

The behaviour of the VI deceived me.

---

Oops.  In my LabVIEW RT project, I have 4 (> 2) Network Streams connected to the same address.  Two form a bi-directional Message Channel, and the other two stream sampled Analog Data (synchronous, known data rate) and "Event" Data (asynchronous, "when-it-occurs") from the Remote to the Host.  Of course, all of the Streams have unique names ...

Bob Schor

[confra82]

Sorry for the missing letter in your name.

In my case the whole URL matches.

Maybe in your case the name of the endpoint server get the network stream properly work.

[Bob_Schor]

My Host -- PC.  My Remote -- PXI running LabVIEW RT on PharLap OS.  The two machines each have a NIC dedictated to the Network Stream traffic, and are connected by a standard Cat5 Ethernet cable.

While my "needs" are for four independent Network Streams, I could easily add more.  If you follow my suggestion and write a "tiny" test routine, putting in the Network Streams you are trying to set up, and attach your Test VI, we could (probably) point out ways you could "make it work".  If you have the same URL on multiple Streams, you are doing it wrong (and hence your code doesn't work).

Bob Schor

[confra82]

With a deeper debug I find out that the issue was generated by timeout connection of the networkstream.

I mean during the software test I do not connect the pc to the network devices, then the network streams have to wait the timeout before attempt to reconnect. When the application run only two network streams (reader and writer of a test page) they properly wait the timeout, instead when a new test page is open and 4 network streams run (reader and writer for every test page) some network streams do not wait the timeout and its cycle run as quick as possible resulting in a loss of performance of the system.

Why is not take into account in some case the timeout in the "Create Network Stream Writer/Reader Endpoint"?

EDIT: My URLs erroneously match, obviusly every cRIO run the same network stream with a specific IP

[Bob_Schor]

I can tell you how I (successfully) initialized my four Network Stream connections.  It worked as follows:

• The Remote was a LabVIEW-RT system running on a PXI Chassis.  The PXI, when started, is set to run the Remote code automatically, so it would be running when the PC wanted to initiate the connection.
• The RT Streams consisted of one Reader (a Message Channel) and three Writers (a Message Channel and two Data Channels).
• The RT code had Initialize Network Streams as one of its first VIs.  This VI looped repeatedly until all four Network Streams were established (which required, of course, the Host to "reach out" and initiate the contact).  The code consisted of one Create Reader Endpoint and three Create Writer Endpoint, all executing in parallel, and with timeouts of 15 seconds, looping to "try again" unless all four successfully connected.
• The Host side also had an Initialize Network Streams VI, executed fairly early.  Each of the Create Reader/Writer Endpoint function had the IP of the Remote specified (so we only needed to know the IP of the unique, in our case, PXI Chassis we were trying to contact).  I arranged the four Endpoint functions to execute serially, with 15 second timeouts, and placed this "attempt to connect" code inside a For Loop that would repeat 3 times if it couldn't connect.  If a connection was established, this routine would exit and allow the rest of the Host code to proceed, knowing that all 4 Network Streams were established and runnning.  Otherwise, it would return an Error, which the Host routine would handle as appropriate (it usually meant that someone had turned off the PXI Chassis, so the Remote was not running).

Bob Schor

[confra82]

Hi, in the image you can see what I have done to solve the issue, a kind of check on the timeout of the endpoint.

Is this solution not recommended?