LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

tcp reference is lost

Solved!
Go to solution

I am in asumption that the shift register will remember the last value. My  shift register is not passing TCP reference to TCP function. I believe it is to do with property setup. Can sombody help the VI is not making a valid connection. 

Download All
0 Kudos
Message 1 of 13
(3,638 Views)
Solution
Accepted by topic author ssnp

In your example - you need to wire the Port number to be a valid port (nonzero) and the IP address of the device you are connecting to.

 

I tried connecting to a webserver (port 80) running on my PC (localhost) and it ran without error.

 

You need to see where the error is actually being generated - it's from the first call that opens the port.

 

Your uninitialised shift register will hold the TCP reference just fine. As an aside, it's more common to use a while loop with a true wired to the stop condition than a for loop for 'functional globals'/'FGVs'/'action engines' - even though it's functionally identical to your code.


LabVIEW Champion, CLA, CLED, CTD
(blog)
0 Kudos
Message 2 of 13
(3,616 Views)

If you use the default port of 0, TCP Open returns an error; the reference will be invalid.

 

Your test VI does not set the remote port, so you always get an invalid reference.

 

EDITED: need to improve my speed in resonses 😞 

 

remote port or

service name can accept a numeric or a string input. remote port or service name is the port or name of the service with which you want to establish a connection. If you specify a service name, LabVIEW queries the NI Service Locator for the port number that the server registered. If you wire a value of 0, LabVIEW returns an error.


Now is the right time to use %^<%Y-%m-%dT%H:%M:%S%3uZ>T
If you don't hate time zones, you're not a real programmer.

"You are what you don't automate"
Inplaceness is synonymous with insidiousness

0 Kudos
Message 3 of 13
(3,613 Views)

Your real problem is being hidden by the Clear Error inside of the Read case.  You really should add a case structure around the read code so that you do not perform that action if you have an error coming in.


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 4 of 13
(3,599 Views)

A coulpe of things

First-  You have some very bad habits.  Learn to use Ctrl+U and watch your panel sizes.  GET an error case around your action engine! (See Below RE: here's the bug) Use a while loop with a T constant wired to the conditional terminal (or a feedback node)

Capture.PNGCapturex.PNG

Wow much better- now I can read it- and see the bug right there!  You never wired Remote Port or Service name and forgot to make that terminal "Required" - then left it as a default "0" which will cause TCP Open Connection to throw an error every time.

 

EDIT: Come on guys I took the time to clean up the code!  (Beaten 3x must be a record) @ Tim What took you so longSmiley LOL


"Should be" isn't "Is" -Jay
0 Kudos
Message 5 of 13
(3,590 Views)

Jeff·Þ·Bohrer wrote:  You never wired Remote Port or Service name and forgot to make that terminal "Required" - then left it as a default "0" which will cause TCP Open Connection to throw an error every time.

Does it really need to be required?  The issue here with the Action Engine is that there are inputs that are only needed for 1 case.  What I would recommend here is to create wrapper VIs that call this Action Engine.  Then the API the users of the library see are very simple: no need to keep track of which case you are calling, don't have to worry about which inputs are needed for which case, just looks cleaner.  And to made it even better, but all of these into a library (lvlib) and make the AE and its enum private to keep others from accidentally directly using the AE.


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 13
(3,583 Views)

@crossrulz wrote:

Jeff·Þ·Bohrer wrote:  You never wired Remote Port or Service name and forgot to make that terminal "Required" - then left it as a default "0" which will cause TCP Open Connection to throw an error every time.

Does it really need to be required?  The issue here with the Action Engine is that there are inputs that are only needed for 1 case.  What I would recommend here is to create wrapper VIs that call this Action Engine. 


Exactly.  In my head I had allready done this

Engine.png

Open.pngExample.pngwrite.pngRead.pngClose.png

 

VI Documentation and Icon clean-up left for the OP


"Should be" isn't "Is" -Jay
0 Kudos
Message 7 of 13
(3,553 Views)

I am getting error code 63

 

0 Kudos
Message 8 of 13
(3,548 Views)

@ssnp wrote:

I am getting error code 63

 


"The network connection was refused by the server."

 

Whoever you are trying to connect to needs to be listening for the connection.  That is llikely your problem.


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 9 of 13
(3,528 Views)

it was a wrong wiring.

thanks for help to all of you

  One question is still in my mind how long I can expect  the TCP connection is valid. It is till the TCP  reference is close and can use same connection in my other vi. If yes then how

0 Kudos
Message 10 of 13
(3,506 Views)