Convert SGL to ASCII

[TCPlomp]

Michelle,

sorry for the misunderstanding, I should have used an I16 like the label says.
If I understand the documentation right, after each read? multiple reads can arrive at the serial port.
So what you should do is after the read wait 10 ms. or so, read all bytes at the port.
Remove the first two characters (#0), then typecast the rest to an array of SGL's, and convert this into a 2D array.
Could you save a VI with data in it and post it?

Ton

[Mkova00]

Hello,

Thanks for the help. I think that I have found the problem --- and it was actually with some of the SCPI code going to the picoammeter. I've redone it, and now a couple of the previous suggestions are working to convert the data. I've attached images of two different ways that I've tried. VI 14 takes two subsets of the buffer string -- one for the current and the other for the time -- and then type casts them separately to SGL. They are then sent to an array and written to a spreadsheet. (For this VI I've also included an image of the front panel indicators with the data.) The second way that I tried (VI 18) is running faster. In this I unbundled the data and type cast the current and time portions as SGL, then built the array, and sent it to a spreadsheet.

I apologize that it took me so long to realize that the problem was not with the LabView code!!!

The only problem I am having now is that the data is still only transmitting at 40 Hz (VI 14) to 70 Hz (VI 18) even though I have reproduced the example code for 900 Hz readings from the picoammeter manual. I'm thinking that I may have to try the previous suggestion of writing all the data to a front panel indicator, and then copying it out to save it after all the data has been collected. Perhaps writing the spreadsheet file is slowing it down?

Thanks again for everyone's help and patience!

Michelle

[TCPlomp]

Michelle,

good to know LV is right
But be aware, you tell VISA to read 100 bytes, and then you only parse two sgl's (2 header +2*4 data+2 footer)=12 bytes. So you lose a lot of data.
Then you open (and close) the measurement file every run, this will cost time.
What you could do is open a file before the while loop. Convert the sgl-array into an array with array to spreadsheetstring, and write this to the file (via the reference) and close the file after the while loop.

Also try to use the tool in my sig. for getting a screenshot, yours look a little noisy.

Ton

[Mkova00]

Hi,

Thanks for the suggestion. I've attached an image of what I tried, to make sure it's what you intended.

This was somewhat faster than opening the file for each reading: 80 Hz instead of 70 Hz. But still much slower than expected.

One of the LabView application engineers has suggested that I use a producer-consumer set-up so that as the data is read, it goes into a queue to be saved. I am working on figuring how to set this up now, but I'm definitely open to any other suggestions.

Thanks,

Michelle

P.S. Ton, I tried using the Code Capture tool from your signature, but the arrow on the VI is broken. When I click on it, it says no VIs with errors were found. I'm not sure what I need to do to remedy this? I apologize for the grainy screen snap attached!

[TCPlomp]

Hi Michelle,

you took half my advice (now if my boss did that I'd be happy)

You also have to limit the number of bytes you read every time! LV is waiting on 100 bytes don't get these and times out and returns all bytes it has.
This timing out probably causes the slow sample rate.
It is interesting to find out how many bytes are read every run (string length). If you have more than 14/16 (with termination) look at those bytes as well, maybe you are just putting these down the drain.

Ton

PS strange about the code capture tool, Maybe a recompile? (ctrl-shift run arrow) Otherwise you can use the diagram disable structure to disable parts of the code. If you do this half wise you will quite fast find what causes the error

[Mkova00]

Hello,

Ok, have taken the other half of the advice!

I switched the number of bytes to be erad from 100 to 14. However, the VI still only records at 80 Hz.

I've also tried the producer-consumer loop template. I got it working, but the VI still only runs at 70 Hz. (Image of block diagram attached.)

Michelle

[Dennis_Knutson]

Asking for a high number of bytes will not affect the acquisition rate and you will not get a timeout. The VISA Read will automatically terminate when the GPIB controller detects the EOI asserted by the talker. At 70 to 80 hz, you are talking about a 12 to 14 msec time for the instrument to perform a measurement, transfer it to it's buffer, and then transfer to the pc. You may simply be seeing a limitation of the instrument. Transfer rate is something that is usually in the instrument's specification. Certain instrument settings (i.e. autozero, resolution setting, etc.) can also affect how fast you repeatedly read. You might want to contact the instrument vendor to see if they have any recomendations.

Are you using the NI GPIB-USB-HS? You want to make sure that it's plugged into a USB 2.0 port. And if you have any other USB devices, you might want to try running without them.

[Mkova00]

Hello,

The instrument specs are for a maximum rate for the buffer of 900 Hz. The instrument manual, as well as Keithley tech support, suggests the following settings:

0.01 NPLC (the number of power line cycles between readings)

digital filters off

front panel display off

auto-zero off

binary transfer

language  = IEEE-488.1

All of these are being set appropriately by the SCPI code sent via the VISA before the while loop.

We're using a GPIB-USB-1 connection. We actually bought the cable from Keithley, and they sell it for just this purpose. So I don't think it is a connection problem. The only other USB connections to the computer are the keyboard and the mouse.

I'm going to try to reach Keithley support this afternoon to see if there are any other settings that may need to be changed.

Thanks for the help,
Michelle