07-06-2009 03:38 PM
07-06-2009 04:12 PM
LabVIEW has TCP/IP functions for this kind of communication. There are examples that ship with LabVIEW that show you how to use the TCP/IP functions. Does the driving simulator software initiate the connection, or does it run a listener that you connect to?
As for the saving, unless you absolutely have to generate an Excel workbook, the easiest way to get the file is to use the Write to Spreadsheet File VI. This generates a text file with delimited columns. This can be imported into Excel directly. If you have to generate an Excel file directly then you must use ActiveX. You can either buy the Office Report Toolkit, or code it up yourself. Plenty of examples can be found in this forum as well as on the Excel thread
07-06-2009 04:38 PM
Thanks for replying.
As per your question, driving simulator initiates the connection and I should listen from it.
As far as i understood from examples, i will initiate a connection or listen to a already connected network, then read it using TCP read and from there save it.
But when i try to wire "data out" from TCP read to "write to spread sheet file", the wire becomes broken.
Should I need to use TCP write or some thing before it.
The main doubt i have is "where the output should be taken from one of the TCP palettes to write data in a spread sheet file"
Thanks
07-06-2009 04:59 PM
Knowledge based wrote:Thanks for replying.
As per your question, driving simulator initiates the connection and I should listen from it.
In this case you would need to create a listener that waits for a connection. The "Simple Data Server" and "Simple Data Client" examples that ships with LabVIEW are the ones to look at. However, in your case the "Simple Data Server" would be the one that has the function to open the connection and the "Simple Data Client" is the one that has the TCP Listen.
Knowledge based wrote:But when i try to wire "data out" from TCP read to "write to spread sheet file", the wire becomes broken.
Should I need to use TCP write or some thing before it.
The main doubt i have is "where the output should be taken from one of the TCP palettes to write data in a spread sheet file"
The TCP Read simply returns a string, which is a sequence of bytes. You have to convert this to numbers, which means you have to know in what format the data was sent in the first place. In the examples that ship with LabVIEW the array of values was simply type cast to/from a string. I'm assuming you know the format of the data you get over TCP/IP.
02-22-2010 11:17 AM
Hello Sir,
I am kind of new to TCP/IP in LabView..So I have some questions.
What I am trying to do here is I have a previously developed Python code and I am incorporating it to write data to a data socket. Then I want LabVIEW toread from that same port and get the data using TCP/IP. After getting the data, I want data to run through an equation before outputing into graph.
I am actually using the shipped examples of Data Client and Data Server block diagrams... but I am not sure where exactly to include my block diagram in those examples for reading data and to run through equations and write the data an excel file.
02-24-2010 02:29 PM
Hi Venk7337,
The string coming out of the TCP Read function can be converted to numerics using a conversion function which you can then use as your Signal in the VI you posted.
I hope this helps.
Kristen
02-24-2010 08:25 PM
VenK7337,
Could you show your python code. so we know what your are "writing" to the ethernet port?
That way we can see what you are receiving.
Parsing the incoming data (from the TCP-read) depends heavily on the device that sends it, and can not generically be described. LabVIEW has many byte (and even bit) manipulation functions to convert many different data formats to its own build in formats.
So after the TCP listener is connected, you are constantly reading from the established connection (until it gets broken of course). More advanced example would be the internet toolkit if oyu have it.
From the read characters (and I hope you designed a protocol with a clear starting character, ending character and maybe even a build in checksum) you parse the data and perform you action, and of course generate a reply. Again the internet toolkit is a good example. It parsed the input as it comes it, based on the HTTP format. Then generates the reply based on the request received.
These days I would suggest not to use binairy encoded numerics. Try and use XML formatted data. Yes, it causes a lot of overhead. But typically this is not an issue and makes the code a lot more portable and maintainable. Also makes it easier to interface with other languages/platforms.
Umless of course you are looking at Khz data rates, then XML is not th preferred choice.
Hope this helps...