Ivi : logical name sent to specific init function instead of rsrc descriptor

[pak]

Hi,

"But there’s a crucial piece of information missing here: Can he use a logical name or driver session directly with his specific driver? "

==>It doesn't work when I give a logical name to the prefix_initialise() function. But there is an "interesting" point : if I give a bad logical name as parameter, I don't have the error that tells me the logical name isn't valid. So it brings me back to a question I asked in my first post and you didn't really answer :
Have the accesses to the configuration store to be done by IVI class drivers, or by the specific driver I wrote ?

My configuration store file is attached to the post.

Thank you for your help

Message Edited by pak on 07-20-2005 04:09 AM

Message Edited by pak on 07-20-2005 04:10 AM

[Glenn Burnside]

First, to answer your question: Both the specific driver and class driver need to access the config store, but for different reasons:

1. The class driver accesses the config store to resolve a logical name or driver session name to an actual driver session, so that it can determine from the driver session what software module to load. The class driver returns error information based on an assumption that you are always passing it either a logical name or a driver session name.
2. The specific driver accesses the config store to resolve a logical name or driver session name to an actual driver session, so that it can find things like virtual channel names that have been defined, initialization options, default property settings, etc. However, if you pass a "bad" logical name, the specific driver doesn't know that you meant it to be a logical name - you might have meant it to be a VISA resource descriptor (or a VISA resource descriptor alias.) 95 times out of a 100, if you're calling the specific driver directly you're using a resource descriptor to initialize, not a logical name - so the driver reports the error back to you focusing on the fact that it can't resolve the resource descriptor.

Now, on to your config store issues:

You have a logical name "bu3430", but it doesn't refer to a driver session. You have a driver session called "NewDriverSession", which it looks like is supposed to be the driver session you're trying to use. You should go ahead and give it a different name, and then set the logical name's driver session to that. The driver session itself looks like it's set up ok - it points to the hardware asset you want to use, and the software module for the driver.

Before you make any changes to the system, I'd like to run one more diagnostic on it - call the specific driver with the DriverSession name instead of the logical name - bu3430_init("NewDriverSession", VI_TRUE, VI_TRUE, &vi); That ought to work. If it doesn't, we might have deeper problems. If that does work, do the same thing with the class driver - that also ought to work. Assuming both of those things succeed, go ahead and modify the logical name as I outlined above, and then try first the specific driver and then the class driver with the logical name.

Before you do that though, I'd like to run a test on the system.

[pak]

Hi,
The fact is that I had done lots of test on the configuration store, and when I sent the file I wanted to clean it a little and give it its original configuration. But I made a mistake. That's why there is that "NewDriverSession". Before my tests the configuration store was as you describe it should be. And it didn't work.

And of course when I try  "bu3430_init("NewDriverSession", VI_TRUE, VI_TRUE, &vi) " it doesn't work.

The problem is that I created the specific driver on my own, using CVI 5.0 templates for IVI_scope. But in that template, there is no call to the configuration store. And as nothing was written telling me to do so, I thought it was done by the class driver and that it was the class driver which retrieved the resource descriptor and gave it to my specific driver. Moreover, when I look at the FP file created by CVI wizard, it is said that the parameter for "bu3430_init()" should be a resource descriptor. So I was sure I had nothing to do about the configuration store. Here is part of the initialise function code generated by CVI 5.0 IVI driver wizard :

