Showing results for 
Search instead for 
Did you mean: 

serial read, and data import into spreadsheet

Better yet, handle the error.


0 Kudos
Message 21 of 86

I have a few questions: What is the purpose of the shift register in this application?; Why use a wrist watch, instead of metronome?; and why are there two "browse for paths" (c:\temp\serialread.xls and c:\serialread.xls)?


Incidentally, my com port is at COM4 (so I changed the I/O name from COM1 to COM4); and I am seeing no data at "Data" indicator and spreadsheet.  TS'ing shows port is working - hyperterminal echos data when I perform loopback test (i.e. hook pin 2/3 together and type on the keyboard).  So, it's either the device I have hooked to the serial port, or something in the vi is misbehaving.


Peter Collins.

0 Kudos
Message 22 of 86

A loopback test does not do much. Did you try Hyperterminal with the cable connected to the instrument?


You could be sending the wrong command, you could be sending the wrong termination character, you could have the wrong com settings, you could be using the wrong type of serial cable, or the instrument could be misprogrammed/defective. Please attach the manual for the instrument so at least someone can attempt to see what might be wrong in the code.

0 Kudos
Message 23 of 86

There really isn't a need for the shift registers.


Wait (ms) and Wait Until Next Multiple (ms) behave differently, but it really won't make too much of a difference for your application.  This example helps explain the difference if you are interested.


To troubleshoot your VISA connection, open Measurement and Automation Explorer and find your comp port under "Devices and Interfaces >> Serial & Parallel".  You can then open up the VISA test panel to send commands back and forth to get the communication settings correct.  Then make sure LabVIEW reflects everything you are doing here.


Jon S

Applications Engineer
National Instruments
0 Kudos
Message 24 of 86

@tgilbert wrote:

I have a few questions: What is the purpose of the shift register in this application?; Why use a wrist watch, instead of metronome?; and why are there two "browse for paths" (c:\temp\serialread.xls and c:\serialread.xls)?

On a larger scale, shift registers will feed the resource back into the loop rather than using the one instance of the resource over and over. The advantage is, suppose for some reason downstream the resource becomes invalid. You need to handle the error and re-build the resource (setup the port again, clear the error, or whatever's on the line) and the S/R will feed the new handled resource back into the loop, rather than picking up on a copy made when the loop first started. In this application, all of that doesn't really matter, so yes, the S/R's are not needed. I use them by default. If I have a timeout, as was mentioned, I will deal with it and keep on moving, although this VI does not demonstrate that.


The two paths are there because I was troubleshooting the VI and copied it that way. Personally, I don't like making quasi-Excel files like you are doing, but it does work - kind of. When you open the file in Excel, it will tell you it's not the correct format, and you can convert it to "real" Excel.


The VI does work on my com port as-is, so you're on the right track with hardware.


0 Kudos
Message 25 of 86

Not sure how to use the Measurement & Automation utility.  Is there a simple series of mouse clickss that will verify correct COM performance?

0 Kudos
Message 26 of 86

Okay - think I figured out how to use this.  I connected a paper clip between pin 2/3, execute a viWrite and then a viRead.  Correct data displays on the read buffer.  Does this mean the serial port is functioning properly?

0 Kudos
Message 27 of 86

I tried another tool we have lying around, and it outputs data.  There is some formatting issue, but I think I'm almost there - yippee.

0 Kudos
Message 28 of 86

Everything works great (reading and storing data) - thanks for your help.  I have another related question.  The device I'm reading from requires a "?" to be sent to initiate a read.  I've tried to add an ASCII 0x3F (and 63d) to the write buffer, to send the request for data - don't work.  Any ideas? 

0 Kudos
Message 29 of 86

I've stepped back from the instrument that requires a request to send data (\?), and am looking at general RS232 serial reads.  I think I need to parse the data into chunks that represent the data value (and throw out everything else).  Question: is it better to select the bytes during the read (by controlling the "byte count", or parse the data after the read (by manipulating the "read buffer")?  Is there a preferred method? 

0 Kudos
Message 30 of 86