TCP Listener/Wait On/Close/Open

[Graeme]

Hi everyone,

Well this is my first post here so here goes. LabVIEW (7.1, 8.0, 8.20 if I'm lucky) user for only a year and a half. You can probably see my details as I filled them in for registration - see my background! Addicted to LabVIEW though - it's brilliant!

To the point. In a sub-VI I use a TCP Create Listener followed by a TCP Wait On Listener (server). When the connection is made I then use a TCP Read to get the data. Afterwards I close the connection (TCP Close) - OK so far. The next sub-VI opens (trys to) a TCP Open Connection (client) using the same port as in the previous VI. Says it can't. The server has refused the the connection or the port is already in use. Can't remeber which as I'm writing this from home, not at work, sorry.

Anyway, found an NI page that says if you've used a Create Listener and a Wait On Listener closed with a TCP Close you can't open a connection to that port again until LV is shut down, unless you've close the connction in a rather strange way that the page offers an example for.

Anyone any experience of this? Any comments would be most welcome.

[JackHamilton]

Reliable TCP/IP is not easy, goto www.labuseful.com and download "robust TCP/IP" this is a very reliable 24/7 TCP/IP connect, disconnect, reconnect VI set. (If I say so myself)

Regards

Jack Hamilton

jh@Labuseful.com

[stars_n_moons22]

Hi Graeme,

I'm having some similar problems with TCP connections. (Unfortunately, it's code I've inherited from someone else and let's just say it's not as optimised as it could be...!)

I've encountered a situation exactly as described in the NI page that you talked about. We create a listener and then do a wait on listener. On closing the connection we only close the Listener ID and not both the Listener ID and Connection ID and we've been wondering why we then have to shutdown LV completely before we can establish a new connection to that port!

I'm going to be trying this fix in my code and then doing some tests to make sure it works so I'll keep you posted on the outcome.

Sorry I can't offer any more help than that at the moment, but Good Luck in sorting your problem!

Sam

[eaolson]

I've encountered a situation exactly as described in the NI page that you talked about. We create a listener and then do a wait on listener. On closing the connection we only close the Listener ID and not both the Listener ID and Connection ID and we've been wondering why we then have to shutdown LV completely before we can establish a new connection to that port!

Why not just use TCP Listen as opposed to Create/Wait? It seems to largely do the same thing, but you can close the TCP connection ID it returns and recreate it later with no problems.

[Graeme]

Thanks for the replies so far everyone. I've only just got back to the forum after a few days away so have only had a quick look at the posts, not had a chance to try the suggestions yet, but will ASAP. The example I referred to, but stars_n_moons22 was good enough to link to, was cited as poor but due to some comments posted on it it was possible to gather the following.

1) When using the TCP Wait On Listener you must close the connection ID AND the listener ID (I wasn't doing the latter).

2) You may need a short time delay to allow the connection to close before re-opening it.

My application involves more than just TCP. I've got it running so it works about half the time!!! Timing may be an issue with some other aspects of my VIs. It's a real can of worms. To boot, I'm not convinced that my company's product that I'm trying to communicate with boots up in the correct state every time.

Jack Hamilton, I'll check it out. When you say "reliable TCP/IP is not easy" do you mean in general or just via LabVIEW?

eaolson, well...take your point. I notice most of the LabVIEW example VIs use the function to which you refer and don't use they way I've done it. I've had a look inside the TCP Listen function to see what made it tick. To be honest, it was a bit beyond me.

BTW (off topic), why do NI create these white functions that we can open? Why not just make them regular functions? It always gives me the impression that the regular functions are not quite there and they've had to come up with a fix.

Anyway, thanks again. If I find out more I'll post.

Regards, Graeme.

[stars_n_moons22]

Hi Graeme,

Just to update you, I had a closer look at my code and I was already closing the connection IDs as well as the listener IDs but I don't think my program was being left long enough before trying to reestablish the port connection as you mentioned in your post.

As for the white functions, I tend to think of them as helping hands to get me going on something new. In some instances I find that they can get you up and running by getting most of what you want done without having to dive straight for the advanced functions. But also, if I get stuck on something a bit more advanced I can delve into these for some hints and tips on what I might be missing from my own code. Just my opinion tho!

Sam