DMM too slow at collecting data

[tadk]

Labview 8.0, DMM4060, PXI-2503 switch in 48ch mux mode. DMM triggers Switch using TTL0 HW trigger.

I am using the example "niSwitch DMM switch synchronous scanning.vi" to measure anywhere from 1 to 10 nodes at a time with a scan list. The entire process can take up to 2seconds which is too slow for some of my tests. I need to capture some voltages within a few ms of a digital edge, so I have played around with the resolution and interval inputs and it does help, but not enough. I have inserted a "wait for falling edge.vi" just before the "niDMM initiate" subvi to essentially remove all the setup and initialization time. If I understand it right, at this point the scan list would already be loaded to the switch, the DMM would be set to the correct range and would even have received the 1st trigger from the switch. The DMM should collect that 1st data point with no delay and signal back to the switch then wait for the next trigger. The switch should be capable of switching in 10ms.

Amazingly, it still takes a few hundred ms to collect even a few data points. There is clearly something wrong here either with the driver or the HW config.
This may be related to the scan list parsing bug - the first scan list entry ends up as the last element in the resulting array, i.e. scan with scan list "ch0->com0; ch5->com0; ch7->com0;", ch0 will be scanned (or maybe just stored) in order 5,7,0.

Ideas?

[Odd_Modem]

Turn off auto-range.

[ian_fung]

Try Properties:

1. Aperture Time

2. Settle Time

as well...

[tadk]

The supplied example sets the range to a fixed number. If this does not disable auto-ranging, I sure don't see anywhere else I could do it.

[tadk]

Likewise for the settle time and aperature time. The docs discuss these but I don't see how I could change them. What vi exposes these?
niDMM configure measurement.vi only has range and resolution as inputs. I did find I could set the interval time to 0 and speed things up, but some interval time is probably necessary for the switch, and anyway the initial setup delay is still present. I can even hear it: "ka-chink ...wait... dit,dit,dit,dit".

[ian_fung]

1. Goto Instrument I/O > Instrument Drivers > NI-DMM > niDMM Property Node

2. Place the niDMM Property Node in your diagram

3. Right-click the property node, goto Properties > Configuration > Advanced > Aperture Time/ Settle Time etc

Regards,

ian

[tadk]

Thanks. I see that gives me access to aperature time. Settle time is visible but supposedly not configurable with the DMM4060. I'll give it a try when I get back to the HW.
Aperature time is also limited to a minimum of 1 power cycle (~16ms) which is probably added to the minimum switch interval time of 10ms. So it looks like 26ms ch-to-ch is
the fastest it will ever scan with the synchronous configuration (DMM waits 10ms after sending MC).

I thought that the handshake configuration might improve on this since in theory the switch can do better than 10ms and might sending its own trigger sooner. So far I can't get that example to run even though the only new piece of info is the trigger used for the switch-to-DMM trigger (TTL1). I get an error dialog I have not figured out yet.

My main problem is the pre-scan setup time which I don't think is changed by the above params. The docs say auto-ranging on the '4060 would not be on unless sample trigger was 'immediate' and it is set to 'interval' in this example.

A better approach to this setup time problem might be to put the DMM in continous mode scanning just one channel repeatedly. The sequence would be:
Start the acquisition,
Wait well past the setup time (2sec),
Wait for the external edge,
Wait enough time for the very next complete scan,
Stop the DMM (or just read all the results) and pick off the last one.

If this is possible I should be able to get  a single sample within 30ms of my edge.
How would I read just the last result?
If I collected more than one ch this way with a scan list, how could I tell which result corresponded to which ch? Is there a better way?
 

[tadk]

Now that I look at the handshaking example closer, I see there is a 1sec delay hardcoded in just for the '4060. This tells me that the HW itself needs this time during initialization, and there is probably no way to make it faster.

I think the only way is to capture data continously and post process to extract the info I need.