Multiple instrument measurement recommendations

[ngay528]

Was going to see if some people had some recommendations or insight on gathering measurements (requests via GPIB/USB, etc) most efficiently from multiple devices.

Say I have a Power Supply, Load, and Scope all connected with a test sequence running.  I would want to log Voltage/Current from supply, voltage/current from load, and ripple/noise from scope.

So at every setting, i could manually go through each instrument one by one, log and then proceed.  But is there a more efficient way for example asynchronously or through multi-threading to query an instrument and either set a variable, or call a success function?  This is usually done electronically via a trigger source, but cannot do that here.

I could see this becoming handy if for instance someone would want a scope waveform capture over a 5 second period.

FYI, I am familiar with asynchronous timers and some of the multi-threading capabilities.

Thanks

[Dustin_D]

Hi ngay528,

The real question you would want to ask yourself is how fast does this need to happen?  Polling sequentially its probably sufficient as long as you can log the required data fast enough.  You would want to consider multithreading your application if it seems that you have troubles logging the incoming data at a sufficient speed.  Other than that its mainly a matter of personal preference.  Post back if you would like to discuss!

Regards,

[ngay528]

Pulling data could become an issue.  And some instruments may take awhile to query.  As mentioned, if I asked for a 5 second sample from a scope, I could not have my program lag since I would be possibly logging other things every second.

By the way, 1 second is my main async timer logger.

Just setting up multiple threads although isn't hard, it may be very difficult to manage, especially the incoming and outgoing data, so was interested in finding a good system someone may have tried before.

[menchar]

You can get most GPIB measurement devices to generate a service request (SRQ) when they have data.  An SRQ is an asynchronous interrupt that CVI can use to read the instrument when new data is ready, and you could have the CVI callback read the instrument and post the measurement results in a common area that your main logic can read.  This way, the reading of the instruments is asynchronous to what you're doing with your GUI.

This is something of a classic design pattern for GUI based test SW, the main idea being that the task of reading and formatting measurement data from an instrument or set of instruments is not tightly coupled to the logic you're using to run the GUI or whatever else you might be doing with your main thread.

Instead of SRQ's, or if you have non-GPIB devices, you can use an async timer to periodically fire and have the callback poll the instruments or trigger the measurement cycles, reading and formatting the data and posting it in a common location.  The main thread can then access the latest measured values, as needed, and per its own timing and logic.  Async timers run on their own thread, though it's problematic how to set the priority of the async timer thread - I'm not sure you can very easily.

You could use multithreading, the GPIB library (and all CVI libraries) are thread safe.  But, GPIB is a parallel bus, pretty much only one thing is happening on it at any one time, there's no compelling efficiency advantage or design advantage that I can see, unless perhaps you have a high priority measurement that you want to ensure gets taken before others and you establish this with thread priority.  Plus, when you multithread, your threads compete against all other threads in the system for execution time, not just the threads in your process.  It can be harder than you might think to get the threads to behave exactly as you like.

You still have to coordinate setting up the instrument - the polling idea works best when you have a set of devices doing the same measurement in a loop, which most instruments do by nature.  The logic is a bit mnessier if you want to explicitly trigger each measurement cycle for a given device - then you've got to coordinate a set of commands to / from the device in order to make a measurement.  And you always are responsible for coordinating this - the thread-safe GPIB library only ensures that a given GPIB transaction isn't garbeld on a byte-basis - i.e. any one GPIB transaction will succeed, but if you have multiple threads trying to do multi-step transactions with the same device, you have to coordinate these by design for yourself.

Menchar

[Dustin_D]

Hi ngay528,

Another architechture that could work well for you would be a state machine with the ability to spawn threads for actions that could take a large amount of time based possibly on SRQs.  This way your program won't stall waiting for operations to complete and you would have a minimal amount of code running in seperate threads and that code would be more time hungry than resource hungry to avoid competing threads.

Regards,

[ngay528]

thanks for all the info.  I will most likely have some instruments on GPIB and others not.  but i will first start with GPIB instruments and look into SRQ's.

I'm currently looking into WaitSRQ and FindRQS.  If I have for example three GPIB instruments, how do I know which one has data for me to get?

And would it be better to Schedule a thread Pool function for WaitSRQ for each instrument or to just continually call FindSRQ over and over and handle incoming data that way?

Thanks

***

I ask because I could not find examples within CVI Environment.  To add to the questions above, it semes ibnotify would work as well, just need to figure out which device has data for me.

[menchar]

The main idea is that the SRQ is an asynchronous interrupt - your code doesn't "know" when it's going to happen.

