07-08-2015 07:17 AM
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.
Solved! Go to Solution.
07-08-2015 07:48 AM
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.
07-08-2015 07:52 AM - edited 07-08-2015 07:53 AM
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. |
07-08-2015 08:00 AM
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.
07-08-2015 08:07 AM - edited 07-08-2015 08:09 AM
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)
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 long
07-08-2015 08:15 AM
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.
07-08-2015 08:50 AM - edited 07-08-2015 08:54 AM
@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
VI Documentation and Icon clean-up left for the OP
07-08-2015 08:57 AM
I am getting error code 63
07-08-2015 09:04 AM
@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.
07-08-2015 09:31 AM
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