ConnectToTCPServer

Hi,
Could someone help?
Why am I getting a library function error
if (ConnectToTCPServer (&g_hconversation, portNum, serverHostName, clientTCP, NULL, 5000) <0
     return 0;
portNum is 5000
serverHostName is 192.168.2.3 and I can ping it.
my clientTCP function is:
int clientTCP (unsigned handle, int event, int error, void *callbackData)
    char receiveBuf[256] = {0};
    int dataSize         = sizeof(receiveBuf)-1;
char lineBuf[130];
    switch (event)
        case TCP_DATAREADY:
#if 0
            if ((dataSize = ClientTCPRead (g_hconversation, receiveBuf, dataSize, 1000)) < 0)
    return -1;
   printf("TCP_DATAREADY received: %s\n",receiveBuf);
#endif
            break;
        case TCP_DISCONNECT:
   if(error)
    sprintf(lineBuf,"TCP_DISCONNECT received due to error= %d\n", error);
    PRINT_DBG(lineBuf);
       g_hconversation = INVALID_TCP_HANDLE;
   else
    PRINT_DBG("TCP_DISCONNECT received from TcpServer\n");
            break;
        default:
        printf("default received\n");
        break;
    return 0;

Hello agyna,
which error are you receiving and where? Does it happens every time you run the code?
Proud to use LW/CVI from 3.1 on.
My contributions to the Developer Zone Community
If I have helped you, why not giving me a kudos?

Similar Messages

RegisterTCPServer and ConnectToTCPServer

I deal mainly in the LabVIEW world, but I'm having to translate some CVI code (the server side) to LabVIEW, and I'm trying to understand one piece of the CVI code first. In the server side, there is a call to RegisterTCPServer
else if ((status = RegisterTCPServer (xxTCP_PORT, xxTCP_Callback, NULL)) < 0)
and on the client side there is a call to ConnectToTCPServer
ConnectToTCPServer (TCPHandle, xxTCP_Port, "xxName", yyTCP_Callback)
The part that is unclear to me is that the client and server are on different computers, and the Client seems to specify a serverHostName (in this example, xxName), but the Server's call to RegisterTCPServer only has the Port number in common with the Client. I'm thinking that since no serverHostName is specified, it would default to localhost. So, why does the client (in this example) specify the serverHostName? Is the port number sufficient for the server/client to find each other, or is there some CVI call I should be searching for in the (server) code that must be being called somewhere that named the server to the samething the client is looking for?

As is clearly explained in the online help for the function, RegisterTCPServer
Registers your program as a valid TCP server and allows other applications to connect to it for network communication.
Clients attempting to connect to your program must use the same port number. Thereafter, all requests by the client are routed through the specified server callback function. You can register your program as a TCP server multiple times as long as you specify different port numbers.
On the server side you do not need the host name simply because you are the host!
On the contrary, on the client side you need to know the server name (together with the port number) so that your messages are properly routed to the correct machine: it could be the same machine or a different PC over the network.
Proud to use LW/CVI from 3.1 on.
My contributions to the Developer Zone Community
If I have helped you, why not giving me a kudos?

ConnectToTCPServer Failure in Windows7

I am using "Measurement Studio Version 6.0, Labwindows/CVI" for my TcpIP Server and Client Program.
It works very well in the Windows XP circumstance using below functions.
But the function ConnectToTCPServer fails with error message like below, whereas RegisterTCPServer works successfully at Windows XP and Windows 7 OS.
I tried ConnectToTCPServer function at three computer, which results in same error message.
I am looking for anyone like an angel who can help me. Thanks.
<server side>
RegisterTCPServer(6000, Server1Callback, 0);
<client side>
unsigned int handle;
ConnectToTCPServer (&handle, 6000, "172.29.24.182", ClientCallback,NULL, 5000);
<error message at client side>
Non-fatal run-time error
Library function error (return value == -2 [0xfffffffe]).
Unable to establish conneciton

Hi seong-yeon
Did you confirmed if that port is available? Also try the computer name as the server host name in ConnectToTCPServer.
Do you have all firewalls disabled? You can confirm with your IT department if there is any network security installed.
This article discuss how to build applications with the TCP Support library and offers a couple of examples you can try to test the connection between the client and the server.
Regards
Chris S.

Network Cable Unplugged Status, PC to PLC

I am working with a PLC connected to the PC via Ethernet. I would like to receive notification that the cable is unplugged. Here is the scenario:
1) Connect to PLC with ConnectToTCPServer (ok).
2) Send commands via ClientTCPWrite (ok).
3) Receive status back from PLC. (ok)
All this works great.
Now unplug the Ethernet cable. Go to step 2) and send the command. CVI sends it and returns a -kTCP_NoError. The PLC never responds, and the system is frozen.
Why do I not get an error when using ClientTCPWrite to an open/broken connection?
Obviously, Windows is aware of the connection, as I instantly get a "Network Cable Unplugged" notice in the taskbar. Is there an SDK function to do this?
If you wait long enough, it will trigger the TCP_DISCONNECT in the callback.
Thanks in advance, David