The GPIB identifies the interrupting device by doing a "serial poll", then in CVI you get a callback parameterized to tell you which device is requesting service.  You don't have to do this for yourself, the NI GPIB driver conducts the serial poll whenever it sees the SRQ line asserted true (if you configure it to act this way).  You can use SRQ's without automatic serial poll, by polling yourself from higher level logic, but it's cleaner to have the driver do it I think.

But then are you using an NI GPIB controller?  Any GPIB controller can be set up to do a serial poll, but the specifics are in the driver, and if it's not an NI GPIB cntroller it's going to be different at the driver interface most likely, though the serial poll at the bus level is only done one way, as defined by the 488.1 spec.

I have an example of SRQ callback use in CVI if I can find it, but I'm sure there's also an example somewhere in the CVI docs, it's a fundamental capability of GPIB/CVI 488 library.

The SRQ mechanism mainly gives you a quick and efficient way to get an instrument reading as soon as it's ready, and without tangling up your main code with the details of reading the data and formatting it - the SRQ callback can do this for you. 

But, you'll still have to coordinate the main thread's use of the measured data (for comparison, plotting, etc.) with the availability of the measured data after the SRQ callback's read it.  I'd think this would be an easier problem to solve than tangling your main code up with the details of polling, reading, formatting, etc.

Menchar

[menchar]

Here's an edited response:

The main idea is that the SRQ is an asynchronous interrupt - your code doesn't "know" exactly when it's going to happen, and it can be off doing other sensible things until it does happen.

The GPIB identifies the interrupting device by doing a "serial poll", then in CVI you get a callback parameterized to tell you which device is requesting service.  You don't have to do this for yourself, the NI GPIB driver conducts the serial poll whenever it sees the SRQ line asserted true (if you configure it to act this way).  You can use SRQ's without automatic serial poll, by polling yourself from higher level logic, but it's cleaner to have the driver do it I think.  Conceivably you could also not "poll" at all, if you're setting up and reading one instrument at a time, then you're only concerned with when the instrument has data ready, and you can loop on its status to know when data is ready.   You can also use the automatic serial poll and callback scheme even if there's only one instrument in play - polling only the one instrument.

The original idea of SRQ was that on a parallel bus with lots of devices, you are able to have any one of them asynchronously request service, for any reason designed into the instrument (typically for data ready), and the controller would identify the requesting device and you can then do a programmatic response to the device's async interrupt.

But then are you using an NI GPIB controller?  Any GPIB controller can be set up to do a serial poll, but the specifics are in the driver, and if it's not an NI GPIB cntroller it's going to be different at the driver interface most likely, though the serial poll at the bus level is only done one way, as defined by the 488.1 spec.

I have an example of SRQ callback use in CVI if I can find it, but I'm sure there's also an example somewhere in the CVI docs, it's a fundamental capability of GPIB/CVI 488 library.

The SRQ mechanism mainly gives you a quick and efficient way to get an instrument reading as soon as it's ready, and without tangling up your main code with the details of reading the data and formatting it - the SRQ callback can do this for you. 

But, you'll still have to coordinate the main thread's use of the measured data (for comparison, plotting, etc.) with the availability of the measured data after the SRQ callback's read it.  I'd think this would be an easier problem to solve than tangling your main code up with the details of polling, reading, formatting, etc.  There are many ways to skin a cat.

Menchar

[ngay528]

Thanks for the input.  I'll look up some examples.  I may just need to try out a couple ways and see how long before i hit a road block 🙂

By the way, I have the NI 488.2 GPIB to USB cable.

[menchar]

You use the function ibconfig to enable autopolling on an NI controller GPIB0:

iStatus = ibconfig (GPIB0, IbcAUTOPOLL, ENABLE);

and ibnotify to register a callback for a particular device, repeat this for as many devices as you want to be auto polled each time an SRQ is raised (get device descriptors for each device first):

iStatus = ibnotify (iDeviceDescriptor, RQS, CallbackFunction, NULL);

Each callback function has this prototype:

int __stdcall CallbackFunction (int Device, int sta, int err, long cntl, void* callbackData);

You can route all instruments to a single callback, or separate callbacks.  You can have the callback be for the controller board, but then you have to poll the bus for yourself to clear the SRQ.

The async SRQ callback runs on a separate thread, so you have to protect access to any shared data that the main thread will also access.

This is all described in the CVI help for 488.2 library.  Some of this stuff is a bit funky since the NI 488.1 and 488.2 libraries date back 30 years or so.  But it's also tried and true, old hat stuff.  GPIB has prevailed for 35 years+ because it was (and still is) a pretty sensible way to hook up programmable instruments.  There's a GPIB primer on this site somewhere.

You're using a GPIB-USB dongle which is parallel to serial conversion, so at the physical level it's not truly working like traditional 488.  But conceptually, you should be able to code as if  you have a true parallel interface to the 488 bus, NI has the dongle model the original 488 parallel port behavior.

Good luck.

Menchar