Implementing a GPIB controlled oscilloscope

[The True Q]

Hello,

First, I am fairly new to LabVIEW and am using 7.0.

I am implementing an oscillscope which will be controlled via GPIB; measurements will be performed with a PXI DAQ (most likely PXI-6115). This scope is meant to replace an existing scope so it must respond to the command set (actually a subset) of that scope.

The basic premise is that it will sit there waiting for a GPIB message. When it recieves a message, it will split it into individual commands (if there is more than one command in that message) and then parse the command, execute the actions appropriate for that command, then wait for anther message (or parse & process any remaining commands from message). Commands can be grouped into three types: acquisition setup, acquisition execution, and data analysis. The acquisition setup commands set parameters such as vertical range/scale, number of points to acquire, timebase, etc, but the actual acquisition is initiated by a separate command; analysis commands perform analysis on data that has been acquired.

My main question is what is the best method to pass these parameters from the command system to the acquisition system, initiate the acquisition when the appropriate command arrives, then perform analysis on the acquired data given a specific command. My current plan uses a large nested case statement to parse each command argument by argument down to the actual value that needs to be set, but how do I get these values to the appropriate DAQmx VIs (and where should the DAQmx VIs be located - doesn't seem logical to place them in the case statements)? I am considering a VI that basically has all of the parameters that need to be set on the front panel and this VI could essentially be run stand-alone as an oscilloscope (it would also have a button to start the acquisition), but how would I set each paramter from outside the VI (and be able to set different parameters from different cases) - is this an appropriate use for globals? I would also need to be able to extract the acquired data and "pass" it to other VIs (located in individual case statements) to perform analysis.

Also for reference, there are approximately 20 parameters/commands that need to be handled to setup the acquisition.

I'd appreciate any advice on the best way to accomplish this.

- Jason

[Dennis_Knutson]

First of all, you cannot control a 6115 via GPIB. GPIB instruments are external to a pc or PXI chassis and use a completely different bus. Why do you have to emulate the command set of the old instrument? Are the users expected to enter these commands? Your idea of a VI with all parameters on the front panel is a good one but the parameters in something like this is a numeric control for time base, booleans for ch1, ch2, on/off, etc. This should be similar to the drivers for a gpib scope. Look at the shipping example called 2 Channel Oscilliscope and compare it to the NI Scope driver (for internal scope card) and any of the GPIB scope drivers that you can download from the Instrument Driver Network. The whole idea of instrument drivers (GPIB, PXI, DAQ, whatever), is to isolate end users from the complex commands needed to talk to an instrument so if the original application is based on this, maybe you can provide more details on it and you can get some idesas on how to simplify things.

[The True Q]

A little more background:

The goal of this project is to develope a replacement for an obsolete oscilloscope in an automated test set, hence the reason for emulating the command set - changing the test set program is not an option. So, what I am planning is to place an embedded controller (PXI-8184), a DAQ (PXI-6115), and GPIB card (PXI-GPIB) in a PXI chassis - this system as a whole will be a drop in replacement for the obsolete oscilloscope. The embedded controller (with Windows, not Real-Time LabVIEW) will run a VI (the meat of this project) which will monitor the GPIB for commands intended for the replaced oscilloscope and when it receives a command, parse the command and perform the appropriate actions such as setting up the 6115 for acquisition, starting acquisition on the 6115, or performing analysis on data acquired by the 6115.

I've looked at some of the GPIB scope drivers, but they are focused on sending the proper commands from LabVIEW via GPIB to a stand-alone instrument. My problem is once I've received a command and parsed it (in LabVIEW), what is the best way to "set" the appropriate parameter on the 6115. I need to be able to receive a command that sets the range, then one that sets the sample rate, then another one that sets the number of points to acquire, then one that tells the 6115 to acquire a waveform according to the parameters set by the previous commands (and using defaults for any parameters not explicitly set).

An example command (NOTE: this is a slightly modified command): "RANGE CHANNEL1 10V" - When this message is received, it would be parsed with several nested case statements (2 in this case). The first argument, "RANGE", would select the "RANGE" case of a case structure. The second argument, "CHANNEL1", would be passed inside the case structure and would select then "CHANNEL1" case of a case structure nested inside the "RANGE" case of the first case structure. Inside this second case structure, I need to the set the Vertical Range of Channel 1 of the DAQ to 10 Volts. What is the best way to do this? Would DAQmx property nodes be appropriate? Are there better ways to parse the commands and select the appropriate action?

Thanks for any more assistance,
- Jason

[Odd_Modem]

I would investigate queues.

You might have one queue that serializes the GPIB data as it comes in, I guess based on EOM assertion. There would be a vi that parses this message info (possibly SCPI) into more atomic units.

My preference from there would be to expand any kind of abbreviation, be it shortened nouns or tree-based parent-children operations, into complete, unit commands; then put these onto another queue that is drained by your DAQ card handler.

[Dennis_Knutson]

Now I understand. Thanks. I think I would go with a state machine architecture. I'm not a big fan of deeply nested case statements. They're hard to debug and to maintain. There are a couple of shipping examples and some more on NI's Developer Zone. One approach would be to accumulate all of the setup information in a cluster maintained by a shift register. Then, when you detect a command to retrieve a waveform or measurment, send the setup information to the appropriate DAQmx function and then start the DAQmx acquisition task. I would try to avoid sending individual setups to the DAQ board as they arrive. Most, if not all, of the parameters are required inputs for a single DAQmx function anyway. If you need to display data continuously, then a separate while loop running the task would work. You could pass data between the parsing loop and the acquisition loop via a queue. In order to change parameters, you will have to stop and then restart the task which is why I would avoid sending any DAQ commands until the very end.

[The True Q]

Thanks for the suggestions - I'm looking into the state machine and I'll let you know if I have any more questions.

Odd_Modem - I'm not sure if I can effectively use queues in the manner you suggest (although one may be good for stacking the messages as they come in to make sure I don't miss any while the VI is off doing something else), but thanks for the suggestion.

- Jason