Hey Microanalytics,
Here are some related posts that give good solutions to this problem:
http://forums.ni.com/t5/LabWindows-CVI/How-to-find-if-the-network-cable-is-unplugged/td-p/1893377
http://forums.ni.com/t5/LabWindows-CVI/How-to-check-network-availability/m-p/689645/highlight/true#M...
Peter T
Applications Engineer
National Instruments

TCP Callback function passing data to teststand

Hi,
I'm trying to pass data via a TCP Callback function to teststand using the TCP steptype that I downloaded from Ni.
When I open a connection, container data is passed to the dll on which it creates a connection, the dll in part creates a TCP Callback function.
The handle obtained from the connection is then passed back through the container data, and the dll returns back to the sequence editor which will execute the next steps.
The problem is that when the TCP Callback function gets an TCP_READY event it can not pass data to TestStand because it can not access the container data.
How can this TCP Callback function pass/alter data to/in Testand?
Thank you...

Yes ThiCop,
That's exactly what I want to establish!
Here is the example code:
//Function needed by the TCP functions
int CVICALLBACK MsgHandler (unsigned handle, int event, int error, void *callbackData)
    char receiveBuf[256] = {0};
    char displayBuf[7] = {0};
    char * tempLookup;
    int dataSize = sizeof (receiveBuf) - 1;
   switch (event)
      case TCP_CONNECT:
         break;
      case TCP_DISCONNECT:
         break;
     case TCP_DATAREADY:
         if ((dataSize = ClientTCPRead (handle, receiveBuf, dataSize, 1000)) > 0)
               // Send data from receiveBuf to a variable in teststand ????
               //  TS_PropertyGetValString (HandleObject, NULL, "Step.Result.Data", 0, &tempLookup);
               //  TS_PropertySetValString (HandleObject, NULL, tempLookup, 0, receiveBuf);
         else
               receiveBuf[dataSize] = '\0';
        break;
return 0;
void __declspec(dllexport) TX_TEST TCPConnectF(tTestData * testData, tTestError * testError)
    int                 error = 0;
    int                 TCPerror;
    double           Port;
    double           Timeout;
    char              *HandleLookup;
    char              *ServerAdd;
    char              *CallbackData;
    ErrMsg           errMsg = {'\0'};
    ERRORINFO   errorInfo;
    tsErrChk (TS_PropertyGetValString (testData->seqContextCVI, &errorInfo, "Step.Result.Handle", 0, &HandleLookup));
    tsErrChk (TS_PropertyGetValNumber (testData->seqContextCVI, &errorInfo, "Step.Result.Port", 0, &Port));
    tsErrChk (TS_PropertyGetValString (testData->seqContextCVI, &errorInfo, "Step.Result.IP", 0, &ServerAdd));
   tsErrChk (TS_PropertyGetValNumber (testData->seqContextCVI, &errorInfo, "Step.Result.Timeout", 0, &Timeout));
   tsErrChk (TS_PropertyGetValString (testData->seqContextCVI, &errorInfo, "Step.Result.Data", 0, &CallbackData));
    TCPerror = ConnectToTCPServer (((unsigned int *) &ConnectionHandle), ((unsigned int) Port), ServerAdd, MsgHandler, 0, Timeout);
    if (TCPerror != 0)
    //Get TCP Error Message
       sprintf(errMsg,"%s",GetTCPErrorString ( TCPerror ));
       error = TCPerror;
       goto Error;
