VISA string parse problem understanding

[Simon-lee]

I’m looking for some help parsing string data.

I’m playing with a cheap gas sensor, its talking (sending commands is hit and miss but once started it streams ok).

I’m trying to graph the CO concentration and write the data to csv.

I feel I must be missing some basic knowledge on VISA somewhere, I was expecting simple csv strings of data but my last attempt ended up at a 547mb csv. I was hoping that using line feed termination meant I had blocks of 65 characters to play with but I'm struggling to understand whats really going on. 

If someone can point me in the right direction I would be most grateful.   

P.S. I save the vi in 2017 if anyone need a earlier version please just ask 

[Bob_Schor]

You fooled me with your VISA configuration.  I was going to complain that you set up Termination wrong, but I realized that you set it up "to use the defaults" (I just failed to recognize you reset the Termination character to 0xA, <LF>, the default.  Most of us leave these terminals unwired, and accept the Default Values (rather than trying to set them to the Default, and possibly make a mistake).

But then you make the Very Common (and foolish) Error and use "Bytes at Port".  No, if your device that is communicating using VISA is using a Termination Character, you ignore Bytes at Port, and instead do a VISA Read (when you expect VISA to be sending you data, such as right after you give a VISA Command) and ask for many more characters than you expect.  Common requests are for 1000 characters (I tend to specify 1024, myself).  If your Device is acting as it should, it will send "a reasonable amount of data" (say 20-40 bytes) followed by a Termination Character, so your VISA Read will wait for the entire String and then present it to you.

Depending on how your device delivers data, you can simply write the entire String to a Text File (terminating with <CR><LF>), parse the String to get out the data, arrange it as you like, then write it as a Delimited Spreadsheet File, or whatever else seems reasonable.

Do you expect a single Command (such as "*IDN?") to produce many lines (strings terminated by <LF>) of responses?  Notice that if you have not pushed the Send Command button, the code will continually read (possibly 0 bytes) over and over, sending the string to the Queue where it will pile up fairly rapidly.

So study your device.  You might want to have a sub-VI called "Initialize VISA" that sends the *IDN? command and parses the results, then sends the "Now Start Sending Me Real Data and Don't Stop Until ... " (you have to think about how to stop your Device from sending data -- read the manual).  If you get rid of Bytes at Port, then the VISA Read will put "real" data onto the Queue at the rate the Device sends it to you, which is probably at a rate of 10-100 Hz (again, you haven't told us what the Device is, so I'm only guessing).

Bob Schor

[cbutcher]

---

@Bob_Schor wrote:

You fooled me with your VISA configuration.  I was going to complain that you set up Termination wrong, but I realized that you set it up "to use the defaults" (I just failed to recognize you reset the Termination character to 0xA, <LF>, the default.  Most of us leave these terminals unwired, and accept the Default Values (rather than trying to set them to the Default, and possibly make a mistake).

---

This is right, unfortunately... The type-cast is set to produce an I32, and the input is U8. The result is that the value given to Configure Serial Port is "0x0A000000" -> "00", which presumably isn't the end character (unless, of course, it is).

When I first saw the image, I was "going to complain" that the mechanical action was one of the Switch modes, and that you were reading multiple lines. However, the FP image shows that you managed to read part of a line in the last case. Coupled with the fact that given a valid TermChar and a number of bytes to read, you'll get whichever ends first, and I'm going to guess that in the case shown, you ended with the Bytes at Port value (multiple times?), which was less than the total string because you hadn't waited long enough yet.

As Bob pointed out, we'd need to know the device to really know the solution, but if the real TermChar is LF, you can either A) remove the inputs and use the default, avoiding the mistake making opportunities or B) use a U8 for the top input to the Type Cast, and then get "0x0A" (the same as the default), or C) wire the constant "0d10" U8 value (in this case, you can also use a larger numeric width and have it be coerced, but there's no reason to do that that I can see from this BD (and perhaps no reason I can think of at all)).

[Simon-lee]

Hi Folks,

I apologise for not including the sensor data sheet (DGS-CO 968-034) please find it below.

It came from Digi-key and cost 71 dollars – using Tera Term as described in the data sheet “C” start a continuous output and a “R” stops it. The promised timing options don’t seem to exist and the data stream is on a 1 sec cycle.

The data sheet is very sparse on detail so I made assumptions on termination. (first mistake)

The *IDN?\n and bytes at port are hang-overs from the example finder simple serial.

I’m going to have another stab at it today starting from scratch but any additional input would be welcome.

[cbutcher]

Hi Simon,

As you said, the datasheet is a little lacking in clarity regarding a possible termination character.

I'd first go ahead and try with the default (10, "LF" -> U8, etc - easiest just to not wire this connection to Configure Serial Port).

Hopefully the "CSV" values are terminated with some sort of end-of-line character (since otherwise, it isn't a CSV output), and everything will work a little better.

Just as a reminder, to do this (as Bob said) you'll need to remove the Bytes at Port and just wire a sizeable constant. In your case, the constant needs to be larger than ~80 (I didn't carefully count - I recommend stetting this to perhaps 200 or 300, but 1000 as was suggested by Bob Schor is also fine and removes the chance of a silly long output messing up your acquisition) ->(SN [XXXXXXXXXXXX], PPB [0 : 999999], TEMP [-99 : 99], RH [0 : 99], RawSensor[ADCCount], TempDigital, RHDigital, Day [0 : 99], Hour [0 : 23], Minute [0 : 59], Second [0 : 59])

Let us know if it still doesn't work!