Incosistent type declaration in instrument drivers.

[OleAndre]

I get the following 'Build Error' when trying to compile my project (CVI 7.1):

"Inconsistent type declarations for external symbol '_ESupportedOptions' in modules 'ag5313xa.c' and projectfolder\cvibuild.projectname\agn6700.nidobj'."

The enum declaration 'ESupportedOptions'  is declared in two different instrument drivers; ag5313xa.c, and agn6700.c. They are declared like this:

-----------------------------------------------------------

ag5313xa.c:

/*- Supported instrument options --------------------------------------------*/
enum {
  OPT_000 = 0,
  OPT_001,
  OPT_010,
  OPT_012,
  OPT_030,
  OPT_050,
  OPT_124,
  OPTIONS_COUNT
} ESupportedOptions;

---------------------------------------------------

agn6700.c:

/**
 * Define supported instrument options.
 */
enum
{
  OPT_054 = 0,   /* 0 - bit */
  OPT_761,       /* 1 - bit */
} ESupportedOptions;

What is the recommended solution to this? I can of course rename the declaration in one of the the drivers. But I do not think it is good practice to have to modify these public available drivers.

Regards

Ole André

Message Edited by OleAndre on 10-25-2007 02:33 AM

[NicoLeach]

If both variable have a limited-to-their-file scope, I would declare them as static enum {bla ...} ESupportedOption.

Regards,
Nicolas

[OleAndre]

Thank you for your suggestion Nicolas.

Yes I could do that, but these two files are both downloaded from National Instruments as IVI compliant. I do not know the details of the IVI compliance rules, but I would guess that one requirement is that all IVI drivers should work without modification together with other IVI drivers included in the same project. Do this problem qualify as a "bug" that National Instruments should look into?

The problem of modifying one or both files is that I am working in fairly big projects where multiple developers might be using the same driver(s). Then it can/will be a hassle to make sure everyone is using the 'edited' version of a NI driver and not using it directly as downloaded. Furthermore the problem may suddenly reappear and cause headache for developers in the future if someone decides to go with a newer revision of the driver thus replaces the edited one. 

Regards

Ole André

[z_haider]

Ole,

The enum is NOT part of the public interface of the driver. It is part of the implementation and there is no requirement that identifier names be unique in the implementation across drivers. You are running into this problem because you are statically compiling the driver source from multiple drivers into your application which is not the correct thing to do.

You should link to the driver using its import library (.lib) or function panel (.fp) file. This way your application will load and execute the driver's DLL at runtime. Any updates/fixes to the driver will not require a recompile of your application, only an upgrade of the driver.

An IVI driver is meant to be compiled as a standalone DLL. If you want to statically compile multiple IVI drivers into your application, then you are responsible for making any modifications to your source code to make it work. This use case is not supported.

The attached project demonstrates that you can successfully build a project that uses both drivers by dynamically linking.

z_haider

[z_haider]

Addendum: To build the project I posted earlier, you need to load both instrument drivers using the "Instrument >> Load" menu option.

z_haider

[OleAndre]

Hi, z_haider.

Thank you for your clarification. Your points really makes sense. I was not really aware of how the compiler differ in behaviour wether the source is statically included in the project or not.

However, at this point I am not sure what I am doing wrong because what you describe is exactly how I have implemented the drivers already. That is; Loaded the instruments from .fp files. Not included any driver .c files in the project.

I don't know why the compiler still references the driver .c file.

[OleAndre]

Update: I got it to work now. It appears that load and including the .fp to the project alone is not enough because the function panel (by default?) references  the .c file. But if I include the .lib as a part of the project a message popup appeared asking if I wanted to replace the .c file with the .lib as source for the .fp. This solved the problem. Please note the the .c file was NOT explicitly included in the project.

Thank you for your effort.

Message Edited by OleAndre on 10-26-2007 04:43 AM

[LuisG]

Hello Ole,

It's very odd that the .fp files were referencing the source. They should be referencing the .lib files without it being necessary for you to add the .lib files to the project.

If you start out with a new project, and you add the two .fp files to this project, do they also use the source?

I just did that experiment in CVI 7.1, and the drivers were attached to the .lib files, as expected (see attachments). Normally, an IVI driver would only use the .c file if it can't find the .lib file in the expected location. Of course, this is somewhat moot, since this is now working for you, but could you just confirm that this is where you have them?

    C:\Program Files\IVI\Drivers\ag5313xa\ag5313xa.fp
    C:\Program Files\IVI\Lib\msc\ag5313xa.lib

and

    C:\Program Files\IVI\Drivers\agn6700\agn6700.fp
    C:\Program Files\IVI\Lib\msc\agn6700.lib

Thanks,
Luis

[OleAndre]

Hi.

I can confirm that my drivers are NOT in the default installation directories as all drivers are placed in a common project directory.

What you are saying, that function panels will attach to the c-file IF the lib-file is not found is probably what happened in my case. As when I started working on the project (which was already started by someone else) the lib-file was not included in the project directory and naturally the function panel could not find it thus attaching to the c-file instead (without any notice).

When I added the lib-file to the project a popup appeared asking if I wanted to attach that file to the function panel instead of the c-file. I then assumed that the lib-file had to be included. However I tried now to remove the lib-file from the project, unload the instrument and then load it again and it attaches to the lib-file.

[LuisG]

Okay, that makes sense.

If an instrument driver is flagged as an IVI-compliant driver (which these two are) then CVI expects to find the .lib in the default location. If it doesn't, then it reverts to its fall-back, non-IVI behavior, which is to look for the program file in the same directory as the .fp. Also, when CVI is looking for a program file, it uses the following preference order: .lib, .obj, .c (although it gets a bit more complicated when some of these files are in the project)

The installers for those drivers should have placed the files in the default, IVI-specified locations. So, what must have happened was that they were either they moved post-installation, or they were copied from one machine to another without being installed.

Thanks for the clarification!

Luis