LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Isolate data from string

Hopefully I will get a chance to test your suggestion today. However, if there were a "\n" termination character, wouldn't the data look like this in Hyperterm?

= 0016.9

= 0016.9

= 0016.9

= 0016.9

= 0016.9

I do have some units that output data like this, but not these. If there were a termination character I would just use the "Intrument I/O Assistant" and everything would work. In these cases, however, the Instrument I/O Assistant does not complete because there is no termination character.

 

Also, the data does not get jumbeled in ScaleReadSub3.vi. I read 1 byte at a time until I find my "=", and that I know what part of the output I am in. I wrote this based on Raven Fan's explanation and it seems to work quite nicely.

0 Kudos
Message 11 of 16
(1,060 Views)

That's interesting info about hyperterminal results. You had more info than you were sharing :). I'll have to think about that.

 

I didn't realize that the posted vi was working consistently for you. Clearly then, there is not a problem taking the bytes out of the buffer this way. And you are getting synchronized with the data. That's the important part.

 

Never Argue with Success

 

steve

----------------------------------------------------------------------------------------------------------------
Founding (and only) member of AUITA - the Anti UI Thread Association.
----------------------------------------------------------------------------------------------------------------
0 Kudos
Message 12 of 16
(1,047 Views)

stevem181 wrote:

 

 

 Since by default you have set your serial port to use a term char, the only way for the Visa Read function to complete is for it to receive a termination character or a timeout. Since you are not timing out, I know that you are getting a termination character and it has to be a “\n” to match the settings. The VISA read does not pass the term char on so you never see it.


Not true.  There are 3 things that can terminate the VISA Read function.  Here they are in the order they would possibly occur.

 

1.  Getting the termination character if it has been enabled.

2.  Getting the number of bytes that were requested.  If this occurs, then you get a warning in the error wire saying you got exactly the number of bytes you requested and there might be more data present.  I believe that the termination character (if you are using one) does count in the byte count.

3.  Timeout.  You did not get the termination character (if enabled) or the requested number of bytes during the timeout period.

 

In ohter words, if you get what you asked for, it doesn't time out.  It doesn't matter if the termination character is enabled or not. 

 

IMSargon, 

If you are getting exactly 8 bytes "=spaceXXXXXX" with no termination character.  Then disable the termination character and read 8.

If you are getting 9 bytes "=spaceXXXXXX\n" (termination character is line feed/new line), then enable the termination character as ASCII decimal 10 (hex 0A), and read at least 9 bytes (more is okay too)

 

One issue that you have if it is the first method, is that if you open the port in the middle of a message, then you 8 bytes won't line up with a data "frame",  you could get "XX= YYYY", incomplete number of bytes from the first data point, and only the beginning bytes from the next data point.  You may need to do a pre-read of the data before you get to your regular loop.  Read 1 byte at a time until it equal "=".  Then read 7 bytes (to complete that frame).  The go into your loop where you regularly read 8 bytes and convert.

0 Kudos
Message 13 of 16
(1,025 Views)

Ravens Fan said much the same as the message I was about to post..

 

One slight difference was that assuming that the interpretation of the data stream is correct, it would be possible to set the termination character to '=', and on the Visa read, set byte count bigger than the number of characters that you would expect, say to 20. You would terminate on the '=', and the routine would still work if the number had more characters, perhaps 100.123

 

The entire string you read could be passed to the string to number routine, which would finish it's scan on seeing the '=' sign. There's a slight difference between using "scan from string" with a %f format and using "fract/exp string to number" in that scan from string will ignore all leading white space (space, tab, new line) but fract/exp string to number will only ignore leading spaces in its scan. Both finish on seeing a character that isn't part of a number.

 

You could gain the initial sync either by a pre-read outside the loop (20 bytes with '=' termination) or by ignoring the first read inside the loop.

 

This technique will also work on instruments that give both '=' and a new line by terminating on an '=' and ignoring all leading white space on the conversion.

 

Rod.

 

 

Rod.

 

0 Kudos
Message 14 of 16
(1,020 Views)

So, what do I need to know about buffers?

 

What I want, ultimately, it to have a subVI that I can call to give me the current mass from the scale. If data keeps pouring in from the scale and I only read the data every second or so, am I really reading old data (ie FIFO)? Should I be clearing out the buffer before each read?

 

And for the single byte reads to find the "=", I would have to do that each time I read if I'm not reading constantly, right?

0 Kudos
Message 15 of 16
(995 Views)

IMSargon,

 

If you want to be absolutely sure you are receiving the most recent data packet, then yes, clear the buffer before each read. But you need to make sure you are reading in each entire string instead of just one character at a time. Otherwise you'll just be picking out a character and clearing the rest of the string.

Will
CLA, CLED, CTD, CPI
LabVIEW Champion
Choose Movement Consulting
choose-mc.com
0 Kudos
Message 16 of 16
(966 Views)