ivi scope only sets aquasition first time

[Muffin]

So I have an odd issue.  I am useing the IVI scope driver to control my scope over GPIB.  My routine initializes the scope and then loops waiting for what to do.  The first time I call the subvi to setup for a capture it works great.  Sets all the aquasition info like trigger level, channel, type.. all that stuff.

Subsequent calls don't do anything though.  No error codes, just does nothing.  The initiate command does continue to work.  I just cannot change any of the aquasition settings like trigger level or channel or anything. 

Please help.

[Muffin]

One thought.  Being IVI I call the initialize function with the logical name and then store the handle.  This handle is passed to the routine that performs all the aquasition settings, but it is not restored.  So the next time the original handle is re-passed to it.  I assumed the handle didn't change as it was passed in and out of the IVIScope functions.  If I probe it it stays the same, but maybe there is something underlying that is changing????  Anyone know?

I mention this because it always works the first time I fire up the program.

[Dennis_Knutson]

Can you post an image of the block diagram? I don't quite understand exactly you are doing, especially the statement 'loops waiting for what to do'. I would be using an event structure. Also, I'm not sure how you are storing the handle? A shift register?

[Muffin]

Picture would be rough.  The handle is stored in a global cluster (array of them since I have two scopes).  The code is parsing an array of commands and performing the appropriate action for each one.  The set aquasition is just one of the commands it accepts along with a "setchannel" to set the vertical and a "getdata" to read the captured data after a trigger event.

I have a simple command sequence loaded to test this that just simply sets up the aquasition for the scope and then applies the input signal so it captures.  First time I run this after starting the program everything works great; I mess the scope up manually prior to running this so it has to change everything.  The program doesn't exit after a run so you can load a new sequence or repeat the last sequence.  If it manually change the stuff on the scope again and then run it again, it doesn't change it all back like the first time.  Everything stays messed up and I get no errors.  It will continue to do nothing until I stop the program and restart it.

[Dennis_Knutson]

Why would messing up manually force your code to change anything? With the state caching feature, the only time the IVI driver will send commands is if the commands in the program change. There is no built-in feature to check the current state of your instrument unless you write it yourself.

[Muffin]

Because I mess the scope up prior to the code running that routine.

[Muffin]

OK, so I wrote a simple VI to test this driver out.  It simply initializes the scope and the in a while loop, sets up the aquasition.  I put a breakpoint at the end.  I first mess the scope up so everything is off.  Then run the program.  It fixes everything nicely and stops at the breakpoint.  I mess the scope back up and resume the program.  Once again, it does nothing, no errors.  I tried this on both my scopes, both behave the same.

I even tried re-writing it to use instrument specific drivers and it does the same thing.  It seems the VIs work great the first time and then fail to do anything after that until the program is reset or the initialize VI is called again.  I really don't want to have to call the initialize function prior to every routine.

Any thoughts here?

I also tried this on the vertical setup and same issue.  I even called the setchannel twice in a row and it worked the first time and failed the second.  No errors of course.

[Shane-C]

Does this problem only occur after manual changes?  If you run your code twice to do programatic changes, does it make any difference?  It sounds like maybe you are not closing references correctly.

[Muffin · Accepted solution]

OK, found the "problem".  The driver is too smart.  If you command it to say trigger on CH1, it remembers this.  So if later you ask it to trigger on CH1 again it doesn't actually set the scope; it assumes it is still set to CH1.  Not good it someone manually changed this setting in the interm.  There is a function to invalidate all parameters that fixes this.  If you call this first, it clears the history and it will always try to set the parameters.

Perhaps I am paranoid, but I do not trust that someone will not hit something mid-test. 

[Dennis_Knutson]

That is exactly what i told you about the state caching feature of IVI. Instruments can be behind a locked door. Operators can be punished for touching an instrument.