Instrument Control (GPIB, Serial, VISA, IVI)

Showing results for 
Search instead for 
Did you mean: 

programmatic reset results in corrupt data

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
0 Kudos
Message 1 of 7
Are you waiting long enough for the instrument to reset itself?
It is possible that instruments send during the *RST can get lost.
greetings from the Netherlands
0 Kudos
Message 2 of 7
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.
0 Kudos
Message 3 of 7
Hello RJ,

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


Applications Engineer
0 Kudos
Message 4 of 7

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.

0 Kudos
Message 5 of 7
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.
0 Kudos
Message 6 of 7
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.
0 Kudos
Message 7 of 7