NI Switch & DMM handshaking optimization

[proland1121]

Hello, I implementing a scan and measure routine based on the shipped example for NI-switch NI-DMM handshaking  (pxi-2536 and pxi4065).  I am conducting a 4-wire resistance measurement (5.5 digits of resolution) over a scan list of 22 switch configurations (this may be extended later).  Evaluating with 11 configurations scan and measure takes roughly 2.5 seconds.  (they're all the same in the attached vi for simplicity)

My question here is rather open; Is there any advice for reducing the cycle time of this operation? Or is this the limit for my configuration?

I'm expecting to execute this sequence tens of thousands of times per day (hopefully as fast as possible), so reducing the cycle time by even a few hundred milliseconds would be extremely beneficial to throughput.

[RavensFan]

How fast do you need it to be?  11 configurations x 2.5 seconds is still less than 30 seconds.  You could do this 1000 times in less than 8 hours.

Looking at your code, I don't see how you are executing multiple configurations.  It is not a subVI as there aren't any terminals connected on the connector panel.  And there isn't any loop to cycle through different configurations.

If there was a loop, then I would suggest any operations you do like initializing the resources, or closing them you make sure you do outside of the loop.

[proland1121]

I guess I didn't explain very well, let me try to add some context.

"Looking at your code, I don't see how you are executing multiple configurations". 

This aspect is a LabVIEW shipped exampled (Switch - Scanning with a DMM - Handshaking).  PXI module hardware timed.. not software loop triggered.  The methodology is to define a scan list (semicolon delimited) and have the two PXI devices trigger each other at each step.  As mentioned in my original post, I simply repeated the same configuration multiple times for testing; end application, each switch configuration in the scan list will correlate to the physical wiring of the test system.

"11 configurations x 2.5 seconds " 

no, sorry... 2.5 seconds total for the sequence of 11 switch/measure steps. I need to minimize this time to maximize throughput of the end application (wafer prober testing of very small die).  shaving this down to 2 seconds versus 2.5 (for example) increases throughput and more product gets through the manufacturing line.  If possible, I'd like to hit 50,000 per day (or more).

The switch matrix I'm using is FET based with nominal switching time of about 20-30 microseconds (spec'd maximum is 16 ms).  Based on the specs of the two devices, this process should be happening much faster than I am currently achieving.  Changing DMM resolution barely has any impact on acquisition time so, at this point, I can only assume there is some overhead slowing the process.  Mainly, I'm wondering why/how it's running as slowly as it is, or if there is a property node/subvi setting I'm missing.

[RavensFan · Accepted solution]

As I said, the opening, initialization, and closing of resources tend to be the bigger timer hogs.  You need to modify your test code to get the DMM Close and NI Switch close out of the timed section.

Get the stuff you need to do repeatedly in a loop and run it hundreds and thousands of times looking at the total loop time and dividing by 100 or 1000, or whatever to get a truer measurement of how long it takes.

If you are looking for 50,000 day, you are getting down to about 1/2 second cycle times.  So anything that takes 10's to 100 msec or so becomes significant.  You will need to do some careful bench-marking to figure out which parts of your code take a long time. 

[proland1121]

RavensFan,  thanks for the reply.

I've placed the core segment (initiate scan and fetch data) in a for loop and saw no significant change in the run-time of the individual loops (+/- a few milliseconds); so I started digging deeper into the various property nodes for the NI-Switch and NI-DMM.

For the NI-DMM, I found the "settle time" property to drastically affect the measurement cycle time when changed from the default -1 (auto).  Combining this with the "number of averages" property, I'm getting a scan time under 600 ms with signal-to-noise ratio over 5000.  WOOHOO.