IviScope vs. niScope Hierarchy

[MarkL@Hon]

I am using LabWindows/CVI to add instrument specific calls to an existing wrapper to an IviScope driver.  I am using an NI scope (specifically a PXI 5114).  Up til now all calls have been to IviScope_*  functions and all attributes used (get/set) have been inherent attributes (IVISCOPE_* defined in iviScope.h).

I now need to add the use of an instrument specific attribute (or is it a class-defined atribute?).  Specifically, I need to set NISCOPE_ATTR_MEAS_OTHER_CHANNEL, which needs to be set before use of the instrument specific call to niScope_AddWaveformProcessing.

I am confused about the hierarchy of IVI-C Class Driver calls vs instrument specific driver calls.  Is it true that all calls to IviScope_ functions are "converted" to intrument specific calls in the IVI engine (through the IVI Configuration store)?  If there is a callback defined for an intrument specific attribute will it still be executed if I call IviScope_Set...?

Here is the specific example but I would like the answer generalized to all cases if possible.

Since NISCOPE_ATTR_MEAS_OTHER_CHANNEL is defined as an offset from IVI_SPECIFIC_PUBLIC_ATTR_BASE,

Is this call legal:

 IviScope_SetAttributeViString(session, "0", NISCOPE_ATTR_MEAS_OTHER_CHANNEL,  "1");

and functionally equiv to:

niScope_SetAttributeViString(cHandleSession, "0", NISCOPE_ATTR_MEAS_OTHER_CHANNEL,  "1");

That is, if there is a calllback defined for NISCOPE_ATTR_MEAS_OTHER_CHANNEL that does something more than just set a specific memory location (and would be executed if niScope_SetAttributeViString is called), will that callback be executed if I set the attribute via IviScope_SetAttributeViString?

More generally, can I use IviScope_ function calls to set "items" that are defined (in niScope.h) in terms of offsets to IVI bases (IVI_SPECIFIC_PUBLIC_ATTR_BASE, IVISCOPE_VAL_TRIGGER_TYPE_SPECIFIC_EXT_BASE, IVISCOPE_VAL_TRIGGER_COUPLING_SPECIFIC_EXT_BASE, IVISCOPE_VAL_ACQUISITION_TYPE_SPECIFIC_EXT_BASE, IVISCOPE_VAL_MEASUREMENT_FUNCTION_SPECIFIC_EXT_BASE, etc)?

All the examples I see online about using IVI drivers, videos for DMM examples, actually show the use of the instrument specific function calls, not the IviDMM_ calls.  This seems misleading and confusing.  I have not seen anything that discusses the use of IVI drivers at this level.

Thanks for your consideration.

[A_Donfigulation_Error_Has]

Hi MarkL,

Is there a reason why you would want to do this? There may be a better way.

Jason L.

[MarkL@Hon]

Jason,

Thanks for your response but your question is wide open.  I have no idea what part you are questioning.

I am new to a program that has made decisions, based on customer requirements, to provide another layer of abstraction above IVI.  Sure, there is always a differrent and maybe a better way to do it but I am not taksed with changing the approach.  I am supposed to work within the established guidelines that were defined.  That said, I am more than willing to consider and even try to champion a change but the program is already well on its way.  And, even if you suggest an alternate approach, I would still like an answer to the question below.

This wrapper is supposed to use IVI calls when at all possible (to save as much of the concept of interchangeability as possible) and only resort to instrument specific calls when IVI calls do not provide the needed functionality.  This means doing as much as possible through the use of attributes as opposed to instrument specific function calls.  I hope this clarifies.

Now back to the original quesiton ("maybe" worded a little better after the reading I have done).   Caveat: I have no prior experience with IVI. 

If there are callbacks defined in, niScope, for an instrument specific attribute (i.e. one that is defined as NISCOPE_* and is defined in niScope.h as an offset from an IVI BASE), will those callbacks be executed if I set the attribute via a call to IviScope_SetAttribute as opposed to having to call niScope_SetAttribute? 

A Specific example.  Is

IviScope_SetAttributeViString(session, "0", NISCOPE_ATTR_MEAS_OTHER_CHANNEL,  "1");

functionally equivalent to

niScope_SetAttributeViString(cHandleSession, "0", NISCOPE_ATTR_MEAS_OTHER_CHANNEL,  "1");

I suspect the answer is yes, but I want confirmation as other developers on this project seem to have differing opinions.

[TimmTheEnchanter]

Hi Mark,

If I am correct, you opened a service request 7339211 related to this issue you are seeing and talked with Tim.  I was working with Tim on that issue, and it came to my attention you posted here on this discussion forum as well.

In general, the IviScope_GetSpecificDriverCHandle function that you mentioned helped you in the service request is provided to help transition instrument specific driver calls and class driver calls.  Using this function NI-SCOPE has the ability to communicate with the same instrument as IviScope using a translated driver session reference.

I believe I understand what your generic question is on this forum (whether a callback in NI-SCOPE will be treated the same when called from IVIScope).  Unfortunately, I'm not able to answer your question at this time, but I wanted to let you know I'm investigating it and I will try to post back as soon as I am able.

