LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Network Stream Error -314302

Solved!
Go to solution

We have a system of five cRIO-9053s.  One is a master and four are slaves.  It uses network streams to pass basic status information from the slaves to the master.  It is one direction only.  Slaves 1 and 2 run identical code.  Slaves 3 and 4 run identical code.  The differences are minor based on the IO modules installed.  The network streams code is identical in all four slaves.  We packaged a custom VI to setup the network stream channels, and all 9053's use this VI.

 

In slave 1 (and only slave 1), the Create Network Stream Writer Endpoint function randomly generates error -314302 and will not establish communications with the master.  "The remote endpoint is already connected to another endpoint. Each endpoint can connect to only one other endpoint at a time."  We monitored the error output in the master's Create Network Stream Reader Endpoint function, and it is not generating any error.  In the master, the reader name string for each slave's Create Network Stream Reader Endpoint function is the slave's IP address so I cannot see how the remote endpoint can be already connected to another endpoint.

 

Code was developed in LabVIEW 2022 Q3.

 

Google search finds no info on this error.  Any suggestions would be greatly appreciated.

 

 

0 Kudos
Message 1 of 7
(137 Views)

This is (probably) either a Hardware or Software error.

 

Hardware suggestions:

  • Shuffle the Servant cRIOs.  Does it still fail with S1, or does it seem to be tied to an IP address?
  • Make a different cRIO the Master.  Any difference in failure mode?

Software suggestions:

  • Attach your code that establishes the connections so we can see it.

Bob Schor

 

0 Kudos
Message 2 of 7
(97 Views)

We performed an IP swap between S1 and S2.  The problem followed the IP address. 

 

Attached are screen captures of setting up the Write for the four slaves and the Read for the master.

 

stgislander_0-1732539558110.jpeg

stgislander_1-1732539589742.jpeg

 

 

0 Kudos
Message 3 of 7
(88 Views)

I've been reading the NI application note "Specifying Network Stream Endpoint URLs".  I'm thinking that my reader endpoint creation is not correct for multiple writers.

 

The VI that contains the Create Network Stream Reader Endpoint function is called for each remote node (S1->S4 and the operator panel).  The VI is set to preallocated clone reentrant execution.  I pass a string containing the IP address of the writer node into the VI, but I'm not using it. The reader tag string is the same for all four writer nodes.

 

Therefore I'm wondering how the reader knows which of the four writer nodes it's connecting to.

0 Kudos
Message 4 of 7
(70 Views)

I usually avoid network streams because of the named connection. You'll need to create a unique name for each device that would be connecting.

~ Self-professed LabVIEW wizard ~
Helping pave the path to long-term living and thriving in space.
0 Kudos
Message 5 of 7
(63 Views)

Correction to my previous:  The string containing the IP address of the writer (slave) node is also wired to the reader name input on the (master) Create Reader Endpoint function.  The writer URL input is not wired to anything.

0 Kudos
Message 6 of 7
(49 Views)
Solution
Accepted by topic author stgislander

I think we found the problem thanks to NI's ability of conditional probing of non-reentrant execution code.  We set probing for all conditions (Error, Warning, Code) and stopped execution after the first iteration. 

 

We discovered that for the slaves, the write endpoint was being created with the default writer name value from the front panel, and not the desired writer name that is determined in a different section of code.  A small wait loop with a state comparison was added.  Once the states matched, the rest of the code, including the network stream Create Network Stream Writer Endpoint function, executed.

 

So far, testing indicates that we've fixed the -314302 error.

0 Kudos
Message 7 of 7
(33 Views)