programmatic reset results in corrupt data

[cobinrox]

Quick and easy question for you all -- we have a really simple Java-to-C++ interface into an E4407B via the Visa GPIB interface, we just send a handful of commands to the specA programatically (e.g. *RST, and such) and get data back fine and for the most part it all works great, 24x7x365.

However, recently we added the capability to allow us force a reset, then a re-init of the set up values and restart the reading (this is in anticipation of eventually allowing us to programatically change some of the settings real time) of the data. The second set of commands to restart and reset seem to take ok, but when we start reading the data, it is all zeros or corrupt.

If we actually stop our program and restart it (i.e. stop the virtual machine and then restart it) it works, but we want to avoid having to do that.

So the question is: is it possible to reissue set up commands to the E4407B programatically, and if so, any idea why our data coming back is incorrect?

Thanks very much
RJ Cox
Colorado Springs, CO

[Albert.Geven]

Are you waiting long enough for the instrument to reset itself?
It is possible that instruments send during the *RST can get lost.

[cobinrox]

Good point.  I did try a 2-second wait, and I do get a "SWEEP" status thereafter, but I could try to bump it up even further.

[Meghan R]

Hello RJ,

Did a longer timeout solve your issue or are you still having a problem that I could help with?

Thanks!

Meghan
Applications Engineer

[cobinrox]

Yes, I did try extending the time, but that made no difference.

One curious thing that I notice, though is that if I use a default of 401 data points (rather than the 2048 that I actually need) and I do NOT set the number of data points after a reset, I can read the data ok.  As soon as I introduce a set the number of datapoints command after having done a reset, however, the data read thereafter is corrupt.  I'm summarizing the commands here, we actually perform:

RST, Check for Sweep Status, Set Number Data Points, Set Frequency/Scale, Set Data Format, Set Byte Order, Check Status, Get Data

We normally loop the last two commands, i.e. check status and get data.  But, when we want to do a reset by following the same command stream, the data is corrupt unless I do not send the Set Number Data Points command.  But since RST resets the number of data points to a default of 401, that doesn't help our particular situation since we want to use 2048 data points.

[cobinrox]

It looks like we have a glitch in the in-house written C DLL wrapper that communicates with the Visa driver.  However, anyone know what the difference is between a JNI DLL that has a function name starting with "Java_blahblahblah" vs "_Java_blahblahblah"?  The existing DLL (the one with the glitch) produced the underscore prefix, while the one that has been patched has no underscore; and we get unsatisfied link error on the latter.  That seems to be the only difference, at least when viewing them in a DLL viewer.  Thanks.

[cobinrox]

Yep, it was the glitch that was causing the problem.  Also just added an extra underscore to the Java_ prefix and the dll was rebuilt ok.