How to programmatically check if a GPIB instrument is compliant with IEEE 488.2 standard or not?

[Sudharsan62]

I wanted to do it in such a way that if it is a non-compliant instrument, the command/method used doesn't affect the state of the non-compliant instrument.

[RTSLVU]

Well you could see if it responds correctly to a couple 488.2 common commands.

IEEE 488.2 Mandatory Common Commands

 See also : GPIB Hardware and Software Specifications

[Minions]

I believe that those are the SCPI compliant commands.  IEEE-488.2 is more of a hardware abstraction layer.  Many of the older power supplies that are IEEE-488.2 compliant will NOT respond to

*IDN?\n

but will respond to

ID?\n

instead.

[RTSLVU]

---

@Minions wrote:

I believe that those are the SCPI compliant commands.  IEEE-488.2 is more of a hardware abstraction layer.  Many of the older power supplies that are IEEE-488.2 compliant will NOT respond to

*IDN?\n

but will respond to

ID?\n

instead.

---

Then those instruments are probably 488.1 compliant, not 488.2 compliant.

For an instrument to be IEEE 488.2 compliant it MUST respond to the list of 488.2 Common Commands I posted above.

[Sudharsan62]

@RTSLVU wrote:

Well you could see if it responds correctly to a couple 488.2 common commands.

IEEE 488.2 Mandatory Common Commands

 See also : GPIB Hardware and Software Specifications

---

I tried this option. The issue with this is - We are trying to do a silent check regularly if the connected GPIB instruments are IEEE 488.2 compliant or not. There might be other software/tools which are communicating with the GPIB instrument regularly. So if we do a query, it might disturb the query (query with a wait time) sent from the other software/tool. And we do not want to do that.

[Sudharsan62]

---

@Minions wrote:

I believe that those are the SCPI compliant commands.  IEEE-488.2 is more of a hardware abstraction layer.  Many of the older power supplies that are IEEE-488.2 compliant will NOT respond to

*IDN?\n

but will respond to

ID?\n

instead.

---

I intend to do this after I know if it is a IEEE 488.2 instrument or not. But at first, I do not want to do a trial and error. I want to know and understand if there is a clear way to know if the instrument is compliant or not.

[rolfk]

Aside from looking at the label on the instrument and the documentation, there is only trial and error. The IEEE 488.2 is also not exactly a standard put in stone. Many devices in the past did sort of implement IEEE 488.2 on software level but had due to the use of buggy interface controllers not exactly the full IEEE 488.2 hardware compatibility.

And the software level is a chapter of its own. While the above mentioned commands are part of the actual IEEE 488.2 standard, the rest is SCPI based and that is more a recommended way of implementation than a standard.

And even those IEEE 488.2 commands are not always fully implemented but should not cause errors when being issued.

But to find out if a device is IEEE 488.2 compliant (it may still not be fully compatible) you have to talk to it and doing that while someone else is talking to it will surely cause trouble.

VXI Plug and Play defines actual device classes that specify in more detail what SCPI commands such a device should support and the actual SCPI command syntax to follow, but that is an even more voluminous standard filling a book shelf of its own. And it's still more of a recommendation than a full standard, since there are many devices out there that don't exactly fit in a single device class only.

[billko]

I think a paradigm shift is in order here.  Instead of making sure you have compliant hardware by testing for it, control the access to the equipment.  Just as having a dropdown menu to select from a list of acceptable keywords is preferable to having someone type a word in and then check to see if it is a "legal" keyword, you should limit the choice of instruments to a list of acceptable equipment.

[JÞB]

---

@Sudharsan62 wrote:

I wanted to do it in such a way that if it is a non-compliant instrument, the command/method used doesn't affect the state of the non-compliant instrument.

---

Not a chance.

If it is non-compliant then there is no reason to believe it does not do anything with a bad command.  An example:  I had several temperature chambers that claimed to be IEEE 488 compliant.  They quit controlling when an interface clear was issued.  (Wrong action)  *IFC can be optionally implemented or not in 488 and 488.2  however, device state must be maintained with a *IFC per the standard.

488.2 is "SCPI" reserved words with mnemonics and : ; separators to navigate menu trees. The IVI consortium defines specific directories for general classes of instruments instruments that have no specific "IVI Class" inherit the general tree and syntax but may have specific keywords that are not otherwise defined.

In short.  RTFM not the device itself.  Bonus: you don't change device state at all when you RTFM!

[RTSLVU]

Granted I don't know what your application is but what I have done in the past to make a program more "universal" with various pieces of test equipment from the same or different manufacturers, is to put all of the "drivers" necessary for all the possible instruments in the program and use a config file to tell the program what drivers to use.

For instance we have DC sources from Agilent and Sorensen in our test racks, also there are two different series of Sorensen sources that use different LabVIEW drivers (DHP and SGI). 

Here is an example of my configuration file section for the DC Source. 

Notice I also have the VISA resource and the instruments output parameters in the config file.  

This file gets read and values put into a cluster for use in my program.

Here is one of my VI's that sets the DC Source output voltage.

All of the VI's for all three source types are in this VI.The DC Source.Type output of the Instruments cluster sets what VI's are used.