LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

VI to interchange GPIB Commands (Ideas needed)

Hello,

I am looking for some ideas on how to set-up my test to use different equipment. Basically the test I have written uses OLD HP (now Agilent) equipment:

-8756A Scalar Analyzer
-438A Power Meter
-8350B Sweep Generator.

The 8756 and 8350 are set-up where the 8756 is the controller to the 8350. GPIB goes to the 438A and 8756A.

Now I have a newer bench that consists of:
-8757D
-83640B
-E4419B

I have the 83640 in the HP compatible mode and it is connected that same as the older system above. I had the E4419B in compatible mode, but changed the commands an made it a specific program to use SCPI commands (more flexible).

Soon we will have a new ESG series Generator, now it too will work in HP compatible mode for the older commands but again, limited functions.

Now what I am looking for is ideas on how to set-up a look up table in Excel or notepad which when I initially run the test it will know what equipment is connected. The stumbling blocks I have right now are that the older equipment does not have any type of IDN command. Also the computers and Test rack are mobile, so I will not always have the same computer and test rack.

I think one way to handle it would be if the IDN command is not recognized on a specific address it could default to the older equipment commands, then the newer stuff would be able to respond.

Like I said any ideas to help me get started would be excellent.

As for the OS and such:
LabVIEW 6.0.2 is used, I cannot use VISA drivers as I am utilizing I/O Tech GPIB cards and they only support 488.2.
Machine OS.. Win XP (my DEV machine) Win98SE and WIN2K for Test.


Jeff
Jeff D.

Certified Architect LabVIEW Champion DQMH Framework

0 Kudos
Message 1 of 13
(4,677 Views)
you could use the "*idn?" query within labview to get a response from everything attached to the gpib chain. you could have a conditional sub-vi within a case that communicates with the device that is currently attached. If you don't want to query the devices every time, you could have a separate config vi that would write files (or a global etc) based on the query. Your actual run program would read those files and adjust accordingly based on what is hanging off your gpib chain.

FYI: *idn? is a GPIB query that should be recognized by all GPIB devices and they should respond with a unique identifier string that you could parse.


Actually this has me thinking that I could make my acquisition programs less brittle using this method as well. I always try to write device driver high level vi's that fail gracefully if the instrument isn't on the bus or is turned off, but this concept would be even more robust and elegant to query the device to see if it's even worth trying to talk to.


Sheldon
Technical geek, engineer, research scientist, biodegradable...
0 Kudos
Message 2 of 13
(4,661 Views)
Apparently I can't read this morning and gave you worthless advise. I was under the impression that all GPIB devices responded to an IDN query.

Sheldon
Technical geek, engineer, research scientist, biodegradable...
0 Kudos
Message 3 of 13
(4,661 Views)
No there is some good advice there..

I did some more research, as it turns out the newer Equipment with respond to *IDN? but the older stuff it Varies..

the 8564E and 8757D use ID?
the 8341,8340, and 8756A use OI (Although I have the 8756A/8757 as the controller for the 8340/41 so that works sometimes)
The 438A is ?ID

the 83640 is in Analyzer compatibility mode so it is also OI.

Now I could write a VI that loops through each command at the beginning of the test and if there is an Error it goes until there is no error, but then each instrument has the ERR flag of some sort and there are not commands for the older insturments to clear it VIA GPIB.

One thing I could do is wait until the Operator enters in the Test Equipment, which is currently done as a Floppy idsk travels with the equipment and I can just read it from there. I could then set-up a TXT file and have english commands reference the actual commands.

hmmmm..
Jeff D.

Certified Architect LabVIEW Champion DQMH Framework

0 Kudos
Message 4 of 13
(4,654 Views)
You and Sheldon seem to be coming up with some pretty good ideas.

Pretty much what you are going to need to do is use a nested case structure to send out the various queries. In your case since there can be problems with not being able to reset the device if the wrong command is sent then you might want to try using the older query first, then working your way up to the newer queries. Keep in mind that if an error is thrown you might want to reset the device before trying the next command.

Of course if you wanted to have the technician enter some information, then that would reduce the chances of throwing an error. Either solution should give you the results you're looking for.

Overall it sounds like you are on the right track. Great advice Sheldon, and an even better signature.
0 Kudos
Message 5 of 13
(4,626 Views)
Well, here is what I have right now..

