LV ATE on GPIB with true P&P strategy, how?

[lab-lurker]

Hi all.

I'm looking with interest at LabView as a serious programming tool to re-design

existing ATE product test applications.

My test desks consist of PC + RF testing equipment controlled via GPIB.

Current applications use SCPI commands via GPIB with a rather smart

"Plug & Play" strategy.

I explain: if an instrument is replaced with an equivalent one (in general

different model and/or brand) the testing application will work without having

to be changed or adapted.

This is achieved as follows: 

when the application starts, an "*IDN?" command is sent to identify the instrument then, 

depending on the answer, instrument basic common actions are implemented by sending proper 

SCPI instruction sequences with a file\path encoded classification.

Example:

a "set_frequency" basic command is sent to an instrument identified as GENERATOR_X

by sending the SCPI line(s) contained into a proper file:

..\GENERATOR_X\set_frequency.txt

If this generator is replaced, the new one will be recognized, say, as GENERATOR_Y

and the same command will be implemented by using a similar file:

..\GENERATOR_Y\set_frequency.txt

Note that, in general, the two set_frequency.txt files above have the same name but

differ in path and may change in content.

Of course, this requires that all needed basic instrument actions are first implemented for

all the instrument models/brands that may be used, with their specific SCPI code and

saved to different paths... quite an heavy work... someway already done.

Now I wonder if an equivalent strategy can be implemented with LabView and how difficult

or easier this could turn to be.

I know about P&P and IVI instrument drivers, but unluckily the instruments we use are not

all covered by drivers and this would bring me to entirely or partially discard the driver based solution, even if very attractive for potential time saving.

In a few words, if LV had no better general purpose options, I would like to keep the existing *IDN? based strategy with LV as well, in a way that if a new instrument is added to the existing

collection, I would just have to create a new path containing proper SCPI files

without having to change anything in the application, which would load the required 

SCPI action files from the new, dinamically computed, string path.

Being at the moment a total newbie about LV,

I would appreciate any suggestion by skilled programmers, pointing me to the right

programming LV techniques and tools to achieve a goal like the one I described:

howto send GPIB commands (using VISA) contained into files with dynamically changing path,

depending on detected instrument IDs.

In addition, any book, tutorial and/or project samples specific to this kind of applications is welcome.

Sorry for having been a bit long.

Thanks in advance for any help.

BR

Lab-Lurker

[Albert.Geven]

It seems that you have a nice way of generating commands for instruments.

In principle you can do the same in LabVIEW.

For your fileformat you need to write a loader that loads all commands into memory and for each command per instrument can spit out the correct visa string. Exactly the same as you do now.

Your only problem is that you are new to LabVIEW so let somebody help you.

One of the nice things in this forum is that all (most anyway) of us are independent from NI and "work" or "play" for free.

You can learn about action engines from Ben (search the forum) and see that such an approach is good for your question.

Or somewhat later you could even opt for an object oriented approach.

But also build for the future: GPIB is going to disappear because of too thick and too short cabling and especially pricing.

USB and ethernet will take over so make sure that both busses (via visa) are also included in your approach and too make live even better.

There are already a lot of nstrumentdrivers available on the network and they only need a unifying layer that can "easily" be done with objects in LabVIEW.

So start using to get used to LabVIEW and ask specfic problems when they arise or when you have read about action engines.

[sabrynico]

Hello,

 I am sending you a tutorial that might give you basic informations about NI-VISA

http://zone.ni.com/devzone/cda/tut/p/id/3702

I hope it will be useful for you

Sabrina

[lab-lurker]

Thanks Albert and Sabrina for your replies.

Albert:

I googled and found Ben's nugget.

Will have to get deeper into it and into LVOOP techniques; my LV skill doesn't allow me yet.

About GPIB, I currently use VISA in my existing applications, so I plan to stay with it

which will allow me to use any kind of interface, besides the vintage GPIB.

About VISA: thanks Sabrina for the tutorial, where I noticed a feedback comment by Albert as well, hehehe.

So, to summarize, I think I'll be using VISA read and write operations;

maybe hard but solid and tracked solution for my case.

I saw some VIs examples where VISA sessions have reads and writes directly wired 

to input strings and output displays, respectively.

In my more complex case I'll have to create something that, depending on the model of detected

instrument, will select "the one" of many sets of SCPI files containing the lines of text 

to be dynamically wired to VISA write actions, lines that often will need to be combined to fixed values or runtime parameters.

On the other side, VISA readings will have to store their results into variables to be used

for further measure computations and/or result storage in a CSV or txt files.

If LV and instruments were human, I would code my problem as follows:

if the generator at GPIB0::5:INSTR is named "Frank" then find Frank's basic actions at:

..\actions\Frank\*.txt

To tell Frank to "eat", you have to execute this file:

\actions\Frank\eat.txt

which will start with the following line:

take the fork...

...

If the detected generator is "Chen" then tell him to eat at

..\actions\Chen\eat.txt

which will start with the following line:

cross your chopsticks...

...

Then I'll cross my fingers

Note that if the action path is created with the rule:

..\actions\<Instrument_Name>\<action>.txt

No application code change is required when changing the instrument, moreover you don't need to have any select case module where to code all the possible cases: each case is implicitly defined!

If someone has any additional specific tutorial or VI code helping with similar scenarios implementation,

any help is welcome, of course.

Finally, I wonder if LabView itself has some aids for interactive (not fully automatic) operations.

Example: display an input box where to type a serial number or displaying a calibration connection animated gif, 

play warning sounds, prompt for multiple keystroke options (Ctrl to repeat, Cancel to stop measurement and so on) or if such tasks are better accomplished with an extra testing management tool, such as Teststand.

Bye for now and regards.

Lab-Lurker

[Albert.Geven]

Hi lablurker

Good work in reading so much. I know there is a lot to learn when switching languages, especcially when the basic princile behind is not the same. In this case LabVIEW as a dataflow language took me more that half a year to get used and that was in the first LabVIEW version on pc, already 17 years ago and LaVIEW hasn een extended a lot since then.

In esence your problem was already solved when you wrote the previous language interpretation.

You need a relative simple visa vi that performs a query. Meaning sending a command and reading back an expected answer.

Around this you need to have for each datatype a function that "knows" the command to send and "interprete" the returned data.

Above this you need to ave a way from your instrument description file which vi to call for which command.

e.g. for the serial number you probably have to send *IDN? followed by reading a string of probably max 256 characters, but for some instruments you only need IDN? and others IDN each followed by a terminal character like CR and or LF.

In LAbVIEW instrumentdrivers do exist that solve most of the work only these instrumentdrivers are not standardized in functions. So as an example the Source Measurement Units from Keithley are not equal in interface to those from Agilent or NI. Even worse the 2400 series from Keithley are quite different from the 2600 series. (as seen in the forum and known by experience)

So succes with the implemtation and in two months I'll be ready with a paper on Source Measurement Units.