Convert SGL to ASCII

[Dennis_Knutson]

I think it would also be helpful to see exactly what the manual has to say about the binary transfer. I agree with Brian that the type cast is causing the problem and seeing the raw data would help enormously.

[Mkova00]

Here is an example of the raw data from the read buffer string. I've saved it to a text file, so it opens up as ASCII characters. It should be reading about 5E-6 in the left column (5 uA) and a timestamp in the right column.

Let me know if there is a better way to save out this data for you to look at (other than a text file).

Thanks!

Michelle

[Dennis_Knutson]

That doesn't look right. If the #0 is a header, then there should be 4 characters after that for a 32 bit SGL representation. The idea of creating a string indicator on the front and saving a reading with a default value will work but I can't view an 8.2 file. Could you do something like the attached? The icons for 8.2 are different. It's a Open/Create/Replace File, a File Write, and File Close. If you could run this just once, I'd like to see how the data is stored.

Message Edited by Dennis Knutson on 11-21-2006 09:12 AM

[Albert.Geven]

I guess that the speed you think to gain by binary transfers is much less than the conversion speed of the instrument.
I think you are right in that binary is faster, but the difference is very small.

I support the question for a raw dump.
to get this create an indicator at the output of the visa read.
after running, make all values default, and save the vi.

[Mkova00]

I think there are a couple of reasons why the ASCII interpretation of the SGL signal may not look right. When the data is transmitted from the picoammeter in ASCII, there is a comma between the current value and the time stamp (attachment to Reply 7). I'm not sure how or if this is sent in binary. Also, the picoammeter manual mentions that there is also a terminator after each value sent as SGL, but it doesn't say what this terminator is or how long it is. Perhaps this is interfering with the conversion. I've attached a PNG image of the relevant page from the manual.

I tried wiring the suggested functions to save a reading from the buffer read string. I couldn't find a VI for "File Write" in version 8.2 of LabView. I used "Format to File," which was as close as I could find. The resulting file with a single reading is attached --although I don't know how to open the file except in Notepad, which interprets it as the same ASCII characters as the last VI (Reply 9). I've added TXT as the file extension so that I could post it. I've also included a PNG image of the block diagram showing how I wired the VI to create this file. I may not have done it as you had intended.

In the VI I also added a string indicator on the front panel. I don't mind using this indicator to capture the data and then saving it out after the experiment is complete; however, I am still faced with the challenge of converting the indicator readout (which is in ASCII) into a comprehensible number. Suggestions?

I'm hoping/expecting to gain a lot in speed by transmitting the data in binary. The instrument specs say that with the settings I'm using and binary transmission, we should get 900 readings/s over the GPIB bus. When we use these same settings with ASCII transmission, we've only gotten up to 75 Hz, which is insufficient for our application.

Thanks,
Michelle

[TCPlomp]

The format looks just like a LabVIEW SGL.
But your file is 10 bytes size and has the following content(hex):
23 30 B0 84 00 00 46 B4 4C A8 0D 0A
header #0 (23 30)
numbers (sgl) B0 84 00 00
number 2 46  B4 4C A8
termination 0D 0A
With the following code


The numbers are converted into:
-9.60426e-10
23078.3
Hope this give you some clues.

Ton

Message Edited by TonP on 11-22-2006 10:41 AM

[Dennis_Knutson]

Those are the numbers I'm coming up with too and they're not matching the 5e-6 and 2e2 ranges that the ASCII setup is retruning. I've tried manipulating the string and the result bits in numerous ways but no luck yet.

[Mkova00]

I'd like to try some conversions, but I'm not clear on how you are getting from ASCII to SGL. I don't seem to get the same numbers. Should I try going to hex in between? If so, how can I do that?

Thanks,

Michelle

[TCPlomp]

Hi Michelle,

what kind of code are you using?
I didn't do any conversion, I only told LabVIEW to view (a part) of the string as a SGL. It is only memory mapping.
Have you tried rebuilding my code?
You could also try this on your code:

Ton

Message Edited by TonP on 11-29-2006 07:31 AM

[Mkova00]

Hello,

I didn't try to rebuild the first code you posted. I'm not clear on where the input is for the data file/values on that one?

I did try building the last code you posted, but I'm still not getting the correct values out for the SGL numbers. (They should still be 5 uA and the time value, starting at zero. The current value is definitely wrong, but the time value does start at zero and go up from there.) I wasn't clear on what representation you used for the header. Your label says I16, but the unbundle says I32. I tried both with similar results. I also tried using two separate bytes for the header or using two separate bytes for the header and two for the terminator. I was very surprised when this didn't work. I set it up to record all the unbundled values (not just the SGL values) and found that it is reading out 35 48 for the header and 10 0 for the terminator. This was surprising to me, since these values don't reflect the ASCII (#0), binary, or hex (23 30) values for the header.... Any idea what's up?

I've attached an image of my last iteration with this code, so you can see how I've wired it.

Thanks for your help,

Michelle