tsErrChk (TS_PropertySetValNumber (testData->seqContextCVI, &errorInfo, HandleLookup, 0, ((double) ConnectionHandle)));
Error:
    // FREE RESOURCES
    CA_FreeMemory(HandleLookup);
    CA_FreeMemory(ServerAdd);
    // If an error occurred, set the error flag to cause a run-time error in TestStand.
    if (error < 0)
        testError->errorFlag = TRUE;
        testError->errorCode = error;
        testData->replaceStringFuncPtr(&testError->errorMessage, errMsg);
    return;

MODBUS/TCP in CVI

Dear All,
I need help to write MODBUS/TCP coding to read data from a third party device.
The deveice is getting connected with help of "ConnectToTCPServer" function. But i am not able to get the data from the module. Any idea how to send the qurey and get the data.
regards,
Kumar.E

Hi Kumar,
I have a few questions that will really clear up a few things for me. Are you actually using Modbus or are you using the TCP functions in CVI? What are you trying to do, basically what do you want to be able to do? The actuall functions that you need to call should be in your device manual. Do you have this information?
We have a Modbus library for LabVIEW but we do not have one for CVI. Please reply with more information on what you are trying to do.
Regards
Krista S.
Applications Engineering
National Instruments

A way to disable NAGLE of windows SOCKET

I know that if I use VISA socket, I can change the value of VI_ATTR_TCPIP_NODELAY attribute and enable/disable NAGLE algorithm. How can I do the same thing using standard windows socket? say when I have established my connection by ConnectToTCPServer command.

Okay, now I am getting really confused... Sorry, it's partly because of my lack of experience... but I'll go ahead and say how I again bumped into a dead end.
I found no winsock2.h under my National Instruments\CVI85\sdk\include (winsock.h exists though under this folder) I also found no ws2-32.lib anywhere in under my National Instrument folder. But I found both of them under my MATLAB directory...
So I copy-pasted winsock2.h into National Instruments\CVI85\sdk\include and #include <winsock2.h> in my c application. I also copy-pasted ws2_32.lib into National Instruments\CVI85\extlib, and added it to my project.
When I compile my code this way, it gives me lots of "redefinition of macro " errors, for example for 'WSAEINTR', 'WSAEBADF' and so on...
If I change #include <winsock2.h> to #include <winsock.h>, the compile works fine, but linker gives error "Read error"...
I have no idea what this means and how it can get solved. Thanks again for your time.

How often is TCP_DATAREADY generated?

What I'm doing:
I'm working on adding a Wi-Fi module to a product that uses a small embedded micro-controller.
The micro operates as a TCP server communicating via Wi-Fi.
I've developed a LabWindows/CVI application to display the data that the micro collects.
In one mode of operation the micro delivers a continuous stream of 20 byte frames.
The frames are sent at 3200 Hz.
The LabWindows/CVI code connects to the micro as a client and then sends a command to start the 3200 Hz stream of frames.
In the TCP callback function (the one that is registered with the call to ConnectToTCPServer(...) )the TCP data is read and handed off to the rest of the application.
The problem:
The TCP callback where it handles the TCP_DATAREADY case is not called often enough to keep up with
the stream of data. ( I am calling ProcessSystemEvents() in the loop that waits for data)
My questions:
How often can I expect to get a TCP_DATAREADY in the TCP callback?
How much buffering of the incoming TCP data is there?
In other words how long can my code be "away" from the callback before things get too backed up?
One other thought:
Everything has been working well using a directly connected serial interface running at 2 mega-baud
to connect to the micro. With the serial connection there is large buffer on the COM port so I have
a fairly long time before the code has to get back to process more incoming frames. I'm trying to
emulate this same behavior with the TCP client-server setup.
Any ideas will be appreciated, thanks,
Kirk

