GPIB No data received

[Moting]

Hi all, I have encountered a problem with GPIB in communicating with the Optical Spectrum Analyzer(OSA).

When OSA was acquired 5000 points of data to the computer through Labview interface, yes it can work. HOWEVER, when OSA was acquired 10000 points of data to the computer, the program don't work and the byte count I normally use is 4096000.

I suspect that if need to acquire more data from OSA, the byte count got to increase to a certain value. The maximum byte count value is 2147483647. So by try and error I increase the byte count between these two values, the 10000 data still cannot be retrieved.

Another idea I think it was not because of the byte count, but the file that I need to save these 10000 points is too big.

The attached is the picture of Labview VI. Please let me know what the problem is, whether due to byte count or I need to change anything. Thank you!

[SteveChandler]

I can't see jpeg files on my phone. But maybe you can try to read the data in chunks. Read for example 5000 bytes at a time in a loop and concatenate it together using a shift register. It might be something entirely different but not being able to see the code this is what comes to mind. I'll take a look tomorrow but I'm sure someone else will chime in before then.

[Moting]

Thank you Steve. I will try to use a shift register, see whether it can work or not. Meanwhile, please kindly look at the attached file when you are able to. Maybe you would have a better idea 😃 Thank you thank you!

[Moting]

In addition, the format that GPIB read is something like ( 2.400, 3.674,5.235, 5.523, 1.435.......) with data seperated by commas and this consist of one chunk of data.

If OSA was turned to control 10000 data points, the GPIB read should contain 10000 points. How to use the shift register to control such that all 10000 points will be read out?

[smercurio_fc]

You're confusing points with bytes. A point isn't the same thing as a byte. 2.400 is one point. It is 5 bytes. Thus, the number of bytes you have to read is the (number of points X the number of bytes per point) + ((the number of points - 1) X 2) + number of bytes for termination + number of bytes for header, if any. I think that math is right. The second addition is due to the separation characters between the "points". If you need to save this amount of data then you have to do as Steve said and read it chunks. Otherwise you will likely run into a timeout issue. You can use the file writing functions inside a loop to append to the file as you read the data. You should also look to see if the data can be transferred in binary mode rather than ASCII. This will reduce the amount of bytes you need to transfer.

Also, you should be using VISA instead of the lower-level GPIB functions.

Have you looked in IDNET to see if there's a driver for your instrument?