Currently the Addressesfor each instrument are hardcoded, I also had a quick make-shift VI that found and changed commands for the Generator since the 8350 has a few different commands from the 83640 when in analyzer mode.

Well I expanded that Vi and basically since all the commands in the program are hardcoded for the older instruments it compares the Old instrument number to the newer one. I have the tech entering the #s (actually on a data disk with the rack) Then when it gets to the commands it runs trhough and changes them before sending them. This way I will get no errors from any equipment.

I will be testing it this week or next to be sure and fix the bugs..

Jeff
Jeff D.

Certified Architect LabVIEW Champion DQMH Framework

0 Kudos
Message 6 of 13
(4,619 Views)
I don't know if this is politically correct these days, but things like GPIB addresses I generally don't hard code. Rather I make a global file that contains the hardware setups. These globals are a step removed from hard coding in that I can go into one location and change hardware setting rather than going on an easter egg hunt through the diagram (or several diagrams) looking for places that need a change.

For example, my Klinger MC/MD4 motor controller VI's have a global that contains the following items:

GPIB address
Each axis present or not
Each axis acceleration
Each axis max velocity
Each axis deceleration
Each axis counts to engineering units
Each axis linear or rotation


My actual driver VI's spit out position in engineering units and unit type for example, and they take in position in engineering units. When the hardware in the lab is changed, we all know to go to a global to put in the new parameters. And none of the underlying code needs to be touched.

The downside of globals is that they are a bit funky when compared to disk files. (I'm a bit fuzzy on this, but here goes:) The data in a global seems to be persistent within a labview session, IE even if all VI's and the global are closed, the data is still retained until the application is closed. When the app is re-run, the default values are read from the global. So when changing the global, I "make current values default" and save it to make sure my settings are persistent. For me, disk files are more easy to get my head around, I know when the data is retained and when it isn't. But the globals are sure easy to use with multiple related VI's.

Comments?

Sheldon
Technical geek, engineer, research scientist, biodegradable...
0 Kudos
Message 7 of 13
(4,617 Views)
I don't like to HardCode the Addresses either.. maybe with what I have (Command Look up table) I can also incorporate the Addresses. The look up table is in Excel and is read in as the program starts. I can add the Addressing there, then for the commands in the code I could use an english type command and then in the Table have it relate to the correct command. I am working on revising this program. When I started it was to be bare bones, but there is always function creep. Since I have a working version in production, I am not under that much pressure for these changes.. Maybe I will go through and add that. This way the English command would never change and never need to change...

Thoughts?
Jeff D.

Certified Architect LabVIEW Champion DQMH Framework

0 Kudos
Message 8 of 13
(4,611 Views)
I have been battling with this issue for a while as well. I use Access databases to store Instrument Alias, Primary Address, Secondary Address, Interface Type, etc. Upon the User interface startup I read this database to an array that is passed to every VI called by the User Interface. Each VI will then search the array for the instrument alias and parse the needed configuration data to communicate to the instrument. I want to really create hardware independent tests but this method requires I have cases in my code for each instrument model supported. I want to be able to create instument classes and dynamically call the correct driver code. I thought IVI drivers were the way to go but the number of classes is limited and who knows if this will become standard anytime soon. My other problem with IVI is if you use the Measurment and Automation Tools utility it assumes that there is one alias for each instrument that has a GPIB address. This is not always the case. Some instruments have plug ins or channels that are logically independent instruments. So you still need a way to manage instrument sessions along with channels (unless they are VXI instruments).
0 Kudos
Message 9 of 13
(4,610 Views)
Okay,

I thought a had something working well, then of course, I now have a new instrument that does not like one of the commands, even though it is in compatibale mode and should allow it.

So I am rethinking my GPIB Strategy. One thing I am changing is I will keep the information in a Tab Delimited Text file. The initial load for the file is much faster the excel, even with putting the file into an array.

So I am thinking I will have an English command listed in the code. this will refer to the actual command set, and then an instrument generic name will be list before the command to be used to find the right instrument along witht he correct address and then append all the correct info to a string for my GPIB read/write VI.
Jeff D.

Certified Architect LabVIEW Champion DQMH Framework

0 Kudos
Message 10 of 13
(4,568 Views)