Hi kirkm,
I was able to do a little digging and did find an available knowledgebase article on this particular flag. You can find it here
http://digital.ni.com/public.nsf/allkb/C5CC85D98C771FC78625768500565FAF
It appears the TCP_DATAREADY event of a callback still requires a call to ClientTCPRead. In that function you can specify your data buffer size. That could be one approach to making sure you get the data needed, by specifying your given buffer size.
Reading up on TCP Communication found at http://www.ni.com/white-paper/3067/en There is a section on how to react to the streaming nature of TCP. I will quote that section for reference:
"In TCP, because data is sent in a byte stream, it is not possible to know how many bytes are present in the data stream. Therefore, you cannot query the LabWindows/CVI TCP Support Library to get the amount of data available. When you call ServerTCPRead or ClientTCPRead, the library returns the number of bytes read into the data buffer. If the number of bytes read is the same as the data buffer size, then more data still might be present in the data stream. You can read the remaining data immediately by calling the read functions again or wait until the TCP callback is called again with the TCP_DATAREADY event. The LabWindows/CVI TCP Support Library calls the TCP callback with the TCP_DATAREADY event whenever events are processed and there is data in the TCP stream. Refer to the LabWindows/CVI samples\tcp\message.cws sample program for code that shows how to read all the data in the TCP stream whenever the TCP callback receives a TCP_DATAREADY event. The ServerTCPWrite and ClientTCPWrite functions return the number of bytes written to the TCP stream, which might be less than the number of bytes in your data buffer. You must check for this condition and make sure all the bytes in your data buffer are written out successfully. The following code, based on code in the samples\tcp\messagewriter.c sample file, demonstrates how to check for this condition."
Hopefully that will get things started.
Regards,
James W.
Applications Engineer
National Instruments

Question about callbacks

I'm trying to design a small program that involves TCP socket reads and writes. In the help for the ConnectToTCPServer() function, there's a note about the callbackFunction:
The callback function should be short and should return as soon as possible.
My question is, does this statement apply principally to the ConnectToTCPServer() function, or to all callbacks? It seems that once I've called RunUserInterface(), pretty much all my processing will be within callbacks (or routines that the callbacks call).
Am I missing something here?

Generally speaking, that warning applies to all callbacks: a control callback that takes too long to terminate blocks all user input on the user interface. One very common question on this forum is indeed "I have a callback that executes a test but I cannot stop it pressing a stop button because it is unresponsive!" CVI offers ProcessSystemEvents () function exactly to permit processing events in case of a long callback that blocks out other events, but it must be used with cautions: as you can read in the help for the function, Take care when using ProcessSystemEvents, because it can allow other callback functions to execute before it completes.
Additionally, there are several methods to execute code out of a control callback or without blocking the user interface:
UI timers
Asyncronous timers
Functions called via PostDeferredCall
Threads other than the main thread
In case of a long lasting procedure, I strongly encourage you to handle it in one of these methods instead of running it inside a control callback with embedded calls to ProcessSystemEvents () .
Proud to use LW/CVI from 3.1 on.
My contributions to the Developer Zone Community
If I have helped you, why not giving me a kudos?

TCP client server sample

