Function returns error when using specific driver handle
Hello,
i created a c++ DLL for the IviDmm class and i am calling the keysight 34980 ivi driver. The Dll contains all generic functions.
Now i wanted to run a specific function of the 34980A-driver. For this execute "iviDMM_GetSpecifiDriverCHandle" which returns a numeric handle without error.
Then i run a function of another custom c++ DLL where i call some specific functions. For example: ... viStatus = Ag34980a_SetAttributeViBoolean (Vi, Channel, AG34980A_ATTR_OUTPUT_STATE, State); ...
For the parameter "Vi" i pass the specificDriverCHandle that was created by the other DLL.
But the function returns:
-1074135040 = Failure cannot recover.
What is the error here?
Thanks
Best Answer
As I've explained, the GetSpecificDriverCHandle isn't working with that driver for a good reason -- there IS no IviDmm support for that class in the IVI-C driver. Creating a separate driver session isn't going to change that, and certainly could introduce some unexpected behavior. It's the same as if two totally separate applications (processes) were talking to the same instrument, so whatever might happen in that scenario could happen to you. Any state managed by the driver, such as simulation state (which the IviSwtch implementation uses *very* extensively), will be totally separate between driver sessions.
So, in short, using GetSpecificDriverCHandle is the proper mechanism for doing class-compliant and instrument-specific programming against the same IVI-C driver session -- and that's the only mechanism you should try to use. Your problem actually has nothing to do with that -- your issue is simply that you're trying to program against a class (IviDmm) that your IVI-C driver doesn't support.
Hope this helps.
Edit 1: When i execute the Init function of the specific functions and use this handle then i can use all other specific functions. So the problem has to do with the created handle of "iviDMM_GetSpecifiDriverCHandle".
Edit 2: Exactly the same method for the IviScope is working fine. Means i can execute a specific function using the vi handle from "iviScope_GetSpecifiDriverCHandle".
Here some information if someone is getting into the same problem:
I am not sure if this behaviour is IVI-conform?
****
The Ag34980a IVI-C driver does not support the IviDmm instrument class.
The Ag34980a IVI-COM driver does support IviDmm but not the IVI-C driver.
If you want to use IVI-C to access 34980a DMM functionality, you must use the Ag34980a instrument specific driver exclusively.
The call to IviDmm_init function worked because all IVI-C drivers support the _init function but calling it via IviDmm is not valid for Ag34980a.
You must use Ag34980a_init and “Ag34980a_” prefix for all function calls.
****
That driver, I believe, is a special case where it supports more than one instrument class (IviDmm and IviSwtch). IVI-COM drivers can support multiple instrument classes, but IVI-C drivers can only support a single instrument classes because the attribute value #define's (IVI_DMM_ATTR_XXX) overlap in values between instrument classes.
Hi Kirk, can it be a problem if i execute for the same logical-name a) "IviSwtch_Init", b) "IviDmm_Init" AND c) "Ag34980a_init" together in the same program?
I need switching, generic dmm-functions and now also specific 34980a-functions
Or does the specific init resets something in the other class?
Thx
Yeah, it's probably a problem. I would expect that the handle you get back from IviDmm_Init is a handle to the class driver and couldn't be used to talk to the specific driver. But, maybe NI can chime in here and confirm or dispel that theory.
Note, however, as per my remarks above, you can't use IviDmm_Initi anywhere with that driver because the IVI-C driver doesn't support it -- only the IVI-COM one does.
Yes the handle from IviDmm_Init is working only for the class driver. For this normally i could use IviDmm_GetSpecificDriverCHandle. But for the 34980 this is not possible.
Thats why i have to execute an additional specific Ag34980a_init to get a handle for the specifc functions. This workaround is working.
The question is only if this third handle to the same instrument makes a "damage" in in the other two handles of the DMM and Switching class.
