Problem with TCP communication in VBAI

[Vladimir_Drzik]

Hi all
I'm experiencing a problem with TCP communication in VBAI. I want to check if there is any character in the TCP input buffer, so I run the TCP I/O step with reading of one byte and just 1 ms timeout. When there is a character in the input buffer, it is correctly displayed in the TCP Comm Terminal and it is also correctly read into the local variable of the TCP I/O step (String #0). However, the step fails with timeout error. Why is this so? To make it more clear, I'm attaching an example VBAI file.

Vladimir

[ChristopheC]

Hi,

I tried your inspection and it seems to work fine. The checkbox "Inspection Fails in case of error or timeout" is enabled, which means the step is going to fail most of the time, except for the iteration when the step actually receives a byte. If you don't want the step to fail, simply uncheck that checkbox.

-Christophe

[Vladimir_Drzik]

Hi Christophe
Thanks for your reply. I actually need the TCP I/O step to fail if there is really a timeout. However, the problem is that the step fails with timeout error even if there is no timeout and a string is actually read.
Vladimir

Message Edited by vdrzik on 07-29-2007 06:37 PM

[Brandon M]

Hi Vladimir,

I took a look at your inspection, and I got it to work with no problem.  Have you double-checked your settings in Communication Device Manager?  My guess is that it is a problem with your settings.

When I ran your inspection, I set it up to read from the TCP buffer on my machine, and modified a LabVIEW shipping example VI to output the string.  Iset the following parameters in Communication Device Manager:
Type: Slave
Protocol: TCP/IP
IP Address: my current computer's IP
Port: 2055

I then ran the LabVIEW Vi, which I have attached.  I made sure the port settings were the same - 2055 for both.  I ran the VI first, because it waits for listeners, and then ran the inspection.  It passed, and I was able to verify that it was correctly reading the character by modifying the string recieved before timeout matches.  I set this value to the character in the VI, and it passed, and when I change it, the step fails.

So your code should work if the settings are valid and there is data in the TCP buffer.

[Vladimir_Drzik]

Hi Brandon

Thanks for your help. You are right, the Slave mode works for me, too. However, I need to use the Master mode. Does that work for you?

Vladimir

[Brandon M]

Hi Vladimir,

It does not work for me in Master mode.  I believe that it hs to be in Slave mode to receive characters.  Are you needing Master mode because you are sending out characters as well?

[Vladimir_Drzik]

Hi Brandon

I am needing the Master mode because the application I am communicating with is just a TCP client. Thus, my VBAI has to be a server to it. I actually don't understand why there should be a difference in the behavior of TCP I/O step in the Master and Slave modes. I think each TCP connection is always bi-directional.

The other fact is that the character reception actually works in Master mode, too. It just does not work reliably. For example, if I use timeout value 1 ms, it always fails, even when a character is actually received. If I use a greater timeout value, such as e.g. 50 ms, it works fine for most cases, but sometimes it fails again, even if a character is received. If I use a timeout value of 1000 ms, it works fine almost all the time, but still it sometimes happens that it fails. It seems to me that there is a certain time period, which is a part of the whole timeout interval. If a character arrives during this period, it is actually read out, but the TCP I/O step fails with timeout. Which seems to me as an incorrect behavior.

Regards,
Vladimir

Message Edited by vdrzik on 08-04-2007 09:34 AM

[Brandon M]

Vladimir,

The issue has been reported to R&D.  It sounds like you are correct and that this is incorrect behavior, but I will let you know what the verdict from R&D is.

[Brandon M]

Hi Vladimir,

I spoke to R&D on this issue, and in doing so, I discovered the error in my program.  The VI that I posted starts with a TCP listen, so setting the device type to Master will not work because both programs are waiting for communication.  However, if you write a VI that just sends a character when a button is pressed, and run the VBAI inspection in a loop, the inspection will fail until you press the button.

I found that this works for me 100% of the time, as long as the timeouts are properly configured for both ends.  If the connection is closed by the client, you need to make sure that there is enough delay before the connection is closed for the string to actually be written.  I found that it was possible to make a LabVIEW VI that opens, writes, and closes a connection, when a boolean becomes true, and if there is no delay, sometimes the string cannot be written before the connection is closed.

The other concern that I have is about your client application.  What is your client?  Is it a LabVIEW VI?  Is it proprietary code?  If there is some error in the communication, does your client try to reestablish a new connection?

[Vladimir_Drzik]

Hi Brandon

Can you attach the exact VI and VBAI file that worked for you 100% of the time? I would have a look at it and try it on my machine.

Regarding my client application, it is a proprietary code that connects to the VBAI's TCP server on startup and disconnects on exit. So there cannot be the issue of closing the connection before actually sending the string. Also, I have usually tested my VBAI script with simple telnet connection to the VBAI server. Each time your press a key in the telnet session, a character is sent. This client makes the same kind of problem.

Vladimir