LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Send data command via TCP

I have a non-LV application that while running sends data via TCP on a localhost address.  In my LV applicaiton I use the TCP Open Connection in conjuction with TCP Read and it works great.  However, I need to issue a command to the non-LV application while its running to set it into different modes of operation.  I've tried a variety of schemes (i.e. uisng TCP Write) to no avail.  I can get the LV samples to work by themselves as samples but I cannot get the writing of data implemented into my application.  The programmer who created the non-LV application demonstrates that it responds to commands via the TCP connection.   I'm under the impression that I need a better understanding of how to interrupt a TCP session.  Please advise on what to use for the proper sequence of LV functions to do this.

 

Please note I'm a common Joe LabVIEW user and am not well familiar with TCP concepts.  I'm using Win-XP and still stuck with LV v.8.5.1 for this application.

 

Thanks,

 

DJ

0 Kudos
Message 1 of 6
(3,055 Views)

You don't "interrupt" a TCP session. When you open a TCP connection, it's available for reading and writing. You could open a separate connection for each, but that's usually not necessary, unless the other end expects separate connections, like for example, on separate ports. It sounds to me like the other app is expecting data in a certain format, and you are not sending it in that format. What are the "commands" that the other app expects? Are they text-based commands? A byte array? If they're text-based, are they supposed to be terminated with a certain character? Are you supposed to send the size of the data that you're sending before you're sending the data? All of this information would come from this other fellow.

Message 2 of 6
(3,048 Views)

I apologize for my delayed response as I was sidetracked on another project. I've issued the commands exactly as the other programmer wants it and have tried a wide variety of schemes to issue the commands. This also includes telling the server how many bytes to expect.   It's turned into a frustrating project because I've spent way too many hours trying to get it work. Part of my problem is working with programmers who hold LV with a certain sense of derision saying that it cannot handle the real world of programming. Another reason for my delayed response is I had given this project to two other persons who are younger and brighter than I am but they also were not able to get it to work.

 

Okay enough pining.   I notice that when the server application is running, it will not work with more than one client connected to it.  For example, when I monitor the server with HyperTerminal, I can see the data the server is issuing but I cannot get the TCP Open Connection to work.  Conversely if I first monitor the server data with TCP Open Connection in conjunction with TCP Read, I cannot get HyperTerminal to work.  Could this be an indicator or symptom of the problem?  What is the TCP jargon that defines a server application to be able to accept commands on an open connection?  Incidentally I have not been able to issue commands through HyperTerminal either.

 

I’ve used LV for many years for a variety of complicated projects and have successfully programmed FPGA application using cRIO, which taxed my abilities.  But this little project has me stumped.

 

0 Kudos
Message 3 of 6
(2,985 Views)

I need to make a correction in my last reply.  I can control the server application by issuing commands using HyperTerminal.  I just cannot get the application to respond to a command from a LV application.  For example, there is an example VI titled TCP Communicator - Active.vi.  If I first run the server application, I can see the data issued by it using TCP Communicator - Active.vi but the application ignores command data issued from TCP Communicator - Active.vi .  I've tried a variety of line feeds, carriage returns, etc.  In short I can issue commands using HyperTerminal but not when using TCP Communicator - Active.vi .

0 Kudos
Message 4 of 6
(2,979 Views)

You need to get the details specifics of teh commands your server appluctaion is expecting. The LabVIEW TCP VIs work perfectly fine and can communicate with applications written in other langauges. The key is knowing the expected format (protocol) for the conversation. What platform is your server running on? Can you get a network trace (using a tool like Wireshark) and capture the conversation with Hyperterminal?



Mark Yedinak
Certified LabVIEW Architect
LabVIEW Champion

"Does anyone know where the love of God goes when the waves turn the minutes to hours?"
Wreck of the Edmund Fitzgerald - Gordon Lightfoot
Message 5 of 6
(2,969 Views)

After spending more inordinate time on this project it was discovered that the command line needs to be sent one character at a time.  For example in this case the two-digit command “X0” will cause the external application to shut down (exit).  Therefore the letter “X” is sent using the TCP Write function and then wait (i.e. 100 mSec) and send the number “0” again using the TCP Write function.  I discovered this by accident.  It seems asinine and very unconventional to send a command like this and I’m frustrated that the programmer did not inform me.  To me it’s as unconventional as paying a bill using two envelopes; one for the bill stub and the other for the check.

 

The comments given that providing the expected command format is indeed the lesson learned and I’m hoping someone else can learn from this experience.

 

Thank you for your responses.

 

DJ

0 Kudos
Message 6 of 6
(2,947 Views)