Retrieve data from a GPIB Device (typecast?)

[Somnatic]

Well, it's me again 🙂

Here I have my device (still the agilent spectrum analyzer). I try to transfer the data from the esa to my pc via a GPIB connection.

I consulted the documentation and it said: :trace:data? trace1

Now I also have to tell my device, how many bytes it should read. How would I get that information - is there a status register somewhere or do I have to calculate that every time I retrieve the data.

the problem is:

When I retrieve my data, and I read too few bytes - I don't have all the information - which is bad 🙂

When I retrieve my data and I read too many bytes - the ESA tells me some error on the display (interrupted transfer or something like that).

I tried the express vi, which works just perfectly (or at least I think so). It somehow gets the number of bytes to read automatically. I checked it, the analysation tells me the correct number of bytes and even tells the right format without my ESA displaying a message - so it must be possible somehow.

And now for the third - type conversion:

I tried retrieving that data in ascii mode, which works, but is a little troubling, since the size for each entry changes. So I wanted to try binary format (which is basically an int32). But how can I convert the binary data to a int in labview. The express VI is able to do it - but how 🙂 I am quite new to this, so please excuse my questions 🙂

Thank you

[Somnatic]

ok, I found out that it's possible to view the code, the express vi creates 🙂

But I still have some questions:

I have 401 values. Every value is a 4 byte integer, that makes 1604 bytes. But why is the string I get from the ESA 1611 bytes long. I think I've been browsing thorugh the doc for a while, but I couldn't find anything 😞 Is there a GPIB reason to this ?

[Somnatic]

oook .. found out something new:

the data in front is:

#41604

I could say that 1604 is the number of bytes I have (401 x 4byte) - then .. what is #4 ?

[Dennis_Knutson]

There's probably an instrument reason for the extra bytes. It could be some sort of header with sampling info. Without seeing the instrument programming manual, I couldn't tell for sure. As far as telling how many bytes to request, you can safely specify some very high number. The VISA Read will automatically terminate when the instrument sends EOI at the end of the data transfer. If you're getting a transfer terminated error from the instrument, then you're sending another command before the read is done. If you're using dataflow with the error clusters connected, you don't usually get this error. It would help if you posted your code to see exactly what you're doing. I don't think the I/O Assistant doesn't really know how many bytes to read until it acutally does the first read in the test panel. I believe it does a read with a high byte count, determines how many bytes are actually sent, parses the data, and then creates the VI. I'll admit that I seldom use the assistant so there may be something else going on. Also, can I ask why you're trying to develop your own driver instead of using the one here?

[Somnatic]

> There's probably an instrument reason for the extra bytes.

Yup, I am currently thinking that as well, since the second part of the data matches the number of bytes, I just haven't found a reason for the first part 🙂

>It could be some sort of header with sampling info. Without seeing the instrument programming manual, I couldn't tell for sure. As far as telling how many bytes to request, you can safely specify some very high number. The VISA Read will automatically terminate when the instrument sends EOI at the end of the data transfer. If you're getting a transfer terminated error from the instrument, then you're sending another command before the read is done.

You were right ... I just checked that and ... voila ... there was some write access between reading a second time 🙂 Don't know why I didn't see that 🙂

> If you're using dataflow with the error clusters connected, you don't usually get this error. It would help if you posted your code to see exactly what you're doing. I don't think the I/O Assistant doesn't really know how many bytes to read until it acutally does the first read in the test panel. I believe it does a read with a high byte count, determines how many bytes are actually sent, parses the data, and then creates the VI. I'll admit that I seldom use the assistant so there may be something else going on. Also, can I ask why you're trying to develop your own driver instead of using the one here?

This is just going to be a very small application for repeated tasks (with a little extra on other devices) ... Using a complete driver looks like overkill to me 🙂 .. I haven't worked with external drivers, but if I find the time, I will try that one 🙂

Thank you for your help 🙂

(If anyone finds out what the first two bytes are - feel free to tell me - maybe I can get some better manual than I have here 🙂 )

[cymrieg]

# - means binary data

4 - means there is 4 bytes per value (in your case a reading). So you should pass in an array of data type 4 bytes ( C/C++ -> float, vb -> single etc, LabView -> no idea)

[Glenn Burnside]

That is not correct. The data in question is in IEEE488.2 Definite length block data format. That format is defined as #<digits><byteCount><bytes>, where <byteCount> is a number with <digits> digits. so #41604<data> means that there are 4 digits in the following number (1604), and then there are 1604 bytes of data to follow. Definite length block data length is always communicated as the number of bytes. It is contingent on the consumer of the data to know how to handle that raw data. Often, devices that return definite length block data will also provide services for finding a description of the data, such as floating point values for scaling, data width, byte orderting, etc.

[Somnatic]

interesting ...

how would you then say it is 11 digits ? that could be 1 or 11 or 11x ? How does the listening device know about this ?

[Glenn Burnside]

The format is always #<n><n digits>, where n is only one character, 0-9. definitelength block data supports at most the transmission of 999999999 bytes (that's largest value that can fit into 9 digits.) I have never seen an instrument come close to trying to send 1 billion bytes of data or more at a time. In fact, I don't know of any protocol that would try to do that - when you get into data transmission on that order, you probably want to transmit the data in smaller chunks, so if there's any kind of network failure during transmission, you can re-transmit just what failed, rather than having to send the whole thing again.

[Somnatic]

hmm .. after thinking it over .. makes totally sense 🙂

thanks for the explanation 🙂