Interface unit descriptor vs. device unit descriptor

[ndiamond]

In NI-488.2 Function Reference Manual for Windows (321038g) the description of ibfind() says in its last Note that ibfind() is deprecated for use in finding device descriptors. It doesn't say if ibfind() should still be used in new applications to find interface descriptors but I think it seems to be necessary. The description of ibdev() says that ibdev() only opens device descriptors so it seems to be useless for part of my needs.

However, ibfind() is still capable of finding device descriptors despite being deprecated for that purpose. I downloaded the example of two computers from ftp://ftp.ni.com/contrib/epd/B45EACE3DD1C56A4E034080020E74861/two_computers.zip

In the example, both the controller and the non-controller call ilfind() which calls ibfind(). The controller calls ibfind("GPIB0") and I think it gets an interface unit descriptor. The controller calls ibfind("DEV1") and I think it gets a device unit descriptor with a connection to the non-controller. But the non-controller calls the same ibfind("GPIB0") and it gets a device descriptor with a connection to the controller!

How does ibfind() know whether the caller wants an interface unit descriptor or a device unit descriptor? As far as I can tell, ibfind() seems to be reading the programmer's mind. How can I be sure it will read my mind correctly?

Also, what happens if there are three computers? When the controller calls ibfind() three times, ibfind() might magically figure out which call to return an interface unit descriptor and which two calls to return device unit descriptors. But how will the "DEV1" and "DEV2" calls be matched up against the correct non-controllers? The controller needs some way to know which device is which.

I see how to set a primary address on a unit descriptor, but this doesn't solve anything. If the unit descriptor has magically been opened as an interface unit descriptor then great, I can set my own board's address. If the unit descriptor has magically been opened to a device unit descriptor connected to a random choice of non-controller device, then I can set the unknown device's address, but I still don't know which device it is.

I think I need to make each computer open its own interface and set the primary address of its own interface, and next I need to make the controller open each device at a known address for each device, but I can't find any way to achieve the necessary detail of control for any part of this.

[DiegoF]

Hi,

The use of ibfind to open device unit descriptor is discourage (deprecated), but it is maintained to support older applications that rely on that functionality.

ibfind will open a interface unit descriptor if the name used is GPIB where id is the interface number (GPIB0, GPIB1, ...).

There is nothing magical about the DEV names. This are what is called device templates. In previous version of the driver, the template configuration was avaiable from MAX. In the newer version of the driver there is an utility called GpibConf.exe.

The utility allows you to assign particular name (doesn't even have to be DEV) to a set of device configuration parameters, which include the interface ID, the address of the device you want to talk to, among ot
her things.

We recommend using ibdev instead to open a session to a instrument (from the controller).

Using your example. Assume you have 3 PCs, one controller (address 2) and two non-controller (address 5 and 8). On the non controllers you would call ibfind GPIBx to open a descriptor to the board. The x is whatever number you configured on each non-controller PC. The controller wants to communicate with the non-controller devices so you would use ibdev two times with addresses 5 and 8, to open a session to each device.

Hope this clears things out.

DiegoF
National Instruments.

[ndiamond]

I think this part of your answer really answers my first question:

> ibfind will open a interface unit descriptor if the
> name used is GPIB where id is the interface
> number (GPIB0, GPIB1, ...).

May I suggest that the description of ibfind() in the NI-488.2 Function Reference Manual for Windows (321038g) would really benefit from the addition of this information.

It also still seems that ibfind() is not deprecated for this purpose because ibdev() cannot open an interface. ibfind() is deprecated in the case of opening a device only, because ibdev() is more flexible for devices, but this has no bearing on the necessity of ibfind() for interfaces.

By the way, if suggestions are permitted: If there were an ibint() function then ibfind() c
ould be deprecated completely. Programmers could see immediately if a call was opening an interface through ibint() vs. a device through ibdev().

Regarding the two computers example, the comment in the non-controller code really confused me. The comment implies that ibfind() is opening a device descriptor there. Now I understand that the non-controller isn't directly opening a device connection to the controller, the non-controller is only opening its own interface because ibfind() gives special treatment to strings of the form "GPIB". (Of course the designer knows that this device will be the target of the controller, but that's not under the control of the non-controller's call to ibfind().)

Now I'm off to search for GpibConf.exe. I guess this utility is newer than the September 2000 driver disk.

(I remember once upon a time when devices weren't powerful enough to run a program like GpibConf.exe, but in my current application the target devices are running Windows 2
000. Maybe the next generation of voltmeters will crash frequently 🙂 Does LabView accurately display the instruments' Blue Screens of Death :-?)

[DiegoF]

Hi,

ibfind is still the only way to open a interface unit descriptor. It is not deprecated if used for that purpose. Actually, is not the ibfond call itself, it is the use of device templates that is discourage. The device templates is what you use to open a device descriptor using ibfind.

DiegoF
National Instruments.

[ndiamond]

Thank you. I sincerely believe that the manuals and example would benefit from having your answers added, as mentioned before. Meanwhile, thank you for clarifying everything.