How can I promptly and reliably generate an output signal upon fulfilling 2 software conditions?

[b777]

No it won't.   I can generate counter output with any of these examples, in a continuous, finite mode, but not upon a software condition.  It is not a problem that the counter output is not generated, but that there are more than one output coming out once the trigger is found.   That is the behavior of the acquisition / generation when the reading of the samples is set the way Dave proposed: reading one sample first to initiate the waveform and then reading all available samples and (it is my understanding) the amount of samples read is determined by the wait.vi.   When reading is done in a proposed way, the trigger seems to work fine, triggers reliably every time the threshold is found.

In an another attempt (program attached), when simply reading the samples without initiating the waveform, the counter output - one desired pulse - is generated promptly after the trigger is found, however the trigger seems not to be reliable and I am not sure if that has to do anything with having the generate output voltage in the same while loop.  I tried changing the numbers of samples to be read, value in the wait time vi, the length of the counter output pulse etc, however in no circumstances the triggering and/or generation is reliable.  Also, when specifying the read all available samples in this read vi, the message Error -20315 occurred at ma_Check Waveform Timing.vi is generated saying that: Analysis:  The waveform dt parameter is <= 0. The trouble is that there is no easy way (or i don't know it ) of seeing what is really going on on the hardware level. 

I've been working for months on this problem, communicated with the NI support engineers over the phone etc, and still don't know if this is even possible to do.  I would really like to know if it is not why not?  Perhaps you can figure out how to generate an output voltage signal upon a software trigger in a reliable and repeatable way and put it in the example finder so that other people do not struggle the way I am.  Also it would be nice to have a way of graphing the output signal and observing it on the front panel along with the input signal.

Thanks, Branka

[johnsold]

Branka,

You say the triggering is not reliable. Specifically what is not reliable? Does it fail to trigger on a signal which clearly meets the triggering specifications? Always or only some times? Or is it that the delay times are too variable? Are there multiple triggering points in your data sample? The Help for the Basic Trigger Level Detection.vi specifies that it finds the first trigger point.

What does the output pulse do? What are the consequences for your system if a pulse fails to occur, if it occurs after the desired condition but late, or if multiple pulses occur? I have some ideas for alternatives, but they may not work depending on the answers to these questions.

Software triggering is always subject to timing jitter due to OS latencies unless you are using a real time OS. Thus the question becomes "Can you get adequate triggering enough of the time to be useful in your application?," not "Can you trigger within a few milliseconds of the condition every time?" You (or your client) must define "adequate" and "useful" because they are dependent on your purpose.

In the VI you posted I have some questions.

The AI Create Channel specifes 1 channel but the AI Read is using the multichannel version. 1 Channel N Samples seems more appropriate.

Any trigger is delayed until the 100 samples are collected plus whatever time the Trigger Level Detection.vi takes. If the trigger criteria are met in the first few samples, the trigger is delayed 100 ms. Some sort of Point By Point approach could reduce this latency.

After triggering the output Is Task Done is called but the "task done?" output is not used to decide whether to stop the task. It is probably not an issue with single point outputs, but it is unusual.

Lynn

[b777]

Hi Lynn,

When I said the triggering is unreliable, I meant it fail to trigger on a signal which clearly meets the triggering specifications (I believe so).  I am importing a sinusoidal waveform from the signal generator 1V in amplitude, 0 offset, 1 Hz frequency and I set the level to 0, falling edge, hysteresis 0.2 (one of the scenarios - I played with the various frequencies etc).  The trigger fails to respond in a random fashion and I can't quite say the percentage of the failing triggers, but anywhere from 20% to 70 % (my guess) definitely very, very high.  Actually, the trigger vi seems to respond more often when samples to read is set to 100 ms than for smaller numbers, but i can't quite tell you what is the variation in the time response.  I was wondering is there a minimum number of samples that are required for the Basic Trigger Level Detection.vi to work well?

The counter output  is supposed to sent a voltage pulse to the driver to start the pump, and it is highly undesirable to miss the trigger.  We can tolerate the variation in the response time between 0 to 30 ms, but not much more than that.  The incoming signal would be a pressure signal (similar to the one I attached in the first question) and is of frequency 1 to 2 Hz.

I have changed the AI Read to be 1 channel N samples (thank you for pointing that out) and it did not improve the triggering function, but now it is possible to read all available samples as well - however with this option - no trigger is detected????

I guess I was trying to see if generation is done so that that does not affect the reading - I removed it and that did not help either.

I was looking into hardware timed single point acquisition earlier as it is recommended for the control applications, but i did not know how to accomplish data processing (measuring the integral under part of the waveform etc.) in this case.

If you have any recommendations, I would really appreciate,

Branka

[b777]

I have a few more questions:

I don't quite understand the function of wait.vi.  It looks like it determines the size of the chunk of data being read when number of samples is set to "read all available samples" (Dave said set it to less than 10 ms if you want to generate an output signal within 20 to 30 ms).  However, when the number of samples to read is set to 100 or so, and wait is 5ms, I don't understand what wait .vi actually do.

I was wondering would increasing the sampling frequency with the right combination of other parameters help solving the problem.  I increased the sampling freq to 10000 and it did not help, but perhaps I did not have the other parameters set reasonably well.

I understand that the software triggering is the subject to timing jitter due to OS latencies, but with the computer speed in the order of GB and the DAQ board with max sampl freq of 1.25 MHz, I simply can not get it that I can't accomplish the desired task.

[b777]

Also what function I should use to see that the data acquisition is "keeping up"?
 

[johnsold]

Branka,

I think that part of your problem is two constraints which appear to conflict. 1. You want to be able to respond within milliseconds of the conditions being met. 2. You need a data set that is about 1 second long to determine if the conditions are met.

One way to deal with this situation is similar to what is done in the Point By Point VIs. Accumulate small chunks of data in a shift register. Then perform sliding window calculations to check the conditions and allow prompt triggering of your output. Each system may need a customized set of parameters for sample rates, number of samples read, and so forth.

For your system I think I would: 1. Read the samples available every 5 ms. 2. Append the samples to a circular buffer implemented as a shift register or queue. The buffer should hold enough data to do the integration of the slowest input pulse, about 1 second from what you have indicated. When the buffer is full, the append process will overwrite the oldest data in the buffer since it is no longer needed. 3. Once the buffer has filled, do the integral calculation on the most recent set of data. 4. Check the most recent data for a zero crossing. 5. If (3) and (4) meet the criteria, then trigger the pulse. 6. Go to (1) and repeat.

When you start the acquisition it will take about a second before it starts the (3), (4), (5) part of the loop. After that there should be an update about every 5 ms.

The calculations should only take microseconds so this loop would run at 200 Hz (5 ms delay). The 5 ms plus any OS jitter would be the trigger delay. Typically the OS latencies are small, but sometimes can be tens or even hundreds of milliseconds.

On your other questions: Wait just tells the computer to ignore this VI for the time specified and then continue. If other nodes are ready to execute, they will run during the wait. If you specify a number of samples to read, the read function itself will wait until the specified samples are availble. If you have both a wait and a specified number of samples, both will execute. If the delay to get the samples is greater than the wait time, there is a chance that both "waits" may execute simultaneously (assuming no data dependency). If there is dependency, then they will execute sequentially.

I think there is a Property node which will report the number of samples available.

Lynn

[b777]

Lynn,

Thank you very much; this clarifies some of my thoughts about labview data acquisition. I will try to follow your suggestions and hopefully will have better luck.

Branka