What is the best way to rise a DO at a given time?

[patufet_99]

Hello,

In an application I continuously do an analog buffered data. I process the acquired data and when a trigger condition occurs I rise a Digital Output signal. With this approach the problem is that the delay between the trigger and the Digital Output depends on the position of the trigger on the buffer.

By waiting: (Buffer_length-Trig_position)*dt before rising the DO the delay will be nearly constant.

Would there be a more accurate way to do that while minimizing the overhead?

Thank you for any hint.

[jdunham]

QUOTE (patufet_99 @ Aug 12 2008, 11:36 PM)

Hello,

In an application I continuously do an analog buffered data. I process the acquired data and when a trigger condition occurs I rise a Digital Output signal. With this approach the problem is that the delay between the trigger and the Digital Output depends on the position of the trigger on the buffer.

By waiting: (Buffer_length-Trig_position)*dt before rising the DO the delay will be nearly constant.

Would there be a more accurate way to do that while minimizing the overhead?

Thank you for any hint.

I think we need some more information. Are you using an NI hardware product? E-series? M-Series? What is your sample rate (seems like it must be slow if your waiting scheme is working). If your process is continuous, then what are the conditions for resetting the digital output?

If your NI card supports buffered digital output, then you should be able to set the trigger for that task to the analog trigger signal.

If not, then you should be able to set up one of the counter/timers either in pulse generation mode or terminal count mode, and trigger that from the analog signal.

Either way you should be able to get 50-nanosecond response times for an E-seris card, and you should be able to add any delay you want and it will be very precise.

Either of those methods will require you to learn about DAQmx timing, triggering, and synchronization, but there are plenty of examples in the NI Example Finder. Probably none to do exactly what you want, but if you get stuck, you can ask more detailed questions or post your code.

Good luck

[patufet_99]

Thanks for your reply.

I use either E series or M series cards. (DaqCard 6036E or PCI 6229 for example).

Sample rate is normally 1kHz with a buffer of 1000 pts. I acquire data every second. The scope would be to have an accuracy of the order of the millisecond.

The DO reset condition is just a delay.

The process is continuous and several channels are acquired simultaneously. As there are several channels to trigger and I do not trigger directly from the acquired signals (signals are filtered and processed), the use of "Daqmx Start trigger" is not suited I think.

Before testing a new approach I just wanted to hear any suggestion not to miss a trivial solution.

Thanks for your comments.

[jdunham]

QUOTE (patufet_99 @ Aug 13 2008, 02:29 AM)

Thanks for your reply.

I use either E series or M series cards. (DaqCard 6036E or PCI 6229 for example).

Sample rate is normally 1kHz with a buffer of 1000 pts. I acquire data every second. The scope would be to have an accuracy of the order of the millisecond.

The DO reset condition is just a delay.

The process is continuous and several channels are acquired simultaneously. As there are several channels to trigger and I do not trigger directly from the acquired signals (signals are filtered and processed), the use of "Daqmx Start trigger" is not suited I think.

Before testing a new approach I just wanted to hear any suggestion not to miss a trivial solution.

Thanks for your comments.

You don't have to wait for an entire buffer to fill before you read the data. If you read the data as fast as possible, you can probably sample each point and test your trigger conditions a lot more often. Then you can control the digital output immediately, and you would have a repeatable 1-2ms latency.

[patufet_99]

QUOTE (jdunham @ Aug 13 2008, 05:42 PM)

You don't have to wait for an entire buffer to fill before you read the data. If you read the data as fast as possible, you can probably sample each point and test your trigger conditions a lot more often. Then you can control the digital output immediately, and you would have a repeatable 1-2ms latency.

Hello,

It is right that I don't have to fill all the buffer to read the data. As I filter the data I think it is an advantage to give the filter always a data chunk of the same size.

Anyway I do not need to have an immediate digital output after trigger, what I would like is a constant and repeatable delay.

Thanks again.

[jdunham]

QUOTE (patufet_99 @ Aug 14 2008, 09:46 AM)

Hello,

It is right that I don't have to fill all the buffer to read the data. As I filter the data I think it is an advantage to give the filter always a data chunk of the same size.

Anyway I do not need to have an immediate digital output after trigger, what I would like is a constant and repeatable delay.

Thanks again.

OK, one last try. When you read the analog input, you should be able to know the cumulative Daqmx scan mark of the beginning of your current buffer, and thus the scan mark of your trigger event which is some short time later. You can then call the property DaqmxRead.TotalSampPerChanAcquired. Don't be put off by the mysterious name; this extremely useful property tells you the current value of your analog task's scan clock. So this value minus your trigger event scan mark tells you how long it's been since the trigger event in real time (of course you have to use your sample rate to convert this to seconds or milliseconds). Then you can use "Wait (ms)" to wait the remaining time required for your constant delay. Obviously you would test this a few times and pick a constant delay large enough so that your remaining wait time is always a positive number.

With this technique, and no obvious performance/design problems in your code, you should get repeatable accuracy of 2-5ms (just a guess). If you want nanosecond accuracy, and/or hard real-time performance, you can accomplish the same thing with the counter/timers on your board and some fancy DAQmx setup. Please PM me if you need help with this.

Have fun,

Jason

[patufet_99]

QUOTE (jdunham @ Aug 14 2008, 07:50 PM)

OK, one last try. When you read the analog input, you should be able to know the cumulative Daqmx scan mark of the beginning of your current buffer, and thus the scan mark of your trigger event which is some short time later. You can then call the property DaqmxRead.TotalSampPerChanAcquired. Don't be put off by the mysterious name; this extremely useful property tells you the current value of your analog task's scan clock. So this value minus your trigger event scan mark tells you how long it's been since the trigger event in real time (of course you have to use your sample rate to convert this to seconds or milliseconds). Then you can use "Wait (ms)" to wait the remaining time required for your constant delay. Obviously you would test this a few times and pick a constant delay large enough so that your remaining wait time is always a positive number.

...

Thanks again for your help.

I am leaving for some holidays! I will think about that and check it at my return.

Regards.