ViStatus _VI_FUNC XXXX_IviInit (ViRsrc resourceName, ViBoolean IDQuery,
                                    ViBoolean reset, ViSession vi)
{
    ViStatus    error = VI_SUCCESS;
    ViSession   io = VI_NULL;
   
    checkErr( Ivi_BuildChannelTable (vi, CHANNEL_LIST, VI_FALSE, VI_NULL));
   
     /* Add attributes */
    checkErr( XXXX_InitAttributes (vi));

    if (!Ivi_Simulating(vi))
        {
        ViSession   rmSession = VI_NULL;

        /* Open instrument session */
        checkErr( Ivi_GetAttributeViSession (vi, VI_NULL, IVI_ATTR_VISA_RM_SESSION, 0,
                                             &rmSession));
        viCheckErr( viOpen (rmSession, resourceName, VI_NULL, VI_NULL, &io));
        /* io session owned by driver now */
        checkErr( Ivi_SetAttributeViSession (vi, VI_NULL, IVI_ATTR_IO_SESSION, 0, io)); 

        }
       
    /*- Reset instrument ----------------------------------------------------*/
    if (reset)
        checkErr( XXXX_reset (vi));
    else  /*- Send Default Instrument Setup ---------------------------------*/
        checkErr( XXXX_DefaultInstrSetup (vi));
[...]
This code was generated two minutes ago by CVI's wizzard, it is not my own.
As you see, there is no call to the configuration store. Am I supposed to add lines of code to access the configuration store and retrieve the resource descriptor here ?

Thank you for your help

David

[Glenn Burnside]

The IVI system went through some significant alterations in 2003, when the IVI Compliance Package version 2.0 was released. This was concurrent with the release of CVI 7.0. If you are writing IVI drivers to comply with the current IVI standards, I recommend that you upgrade to CVI 7.

However, I would still expect the driver to resolve the hardware asset. You do not need to make calls to the config store yourself - that occurs inside the Ivi_SpecificDriverNew function, which is called prior to calling Ivi_IviInit. SpecificDriverNew takes the logical name the user passed in, and returns the actual hardware asset resource descriptor. This is the resourceName you should be passing into IviInit.

Given the nature of the problem you're having, I believe I could troubleshoot it tomorrow if you can send me the source and header file for the driver.

[pak]

Hi,
The source is attached to the file. "bu3430i_functions" functions are calls to our C usual drivers.
Thank you very much for your help.

[Glenn Burnside]

It looks like your InitWithOptions function is missing a call to "Ivi_GetInfoFromResourceName". I've included a copy of the function as it is generated directly from the templates (see attachment):

The GetInfoFromResourceName function takes the logical name or resource descriptor passed to the driver's Init or InitWithOptions function, and returns the hardware resource descriptor associated with it in the newResourceName buffer - this is then what is passed into IviInit.

I hunted back to the templates that were shipped with CVI in 2000 - I don't have the original ones that went out with CVI 5.0 available to me.

The more I think about this, though, the less confident I am about the ability to generate a Class-compliant driver from the original CVI 5.0 templates. The class driver API's themselves went through significant, non-backward-compatible changes between the original IVI release in 1998 with CVI 5 and the next revision in 2000, based on massive changes by the IVI Foundation to what constituted a class-compliant interface. If you want to use the driver you're writing with Signal Express or other tools based on the class driver interfaces, I strongly recommend that you start with templates that are designed to generate a specific driver that conforms to the current IVI specifications.

[pak]

Thank you very much for your help. Now the right resource descriptor is fetched. Now I can start debugging...

Concerning the templates, I had downloaded the last version I found, which is on this link : http://digital.ni.com/softlib.nsf/websearch/F6EA855441DB50AC86256DC20050EAD9?opendocument&node=132060_US

That's why I thought I could trust them.

Thank you again for having taken the time to help me.

David

[Glenn Burnside]

Hi David,

    I didn't realize from your posts that you were using updated templates - since you mentioned you were using CV 5, I assumed you were using the templates that shipped with it, not the newer ones. If you're using the newest templates, everything should have worked fine out of the box. As a sanity check, I pulled the files from the link you provided, and in fact they DO include the call to GetInfoFromResourceName that was missing from your driver. Is it possible that during the course of driver development you modified the InitWithOptions function and removed that code?

Please don't hesitate to post with any other IVI driver questions you might have, as well.

[pak]

Hi Glenn,
I am sure I didn't modify this part of the file. Maybe the installation of these templates failed, or that CVI 5 doesn't use them for any reason, I need to find why CVI 5 still uses the old version of the templates instead of using the new one.
Thank you very much for your help.

David

[Glenn Burnside]

There are other aspects of your driver that appear the way I'd expect them to coming from the latest templates. Under your CVI directory, look in the wizard\ividrvr\Common directory at the "GenTmp.c" file - this is the template file that defines the core driver functions like InitWithOptions. The file should be dated 9/26/2003 if it came from the msi you downloaded. Also, you can check the file's content directly and confirm if it's missing the GetInfoFromResourceName call.