All,
This may not really be a LabWindows/CVI question but I'm really stuck on what should be easy to
solve. The brain trust here on the forums has always been helpful so I'll try to explain.
The project:
Get LabWindows/CVI code talking to a muRata SN8200 embedded WiFi module.
The setup:
(running Labwindows/CVI 2009)
Computer 1 -- (with a wireless NiC) running simple demo TCP server program provided by muRata.
Computer 2 -- USB connection (virtual COM port) with simple program (also provided by muRata) that talks to the SN8200 embedded WiFi module. This code along with the module creates a simple TCP client.
Whats working:
I can successfuly get the Computer 2 client connected to and talking to the Computer 1 server. (using the muRata supplied code)
I can also run the LabWindows/CVI sample code from (\CVI2009\samples\tcp), server on computer 1 & client on computer 2 and they talk with no problems.
(I'm using the same IP addresses and port numbers in all cases)
Whats NOT working:
Run the CVI server program on computer 1.
I cannot get the muRata client program to connect to the CVI server.
I also tried get the CVI client program to connect to the muRata server. No luck that way either. The CVI client sample program trys connect, and this function call:
ConnectToTCPServer (&g_hconversation, portNum, tempBuf, ClientTCPCB, NULL, 5000 );
returns with a timeout error code (-11).
What I need:
Some ideas on how to get this working.
Is there something unique about the LabWindows/CVI sample client/server demo code that would make them incompatible with the muRata code?
Can you think of some ways I can debug this further? I feel like I'm kind of running blind.
What else can I look at?
For those that have read this far, thanks much and any ideas or comments will be appreciated,
Kirk

Humphrey,
First,
I just figured out what the problem is:
When I was trying to use the CVI sample server I was entering the wrong port number.
The reason I entered the wrong port was because the hard-coded port number in the muRata demo code was displayed in hex as 0x9069. ( I converted this to decimal and entered it into the CVI sample server code) The correct port number was 0x6990. (upper and lower bytes swapped) Arrgh!
I found the problem by using the netstat command line utility to display the connections and noted that the port being used was not 0x9069. It is really a problem with the muRata eval kit demo code.
Second,
Humphrey you are right about the CVI sample code not handling all the muRata commands for the client end of the connection that communicates with the SN8200 module. For my test I was using the muRata code for that "end".
The server end is simple and the CVI sample is adequate and is now working.
Thank you to all who took the time to browse my questions,
Kirk

Incorrect errors from ConnectToTCPServer?

(CVI 5.5.1 on NT)
When I call ConnectToTCPServer() and the server wasn't registered yet, I get "Unable to register service" instead of "Server Not Registered" as expected.
Also, when the Address is a host name that may not be resolvable (local or DNS), I got "Invalid Parameter" and started hunting down a parameter mismatch in the call. I eventually discovered that the paramter was valid, but it was a simple case of "host not found."
Any word on these from the NI insiders?

Thanks Jeremiah,
I guess I didn't find this article because I was searching for ConnectToTCP! However, it covers a slightly different case than mine, but the concern is the same, I'm sure.
Anyway, All works OK when the server is actually there, just the misleading error when it isn't. I also noticed the same response when the host is correct, but the port (service) is not registered. Fundamentally, there is an invalid parameter, but a similar error is given from other libraries (like UIL) with different meanings. I don't expect perfection, I just thought I'd bring to your attention.
Thanks for your response.

TCP/IP Library and Windows 7

Hi together,
I have the following problem: I am trying to build up TCP/IP connections as client. On my notebook (WindowsXP) everything works like a charm. But when I install the application on a Windows 7 PC, no connection is possible.
ConnectToTCPServer fails with "WSAE_UNKNOWN".
Probably this has to do with the socket handling from Win 7. Currently I still have the Measurement Studio Ver. 6.0 on my notebook, because my applications always worked fine on WinXP PCs.
So my question is: Is this a known behavior? If so, is there a workaround or is the only solution a newer CVI Version?
Thanks for any help,
Dirk

Hello Robert,
thanks for your answer.
To give a some more details:
I can´t say if it is happening with trying to use any TCP from CVI. Because if the application is running on an WinXP PC (my notebook, even installed from the distribution kit) everything is fine. On a Windows 7 PC my application already fails on the ConnectToTCPServer call with the above mentioned error. With PuTTY I can establish TCP connections, a python script (though I am not sure if my python supports Win 7) shows the same problem.
Some more details about the task: I have to establish two TCP connections as client, one to my data acquisition hardware, second one to a TCP Server provided by automationX (some soft-sps solution). If I run my application on my notebook with WinXP everything works fine (even the automationX stuff I connect to is running on a Windows 7 PC). Now I install the application on a Windows 7 PC and both ConnectToTCPServer calls fail with the above mentioned error. So I have no chance to test other TCP calls from the library.
Actually this behavior makes me think that is a problem with the Winsock of Windows 7. Why otherwise it would run on my XP notebook and would fail on the ConnectToTCPServer on the Windows 7 PC?
Unfortunately, being in Asia atm, I only have the CVI 6 version with me. I will travel back to Germany next week. I have the upgrades up to CVI 9 there, but I never installed them. (Never change a running system ) On the other hand, probably it is time to do so. Never had to work with Win 7 before.
I just wanted to know if anyone else experienced some similar problems and if there is a workaround (maybe even in Win 7 to make the socket behavior / handling like it was on WinXP).
But I guess I have to finally install the upgrades.
Is CVI 9 compatible / tested with Windows 7?
Best regards,
Dirk

About the GetHostTCPSocketHandle() function

Hello,
I'd like to know if the 2nd parameter of the function is corresponding to the "SOCKET" type in the Windows SDK? Can you tell me the usage of this function? Thanks.
David

Phototype:
int GetHostTCPSocketHandle(unsigned int Connection_Handle,int *Socket_Handle);
Connection_Handle: TCP Support Library conversation handle that you obtain from ConnectToTCPServer or ConnectToTCPServerEx or receive in a server callback as the handle parameter of a TCP_CONNECT message.
*Socket_Handle: System socket handle for the connection that connectionHandle identifies. (passed by reference);
Status: Return value indicating whether the function was successful. Unless otherwise stated, zero represents successful execution and a negative number represents the error code.
You can call the GetTCPSystemErrorString function to obtain a system message that describes the error. The system messages can be more descriptive than the TCP Support Library error codes. To obtain the correct system error message, you must call GetTCPSystemErrorString immediately after calling the TCP Support Library function that failed.
For functions that read or write data (ClientTCPRead, ClientTCPWrite, ServerTCPRead, ServerTCPWrite), if the function was successful, the return value is the number of bytes transferred.
You can have a maximum of 255 concurrent conversations and up to 1,024 connections. If you exceed this limit, -kTCP_TooManyConnections will be returned. You may not be able to open the maximum number of connections allowed by LabWindows/CVI because of limitations imposed by the operating system.

TCP/IP Library

Hello.
I am searching for a commercial c++ TCP/IP library to be used on Solaris (both Intel and SPARC). Is anyone aware of any such libraries?
Thanks in advance,
Jim

Hello Robert,
thanks for your answer.
To give a some more details:
I can´t say if it is happening with trying to use any TCP from CVI. Because if the application is running on an WinXP PC (my notebook, even installed from the distribution kit) everything is fine. On a Windows 7 PC my application already fails on the ConnectToTCPServer call with the above mentioned error. With PuTTY I can establish TCP connections, a python script (though I am not sure if my python supports Win 7) shows the same problem.
Some more details about the task: I have to establish two TCP connections as client, one to my data acquisition hardware, second one to a TCP Server provided by automationX (some soft-sps solution). If I run my application on my notebook with WinXP everything works fine (even the automationX stuff I connect to is running on a Windows 7 PC). Now I install the application on a Windows 7 PC and both ConnectToTCPServer calls fail with the above mentioned error. So I have no chance to test other TCP calls from the library.
Actually this behavior makes me think that is a problem with the Winsock of Windows 7. Why otherwise it would run on my XP notebook and would fail on the ConnectToTCPServer on the Windows 7 PC?
Unfortunately, being in Asia atm, I only have the CVI 6 version with me. I will travel back to Germany next week. I have the upgrades up to CVI 9 there, but I never installed them. (Never change a running system ) On the other hand, probably it is time to do so. Never had to work with Win 7 before.
I just wanted to know if anyone else experienced some similar problems and if there is a workaround (maybe even in Win 7 to make the socket behavior / handling like it was on WinXP).
But I guess I have to finally install the upgrades.
Is CVI 9 compatible / tested with Windows 7?
Best regards,
Dirk

Can't receive the data from my hardware device by LAN

Hi!
background: For a testing task, I set up a hardware testing platform that including of a power supply device, a hardware to be tested(Device Under Test), a power Meter and a PC.   i build a program to control the hardwares, and they communicate with each other by LAN. at first, the program as a client can normally communicates with my hardware after initializing all hardwares. And then the program turns off the power of my device and turn on power again after delay 60 seconds. after initiantion, my hardware can execute the command which is received from the program, but the program can't receive the data from my hardware. Why my program cannot receive the data from my hardware, after the second time turn on the power of my hardware? the program as client code as below:
int CVICALLBACK ClientRRH (unsigned handle, int event, int error, void *callbackData)
char temp[64]={0};
int ReceiveSize=0;
char *Pos;
switch(event)
   case TCP_DATAREADY:
    if( (ReceiveSize=ClientTCPRead (rrhHandle, readRRHBuffer, 4096, 2000))<0)
                 SetCtrlVal (panelHandle, PANEL_TEXTBOX_INFO,"Read RRH trace error!\n");
                return 0;
    else
     if (ReceiveSize>4096)
      readRRHBuffer[4096]= '\0';
     else
       readRRHBuffer[ReceiveSize] = '\0';
    if (Flag)
      Pos = strstr(readRRHBuffer,orderString);
      if(Pos)
       //strncpy(temp,(Pos+ strlen(orderString)),maxSize);
       _mbsnbcpy(temp,(Pos+ strlen(orderString)),maxSize);
       sprintf(receData,temp);
       *temp=0;
       Flag=0;
       maxSize=0;
       *orderString=0;
    SetCtrlVal (panelHandle, PANEL_TEXTBOX_INFO,readRRHBuffer);
    *readRRHBuffer=0;
            break;
         case TCP_DISCONNECT:
   rrhHandle =error;
            SetCtrlVal (panelHandle, PANEL_TEXTBOX_INFO,"TCP Clienterver has closed connection!\n");
            SetCtrlVal (panelHandle, PANEL_LED_RRH, 0);
            break;
return 0;
int RRH_ini(char *RRH_address)
    ViChar Buffer[200];
    char temp[200];
    int status =0;
if((ConnectToTCPServer (&rrhHandle, 7006, rrhAddr, ClientRRH, NULL, 1000)<0))
    SetCtrlVal(panelHandle,PANEL_LED_RRH,0);
    SetCtrlVal(panelHandle,PANEL_TEXTBOX_INFO,"Connection to RRH fail...\n");
    else
     SetCtrlVal(panelHandle,PANEL_LED_RRH,1);
     SetTCPDisconnectMode (rrhHandle, TCP_DISCONNECT_AUTO);
     sprintf(RRHCommand,"%s\n","asb");
     ClientTCPWrite (rrhHandle, RRHCommand, strlen(RRHCommand), 0);
     Delay(0.2);
     sprintf(RRHCommand,"%s\n","asb#1234");
     ClientTCPWrite(rrhHandle,RRHCommand,strlen(RRHCommand),0);
     Delay(0.2);
     SetCtrlVal(panelHandle,PANEL_TEXTBOX_INFO,"Connection to RRH successful!\n");
   return 0;

Yes that's exactly my problem. The reader sends bytes but without a delimiter. So for example the greeting message I've mentioned earlier "iiAWID..." happens to be 32 bytes, therefore I made the following changes to the code:
public void receive(int x){     // x = expected length of bytes being received
boolean done = false ;
int limit = x ;
int counter = 0;
try {
while (!done)
if (in.ready())
buffer.add(in.read()) ;
counter = counter + 1 ;
if (counter == limit)
done = true ;
}catch(IOException e) { // some code for handling}
and this works fine, however, I'll probably have problems reusing this method later on, because some commands that I will send to the reader will result in responses of indefinite sizes. So I may have a response of length 12 one time and of length 8 the other. but between each response there's a maximum delay of 100ms... is there any way I can utilize that piece of information to improve my code?

ConnectToTCPServer

Similar Messages

Maybe you are looking for