LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

serial read, and data import into spreadsheet

Getting closer.  I changed the data bits from 8 to 7, and voila.  This uncovered another issue.  Erratic data being read: meaning that sometimes it logs a couple pieces of data (different weights), and then at some point it stops collecting new data - it repeats the final data value (even when the weight is changed).  I also noticed the error message showed up in the Error Message field, so I tied an indicator to the code out leg of the error handler (Error Code).  I haven't been able to find the error value yet: -1073807252.   See Front Panel and text file...

 

Noname6.jpg

 

Noname7.jpg

 

 

0 Kudos
Message 71 of 86
(375 Views)

Here's a description of the error code - not sure how to interpret...

 

−1073807252 An overrun error occurred during transfer. A character was not read from the hardware before the next character arrived.
0 Kudos
Message 72 of 86
(373 Views)

@tgilbert wrote:

Getting closer.  I changed the data bits from 8 to 7, and voila.  This uncovered another issue.  Erratic data being read: meaning that sometimes it logs a couple pieces of data (different weights), and then at some point it stops collecting new data - it repeats the final data value (even when the weight is changed).  I also noticed the error message showed up in the Error Message field, so I tied an indicator to the code out leg of the error handler (Error Code).  I haven't been able to find the error value yet: -1073807252.   See Front Panel and text file...

 


Hmm, so this message "I have the tool set for: 5.1.7 (9600 baud); 5.2.5 (no parity); 5.3.1 (1 stop bit); 5.4.3 (no handsh... was not correct, then.  Smiley Wink

 

I'm going to assume your serial config is still set to enable the termination character that it is linefeed.

 

I would set your wait between the write and the read to be longer than 50 msec.  It might not be long enough to get all your data back.

 

Actually since, you know you are expecting 22 bytes, or even more.  Eliminate the wait, get rid of the bytes at port query, and just wire a number such as 22 or larger into the VISA read.  There is no reason for the bytes at port to grow unless you are getting multiple messages for each write statement, or incomplete messages when you read causing the rest of the message to show up later.  Your Bytes at port should never be getting as large as 4361 if all is working like it should.

0 Kudos
Message 73 of 86
(364 Views)

The tool has no setting for the Number of Data Bits (that I set in the VISA Configure Serial Port)   I was just trying stuff, and changing it to 7 allowed proper display of the data - but I'm not sure why.  The manual has the data output format as 22 characters (see attachment in a previous thread).  Still scratching my head. 

 

As far as the Bytes at port; the number keeps growing until it reaches ~6000 (and it hovers around that value), and the raw data / value attains a value that doesn't change (see image).  Would flushing the buffer clean out the data?  If so, what is the preferred method in LabVIEW?  Or perhaps there's another way to overcome this?

 

Noname8.jpg

0 Kudos
Message 74 of 86
(359 Views)

@tgilbert wrote:

The tool has no setting for the Number of Data Bits (that I set in the VISA Configure Serial Port)   I was just trying stuff, and changing it to 7 allowed proper display of the data - but I'm not sure why.  The manual has the data output format as 22 characters (see attachment in a previous thread).  Still scratching my head. 

 



Page 3 of the manual says the device could be set to either 7 or 8 data bits.  You had 8 wired to the Configure Serial port in one of your earlier images and said that it matched what you did in Hyperterminal.  If Hyperterminal worked okay, then it must have actually been set to 7.

 


@tgilbert wrote:

 

As far as the Bytes at port; the number keeps growing until it reaches ~6000 (and it hovers around that value), and the raw data / value attains a value that doesn't change (see image).  Would flushing the buffer clean out the data?  If so, what is the preferred method in LabVIEW?  Or perhaps there's another way to overcome this?

 

 



A VISA flush will clear the buffer.  But I have never seen a situation where I would need to use it on a serial port.

 

When you hit Esc-P in hyperterminal, does it send one data point for each time you hit Esc-P?  Or does it start sending data continuously at a rapid rate?  Take a look at page 9 of the manual.  It says there is an automatic data output setting that sends data out automatically without asking for it at a predetermined rate.  My guess is that you actually have that turned on, and it is sending data much more rapidly than you are doing a VISA read.

0 Kudos
Message 75 of 86
(354 Views)

Ravens Fan wrote:

 

Page 3 of the manual says the device could be set to either 7 or 8 data bits.  You had 8 wired to the Configure Serial port in one of your earlier images and said that it matched what you did in Hyperterminal.  If Hyperterminal worked okay, then it must have actually been set to 7.

 

