how to release control of scope without destroying ivi scope object

[Dr_Jonno]

I have a measurement studio application which connects to ivi scopes and allows the user to grab data from the scope whenever they choose. Unfortunately, as soon as I create the NiIviScope object (initialising it with the logical device name specified in MAX) I loose manual control of the scope. So I can't change the voltage range using the knob on the scope, for example. I can do it only in software, which I don't want to do. Deleting the IviScope object DOES release control back to the scope. However, when the user clicks the "grab data from scope" button of the application, I don't want to have to each time:

create the scope object

grab the data

delete the scope object

- THIS IS TOO SLOW.

Is there some way I can create the ivi scope object once, then release control (without deleting the scope object), and only take control of the scope when the user has asked to grab the data?

I'm using measurement studio 6, c++, IVI drivers for scopes over GPIB. Any help in any programming language would be gratefully received!

[Glenn Burnside]

I can't verify this without seeing the code for the specific drivers you're using, but the driver itself is probably locking out device front panel control when it initializes, and unlocking it when it closes. So as long as you have a session open to the device, you're going to be locked out of the front panel. It is the opening of that session that is the performance hit, so even if you defer the act of opening the session until after you've created the scope object, you would still see the same performance you're seeing now. When you say that the operation is too slow, how long is it taking, and how fast do you need it to be? Can you post the code that actually acts on the scope, and can you let me know what specific drivers you are using? In general, IVI drivers are not really designed for mixed programattic and interactive control - that kind of usage tends to wreak havoc on their state caching.

[Dr_Jonno]

Thanks for the quick reply. The (simple) code i'm using is given below - 210scope is the Locical name for the ivi driver I' musing, tktds2x0. I'm using the tecronix 210 scope, althoug I do have other scopes with IVI drivers I haven't tried yet.

where m_pScope is a CNiIviScope pointer:

m_pScope = new CNiIviScope("210scope", false, false);
 m_pScope->Measurement.ReadWaveform("CHANNEL1", 10000, waveform, xFirst, xInc);
  double range = m_pScope->Channel.GetRange("CHANNEL1");
  double offset = m_pScope->Channel.GetOffset("CHANNEL1");

delete m_pScope;

It takes a few seconds - perhaps 5 secs - to establish communication with the scope, and another 1 or 2 seconds to grab the data. One or two seconds is acceptable.

You seem to be suggesting that because IVI does offer state caching, local control of the scope will always be locked, and there is no 'better' or faster way to release control to the user, other than deleting the scope object (and therefore the session). Is that correct?

I guess I can maximise connection time by unchecking all the initialisation options which may slow it down, such as 'range check' etc. Anything else I can do?

[Glenn Burnside]

Changing the initialization options is not going to have any noticeable effect on the time it takes to init the driver. There are some other things we can do to "cheat", but we're going to have to drop down to making calls to the specific driver rather than through the class driver:

m_pScope = new CNiIviScope("210scope", false, false);
ViSession specificDriverSession = m_pScope->GetSpecificDriverSession();

// "LOCK NONE" is the tek200 series command to unlock the front panel during remote operation.
tkds2x0_WriteInstrData(specificDriverSession, ":LOCK NONE");

//Then, when you want to actually read the data:

 m_pScope->Measurement.ReadWaveform("CHANNEL1", 10000, waveform, xFirst, xInc);
double range = m_pScope->Channel.GetRange("CHANNEL1");
double offset = m_pScope->Channel.GetOffset("CHANNEL1");

If you do this, you shouldn't have to close and reopen the session repeatedly.

BUT - it's only going to work with the tek scope. You will need to link in the tktds2x0.lib file and include the tkds2x0.h header in your project. If you need the application to work with other scopes as well, there are other tricks we can employ - like pulling the specific driver prefix from the class driver, doing a LoadLibrary and GetProcAddress to get the WriteInstrData function pointer, and then use the config store to keep the command to send (if needed) to unlock the front panel associated with the Driver Session for each kind of scope you need to support.

[Dr_Jonno]

OK, thanks. I would like the same functionality for ANY ivi scope. Could you please clarify a couple of points:

1 - will ALL IVI scope drivers have an exported WriteInstrData function?

2 - for the general case, are you basically suggesting to have a 'lookup table' with specificdriver name, or prefix and the command to unlock the scope? I could have this data in an external file.

3 - you mentioned using the 'config store to keep the command to send'. What is this config store?

Many thanks for your help

[Glenn Burnside]

1) IVI-C drivers written with National Instruments driver development tools will include WriteInstrData and ReadInstrData functions. Unfortunately, those functions are not required in order to comply with the IVI specifications, so drivers written with other tools or from other vendors might not have them.

2) You're exactly right - you'd need a way to look up the command to send for each specific driver. That lookup would probably need to be done based on the specific driver's prefix.

3) The config store is the file that maintains all of your IVI Configuration information. When you define logical names, driver sessions, etc. in MAX, all of that information is stored in the IVI Config Store. It's an XML file located in c:\program files\ivi\data\iviconfigurationstore.xml. The config store includes a limited extensibility mechanism by which you could associate information for a specific driver with that driver session or software module, and then programmatically retrieve it through the IVI Configuration Server API. However, this may be too heavyweight a solution for your needs, if this is the only setting you need to hack around like this. Maybe it makes more sense to keep the information in a separate, more manageable file.

Most devices that can programattically lock out the front panel have some sort of override button that lets you re-establish local control, so you might not even need to handle it programatiically for some other devices. Do you have a fixed set of devices you want to support, or are you writing an application you need to work with whatever scope the user happens to have?  Another idea, if you're willing to try it, is to remove the "Lock All" command from the Tek driver's initialization routine and rebuild the driver. The downside of this approach is that you're going to have to maintain your own version of the instrument driver.

[Dr_Jonno]

Excellent. Thankyou very much for the info. I'll go down the separate file route to maintain the unlock command and driver prefix. As a fall back (for 'unknown' scopes if the device prefix is not in the file, I'll give the user the 'fast' option of leaving the panel locked, or 'slow' option to unlock each time by deleting the scope object after each readwaveform.

We do have a specific set of scopes, but we want the software to be relatively 'future proof' so any new scope will work (to some extent) 'out of the box'. There may also be a limited distribution of the app.

Thanks again