sending large chunks of data from CVS to host using TCP/IP

[ldhertert]

I'm attempting to send images from a CVS system to a host computer via TCP/IP. I made a fairly complicated VI to control this and ran into a wall. So I constructed two very simple VI's (a host and a client(RT)) in order to test the network communication. These VI's don't even communicate with the camera, they just try to send (and receive) an array constant that was created from an image. I can't even get this simple VI to work, and I have a feeling I'm missing something important. If someone could take a look at these VI's (LV7.0) and let me know what I'm doing incorrectly, I'd appreciate it very much. I believe they're fairly self explanitory/documented, but if you have any questions let me kn
ow. Thanks in advance.
-Luke Hertert

[Greg G.]

Can you please elaborate more on the problems you have when you run the two attached VIs? I tried them and they worked for me. The only problem I saw with them was that you send an array of U8s from the RT side and read them as an array of I8s. What were you expecting the intensity graph to look like when everything succeeds?

[ldhertert]

Good call on the U8/I8 mixup, but that's not the problem that I'm having. When I send the array size (or any data structure that is fairly small) it gets through fine. But I get a timeout error whenver I try to send anything larger (like that array). This is somewhat odd, however, because I've set the timeout to something way higher than it should need to be (ie 2 min+). On the intensity graph should be an image that we took with our camera of a sample (just a square/rectangle with a dark background).

[Greg G.]

Ok, I figured it out. The reason I couldn't reproduce this before is that I was using labview 7.1. This was a bug that was fixed in labview 7.1. It occurs when, on an RT target, a VI waits for a connection, and then immediately tries to write data to that connection when it is opened (which is what you are doing). There are two ways to get around this:

1) Add some sleep right after the "TCP Listen". In my tests 2ms was sufficient, but you can play around with it and see how much is neccessary. It varies by target. If you put in 10ms, you would almost certainly be safe. Just make sure the wait takes place after the TCP Listen and before the first TCP Write.

2) Upgrade to labview 7.1. This bug is fixed in the newer version.

[ldhertert]

I'll try the wait, but I'm pretty sure that's not the reason I'm getting an error. I'm actually using 7.1, I just saved the files as 7.0 so everyone would be able to view them. Also, why would the data size write work correctly if this were the problem? from what I understand of your explanation, if this were the cause I shouldn't be able to write that data.

[Greg G.]

Well, if you were actually using 7.1, then I'm stumped. The bug I mentioned is definately fixed in 7.1. And I ran your VIs on my system and it all worked fine. No timeouts or errors. I was only able to reproduce it in 7.0. Sorry I don't have any other suggestions.

[ldhertert]

Turns out that it was a networking issue. I had the computer and the RT system directly connected with a crossover cable, but as soon as I threw a hub in there, everything worked like a charm. The people at NI said it might have been a duplex setting issue when I had it directly connected.