[tgilbert]: Sorry - too many balls in the air.  Hyperterminal was set to 7 data bits.

 

Ravens Fan wrote:

 

A VISA flush will clear the buffer.  But I have never seen a situation where I would need to use it on a serial port.

 

When you hit Esc-P in hyperterminal, does it send one data point for each time you hit Esc-P?  Or does it start sending data continuously at a rapid rate?  Take a look at page 9 of the manual.  It says there is an automatic data output setting that sends data out automatically without asking for it at a predetermined rate.  My guess is that you actually have that turned on, and it is sending data much more rapidly than you are doing a VISA read.

 

[tgilbert]:

In hyperterminal; I don't send an Esc-P, and yet continuously receive data (BTW, Printing option is set to 6.1.4 - Automatic at stability).  When I change Printing option to 6.1.2 (Manual after stability), I press the PRINT key (on the unit) to toggle data capture on and off. 

 

in LabVIEW: I get no data in LabVIEW with the current vi (when Printing option is set to 6.1.2).  I think you're on to something!  Apparently when 6.1.4 is set, the unit continuously spews data; and when 6.1.2 is set, the unit needs some command to be toggled on/off to get data.  I'm not sure why LabVIEW Esc-P (0x2780) is not being recognized.  Quite a perplexing little problem.  So, I guess the possible solutions would be: 1) allow unit to spew data, and grab what I need (flushing the rest); or 2) setup a toggling of the Esc-P command (which isn't currently working, but should be - maybe I have another issue I'm missing)? 

 

0 Kudos
Message 76 of 86
(351 Views)

How quickly does it send each data point?

 

If you ran a loop reading 22 or more bytes at a time running as fast as it can, it should be able to keep up and capture all the data.  You can either do something with it all, or ignore it and only use the data coming in when you need to.  Feed the data into a notifier or perhaps a single element lossy queue so that another loop always has the latest data available.

 

You could do a VISA flush.  The only concern is suppose you do a VISA flush right in the middle of a packet of data coming in.  You could miss the beginning of the message.

0 Kudos
Message 77 of 86
(348 Views)

I'm not familiar with the VISA behavior, so I have a question.  Does the Bytes at Port reading signify a non-recoverable sort of condition, when it reaches the 6000-ish range?  I notice that it counts up to that level while the running of the vi (i.e. - it takes a couple 5 second reads before it gets there), and then hovers around that number.  I get one data reading, that appears valid, and then no updated data (i.e. - the same value continuously gets placed into the spreadsheet - even when the scale is unloaded).

 

Which would be easiest to accomplish this task:  1) "Feed the data into a notifier"; 2) Feed the data into a single element lossy queue"; or 3) VISA flush?

 

The goal of this activity is to accurately obtain / archive measured data; without turning the creation of the vi into a career.

0 Kudos
Message 78 of 86
(345 Views)

I wouldn't say it is unrecoverable.  It is probably in the neighborhood of the size of your buffer.  (Though I would have expect to be around 4096).  The problem is you would have to read through numerous old stale data before you get to the newest.  At 22 bytes per data point, and 6000 in the buffer, you probably have about 300 data points in there.  Since you are only reading data out of the buffer every 5 seconds, the data you will be reading will be upwards of 25 minutes old.  (300 data points by 5 seconds = 1500 seconds or 25 minutes).  If it takes only a few 5 second reads, until it fills up, you might be getting about 10-20 data points per second, but her only reading out 1 every 5 seconds.  So that lack of change in the reading when you unload is actually just you churning through old data slowly.

 

I would do number 1.  As I said, I don't know if a VISA flush would be perfectly reliable.  And I just saw you have LV 8.5, and I don't know if a lossy queue was added to LabVIEW in 8.5 or later.

 

See attached.  Since I don't have your device, I haven't had a chance to truly run this to be sure it works 100%.

0 Kudos
Message 79 of 86
(339 Views)

Awesome.  A few things to tweak (e.g. - data bits from 8 to 7), but the send notification did the trick.  I'm going to play with the formatting, and will repost the front panel, block diagram, and spreadsheet output.  Thanks...and go Joe Flacco. Smiley Wink 

 

I have to do some work to learn the use of the Obtain Notifier, Send Notification, and Release Notifier functions - seems pretty handy.

0 Kudos
Message 80 of 86
(335 Views)