Measuring the time delay between changing the amplitude of a signal and when a relay turns on

[Robroy_95]

Hi,

I'm working on a automation test setup for a product where the plan is to be able to measure the time delay between when we change the level of a generated signal (being fed to the UUT) to when a relay on the UUT switches on (allowed to take a maximum of 100ms). I'm using a cDAQ9178 and in it we have a NI 9205 analog input module, a 9269 analog output module and two relay modules for switching between different input combinations.

I'm using TestStand to control the test and use a StationGlobal variable there to control the amplitude of the signal being generated.

I'm having problem with coming up with a sufficiently good way of measuring this as the 9205 can't sample simultaneously on several channels. I first tried a solution where I would swap between measuring a channel where the control signal is sent and the channel where I have the relay plugged in, thinking that as the 9205 is capable of 250kS/s I could take just a few samples of each channel before jumping to the next. Here though the process of initializing the DAQmx Read, doing the read itself and then clearing the task so that the new one could start the process took to much time (just one read with the DAQmx took about 100ms) and the entire turn about 130ms (measured using the "high resolution relative seconds timer").

I next tried to trigger the relay channel measurment of the signal channel change but could not get the analog trigger to work on any other channel than the same channel as the read was done on and as I need the time for when the signal changes aswell as the relay switch this dosen't seem to work either.

Now I have been working on a more direct timing as seen in the attached file, taking a time stamp when the TestStand variable controlling the generation is changed and then checking at what time stamp the relay channel goes above a given value, 1 volts in my case. Comparing these two still gives a value of atleast 100ms, but I can by manual observation with a oscilloscope see that the correct time is about 5ms.

I wonder if someone could lend me a hand in working to improving the speed of this (if it's possible to measure such small time changes). I know this is a lot of text and I probably missed a lot so just ask if you wan't to know anything else! I'm working on creating a somewhat minimum working example of the first two cases but that will come along tomorow.

[Robroy_95]

Here are the two other bases I've had when working on this problem, a minimum working example for triggering and a somewhat minimum example of switching between measurments on two different channels.

As I see it the problem is to know when the signal generator acctually switches and then getting a reliable time stamp for this moment, on a scale of miliseconds.

[SasounT · Accepted solution]

Hi Robroy_95,

Page 20 of the NI 9205 manual covers settling time and accuracy performance of the module.  The short answer is that at maximum speed, the multiplexer can switch 250,000 times a second, for a scan interval of 4 microseconds.

In CompactDAQ, the default rate for this multiplexer is set as follows (from page 25 of the cDAQ-9172 manual😞

The driver chooses the fastest conversion rate possible based on the speed of the A/D converter for each module and adds 10 μs of padding between each channel to allow for adequate settling time. This scheme enables the channels to approximate simultaneous sampling. If the AI Sample Clock rate is too fast to allow for 10 μs of padding, NI-DAQmx selects a conversion rate that spaces the AI Convert Clock pulses evenly throughout the sample. NI-DAQmx uses the same amount of padding for all the modules in the task. To explicitly specify the conversion rate, use the ActiveDevs and AI Convert Clock Rate properties using the DAQmx Timing property node or functions.

Analog Input Timing Considerations for C Series Devices

Could the answer be to swap to something with simultaneous sampling available like the 9220?

Let us know how you get on,

Sas

[Robroy_95]

Hi Sas and thank you for taking the time to send a reply to my question!

I'm not sure how you mean that I should use that specific information from the data sheets to improve my application, if you would find the time to elaborate on that subject I would be very happy indeed!

Our solution though seems to be landing in your other suggestion, acquiring a NI 9220 to handle true simultaneous sampling of the channels. 

If you do have time to explain how you meant by what you wrote I'd still be happy, and perhaps some other people out there who will try this some day. No matter what I'll mark your answer for accepted in a few days time and I thank you for your input.