It sounds like you have a few different kinds of instruments (not just the 5114 digitizer) for which you may have similar requirements.  That is--designing code with IVI drivers that call into specific drivers (niScope, niDMM, etc.)  Is that the case?  What are the different kinds of instruments?  Have you or your peers done any similar development with these instruments, or do you have plans to?

-Andrew

[MarkL@Hon]

Andrew,

Yes, I did have a ticket open with Tim.  It was working down this same path.  The use of IviScope_GetSpecificDriverCHandle resolved that part of the issue.  Yes, the same approach is being used for DMMs, Power Supplies, Switches, Function Generators, etc.

Not sure if the way you paraphrased my question is what I am looking for.  It could be but I am not sure.  I think that what I am asking should be a simple answer for someone that has access to the niScope source code (and knows how the IVI engine/configuration works).  This makes me wonder whether I am being clear enough.  I may be obscuring the question when I talk about callbacks as that is part of the IVI engine/configuration.

This is the main question: Is it valid (functionally equivalent) to set an "instrument specific attribute" via an IviScope class driver call or do I have to set it via a call to the instrument specific niScope function?

This is the part that I threw in that may have confused the issue but is the root of my question.  The document, LabWindows/CVI Instrument Driver Developers Guide says that there can be up to 6 callbacks defined for each attribute (Read, Write, Compare, Coerce, Range, Check).  When a call is made to an niScope_set/get/check function, if a callback is defined/registered for that specific attribute, the callback is executed.  These callbacks are what communicate directly with the instrument and with the IVI engine to maintain state information.  My underlying question was whether a defined callback gets executed if I set/get/check an instrument specific attribute via an IviScope function call?

The more I read and look into this the more I believe the answer is yes.  I was looking for confirmation from the authorities.  A yes answer will take some complexity out of this wrapper as I can call the IviScope set/get functions and not have to decide whether to call IviScope for inherent attributes and niScope for instrument specific attributes.

Mark

[TimmTheEnchanter · Accepted solution]

Hi Mark,

Is it valid (functionally equivalent) to set an "instrument specific attribute" via an IviScope class driver call or do I have to set it via a call to the instrument specific niScope function?

Yes.  Setting an attribute through IviScope with the IviScope session handle is functionally equivalent to setting the attribute through niScope with the niScope session.  When you call the IviScope_SetAttributeViInt32() function, that translates into the instrument-specific driver (niScope) to set the same attribute.  Specifically, when you are calling that function to set theNISCOPE_ATTR_MEAS_OTHER_CHANNEL attribute, it will be useful for any hardware that is controlled by the NI-SCOPE driver which supports that attribute.

However, you cannot access every function of niScope through IviScope with the IviScope session handle.  This is the purpose of the IviScope_GetSpecificDriverCHandle.  IVI compliance does not require that everything be exactly the same from one instrument to the next (if it did, the world would be rather bland).  Furthermore, if IVI did require an equivalent function that accounts for every function call of every IVI compliant driver, the task of making the IVI class layer would be unending.  IVI compliance means that only the most basic functions, such as Configure, Initiate, Read, Close, etc. are interchangeable.

Also, as far as callbacks go, they are irrelevant.  Whether or not an niScope driver call includes a callback, there is no difference in setting an attribute through IVI or making an IVI function call, and doing the same with an IVI compliant driver like NI-SCOPE).  This is because the IVI class call really doesn't have much more complexity than translating into an instrument specific driver call.  Whatever the instrument specific driver call does, at the end of the day it simply needs to return a value to the IVI class layer, which is then returned to the user.

Just to be clear (for anyone else reading the forum), the IVI class driver is linked to specific instrument drivers (such as NI-SCOPE) through MAX. Part of the IVI name is "Interchangeable"--this is because any function calls (such asIviScope_ConfigureAcquisitionRecord or IviScope_Initiate_Acquisition) are common to many different scope/digitizer instruments.  When you've linked up the IVI class driver to the instrument specific driver through MAX, these common function calls will then translate into instrument specific driver calls.  One scope/digitizer from one manufacturer should run like another scope/digitizer from another manufacturer, so long as the instrument's driver is IVI compliant and these fundamental functions are used.

However, when you are trying to modify specific attributes (which can vary from manufacturer to manufacturer, or can even vary between products from the same manufacturer), then IVI only gives you the ability to modify or read those attributes--it is no longer "interchangeable" between digitizers/scopes.  So while NI-SCOPE may have an attribute calledNISCOPE_ATTR_MEAS_OTHER_CHANNEL, and IVI provides a way to change that attribute, that attribute cannot be recognized by other IVI compliant instrument specific drivers from other manufacturers.  What this basically means is that you must set upif...then... statements or case structures (or the equivalent) to handle each attribute on each scope/digitizer independently.  Similarly, specific functions that cannot be accessed through IVI (where you must use the IviScope_GetSpecificDriverCHandlefunction first and then make the instrument specific driver call, as mentioned before) must be handled in some kind ofif...then... statements or case structures to make particular exceptions for each scope/digitizer.

Hope this helps.  Please let me know if you have further questions,

-Andrew

[MarkL@Hon]

That is exactly the kind of discourse I was looking for.  Thank you.

[TimmTheEnchanter]

Glad I could help, and sorry about the delay.  I'm working with Roman on your other case right now, as well.  We can talk more about that in the Service Request itself.

-Andrew