NI-DMM speed

[mdbeaster]

I'm using a PXI-4065 multimeter with MS Visual C#.NET 4.0 and NI-DMM. I have a test that requires a sort of closed-loop feedback system and I need to take DC voltage readings with an interval of every 5 ms or better (software controlled) for a period of 1 second. It needs to be software controlled so that the application can adjust a second parameter in response, ie. I can't use a multipoint measurement function. I have read all the NI-DMM documentation regarding aperture times, settling times, etc, and adjusted my function accordingly to read 4.5 digits, no settling time, and a discrete value of 0 for trigger delay (accuracy is not very important...I need the speed here). With the caveat of understanding that an RTOS might be better suited to do this, if money and time were no object, I need to make it work with what I've currently got.

I inserted a start time/finish time measurement before and after calling the read function (using DateTime.Now.Ticks; 1 tick = 100ns) and I'm measuring around 30 ms. Even with some processing overhead, I can't believe it should take that long to process this function with all the delay stuff on the meter turned off. Am I missing something? My NI-DMM function calls are as follows:

...

...

PXI4065_Session1.ConfigureMeasurementDigits(DmmMeasurementFunction.DCVolts, 300, 4.5);
PXI4065_Session1.Trigger.DelayAuto = false;
TimeSpan triggerDelay = new TimeSpan(0);
PXI4065_Session1.Trigger.Delay = triggerDelay;
PXI4065_Session1.Trigger.Source = DmmTriggerSource.Immediate;
PXI4065_Session1.Advanced.SettleTime = 0;
measuredReading = PXI4065_Session1.Measurement.Read();

...

...

Please help!

[Thomas-B]

Hi mdbeaster, 

From what I can see, it should be optimized fairly well, as far as the calls being made by the driver goes. Assuming "triggerDelay" is set to zero, I don't know that there is much else you can do, regarding hardware configuration. 

It looks like the delay you are experiencing is due to other operations occurring in your application (like the second parameter adjustments in response to the readings being taken). It also will be dependent on other events occurring within your operating system, such as occasional virus scans, Windows checking for updates, etc. A maximum loop rate is optimistically about every 3-4ms, and that is without much of anything else going on on your system. Is there a way to pare things down a bit? I don't know that you can reach 5ms, since you have to dynamically make changes based on your data readings, but optimizing your code and eliminating as many other processes on your computer that could be interfering might help you drop below 30ms.

Other options would include using a real-time operating system, or finding a way to do what you need with hardware timed readings. However, from what you have said, it sounds like you have determined these are both out of the realm of possibility.

This probably isn't what you wanted to hear, but hopefully it is helpful. 

[rsvaidya · Accepted solution]

Hi mdbeaster,

Could you please check if the following suggestion by NI-Dmm driver experts is helpful.

Quote

"The read function will implicitly call initiate and then fetch, but the way that the customer is configuring the device, this is necessary.

Multipoint could be used in this case since the customer is not actually reconfiguring the DMM, they are just reconfiguring something else based on the dmm measurement.  The customer would need to use initiate and fetch multiple instead of read.  They would then fetch all available measurements and use just the newest one for their calculation.  This should allow them to get under that 5 ms requirement (I got it to under 1 ms with no calculations).

An even better way is to use multipoint with software triggers. 

This ensures that the customer does not receive a stale measurement and use that stale data in their adjustment of whatever.

1) Configure mode/range/settle time
2) Setup for multipoint with enough points for the 1 second period
3) Configure trigger to software
4) Initiate
5) In a loop:
        a) send software trigger
        b) fetch
        c) use measurement as desired"

Thanks & Regards,

Raghavendra

[mdbeaster]

Very helpful solution and it looks like the second suggestion will do the trick. Thanks so much!