Event at a specific moment of a data acquisition

[Maxime]

Hi!

I'm trying to create a VI which should perform data acquisition during which an event should happen.

The full problem is:
I have to do data acquisition (sampling rate up to 100000 samples/sec) of the voltage of a deformed 60 Hz sine wave signal. This data acquisition is saved into a file (Excel or DIAdem compatible) and is not displayed to the user of the VI in real-time (no worrying about displaying a graph). The problem is that after a fixed number of periods has been acquired, at a specific angle of the ideal sine wave (0° being the beginning of the sine wave, 90° the positive maxima...), a digital signal has to be sent to modify part of the circuit we are analysing, while continuing to gather data. I know that using an analog trigger, I can find a 0° point easily, then, knowing the sampling rate and the input signal's frequency, I know the number of samples to wait before the angle. What I don't know though is how to do this event at that specific moment without interrupting the data acquisition.

I am using LV7.1 with a NI-6110 DAQ device configured with NI-DAQmx. If you need additionnal information to answer, then just ask me.

Thanks!

[Tom_W_[DE]]

Hi Maxime-

Just to clarify, it sounds like you are planning to run a continuous analog input operation and then perform a digital output based on the results you obtain. The digital operation can be run at the same time without disrupting the analog input so you don't need to worry about that.

It seems that you have the scheme for deciding the proper time for the digital operation based on the 0 degree point, etc. I have attached an example that uses a continuously running While loop's iteration counter to simulate an acquisition point counter for a 1kHz analog input. I simply compare the counter value (i.e. number of samples taken for your case) to the value I need to wait before outputting my digital response.

A case structure is used to execute the digital output only after this condition has been met. If you need a more complex generation like a pulse or a software-timed digital pattern this method should work just as well.

Please let us know if you have any additional questions.

Thanks a lot!

[Maxime]

Thanks for your answer, but I saw that I didn't ask my question very well. The VI you suggested illustrates what I will use once I get to the 0° point, but I first have to get to it before I start counting. The VI I'm making should allow the user to choose how many periods of signal to acquire before the event occurs. The general structure of that part of the VI will probably be:
1. Start analog data acquisition
2. After N periods (as specified by the user; as much as 80), wait for the 0° angle
3. At the 0° point, start counting the samples
4. After n samples (calculated using the sampling rate and the angle), send the digital signal
5. Continue data acquisition for X periods of the signal (user defined too), then stop data acquisition
note: from step 1 to step 5, the data is acquired without interruption.

Now, the parts that are confusing me are the steps 2 and 3... How should I specify that I only want to start counting at a specific moment (if I start counting from the beginning, a very small variation of the frequency would cause problem)? I forgot to mention that a digital input is connected to a comparator circuit which is sending a "true" value while the acquired voltage is positive. It could probably help to find the 0° point. The DAQ device I'm using is a PCI-6110.

Thanks in advance!

[Kevin_Price]

Maxime,

If you can make your comparator signal TTL-compatible (sharp clean transitions from between logic levels), you should be able to accomplish steps 2-4 using the counter/timers on your board. Briefly:

1. Configure 1st counter for pulse generation using units of "Ticks". Use the comparator signal as the timebase. Set "Initial Delay" and/or "Low Time" to be N (I don't remember which of these settings is actually used for a single pulse). "High Time" can be any value >= 2. This counter will generate a single pulse with a rising edge corresponding to the 0 deg point of your sinewave after N periods.

2. Configure 2nd counter for pulse generation using the first counter's output as a start trigger. Use the analog sampling clock as the timebase. Again set up "Initial Delay" and/or "Low Time" to be n. "High Time" depends on how your external circuit works. If rising-edge sensitive, "High Time" shouldn't matter much. If level-sensitive, you may need "High Time" to be as long as the entire data acquisition.

Sorry this is short and dense, but I've gotta run now. Post back for more specifics...

-Kevin P.

[Maxime]

Thanks for your answer, Kevin!

It looks like a logical way to achieve what we want to do (btw, the comparator is TTL-compatible). Unfortunately, I can't test it right now, but as soon as I've tried it (probably in a few days), I'll post back with the results of my tests.

Maxime B.

[Maxime]

Hi!

Sorry to have taken so much time before posting back, but I seem to have a problem counting the edges of the output of the comparator. What happens is that the counter counts 15-20 times too fast.

At first, I thought that my signal's rise time was too slow, but I tried another signal with a much slower rise time and it functioned correctly.

Then I thought that my signal's small offset (the output of the comparator is 0.2 V low and 5 V high) of 0.2 V as probably too much for the DAQ device (it would have been quite surprising...). I used a function generator to create a 0,5 - 4,5 V signal and the counter worked well...

Right now, I am still investigating to find the cause of this problem.

If anyone has any idea about this, feel free to post 😉

Thanks!

Maxime B.

[Tom_W_[DE]]

Hi Maxime-

I'm not sure why your counter would be counting too fast, but it might have something to do with the comparator circuit. Are you able to count edges successfully with your counter? I would suggest using the LabVIEW shipping example "Count Digital Events.vi" that can be found by accessing Help>>Find Examples in LabVIEW and then browsing to Hardware Input and Output>>DAQmx>>Counter Measurements. You will need to connect your comparator output to the source input of the counter.

If this VI works for you then I have another suggestion along the lines of Kevin's earlier suggestion to use two counters. The counters on your board can be configured to output a pulse once the counter reaches your Terminal Count (i.e. the highest value the counter can reach before rolling over to zero). Your PCI-6110 has 24-bit counters, so the terminal count will be 2^24-1 or 16777215.

By using the first counter to count zero crossing events from your comparator and setting the initial count to be a certain number of counts less than the Terminal Count you can output a pulse after a user-specified number of rising edges. This output can then be routed to trigger pulse train generation on the second counter of specified frequency and length. Finally, you can route this generated pulse train to be the external clock for your analog input operation.

I have attached a modified edge counting example that shows how to route the terminal count to a pin that can be used to trigger the pulse train on the second counter. For an example of AI operation with a counter-generated pulse train, check out "Multi-Function-Ctr Retrigg Pulse Train Generation for AI Sample Clock.vi" in the Hardware Input and Output>>DAQmx>>Synchronization>>Multi-Function folder in the Example Finder.

Thanks-

[Maxime]

---

@Tom W. wrote:
I'm not sure why your counter would be counting too fast, but it might have something to do with the comparator circuit. Are you able to count edges successfully with your counter?

---

The small test VI I made used the counter to count the rising edges (I tried the failling edges too... the results were the same, even for the comparator) of 3 other sources:
-An oscilloscope's test signal (used to ajust probe compensation), which is a 1 kHz 0-5V signal with a rise time about 3 times slower than the comparator
-A digital signal I had generated on the DAQ device, using a timed loop to change state (8ms between a change of state = a period of 16 ms... quite close to 60 Hz)
-A function generator ajusted to output a 60 Hz 0.5-4.5V signal (to see if the small 0,2V offset of my signal was the cause of my problem)

---

@Tom W. wrote:
I would suggest using the LabVIEW shipping example "Count Digital Events.vi"

---

I have tried the exemple Count edges, but it didn't work... I haven't tried Count Digital Events... I will try it even if I know that I can count from other sources... I will also take a look at the VI you posted and at the other example.

I will post back either tomorrow or next week

Thanks for your help!

Maxime B

[Maxime]

I just tried the example you suggested (count digital events.vi), but the results are exactly the same as they were: the counter is still counting way too fast. Using an oscilloscope, I zoomed on my signal, and there is some noise somewhere between 0.1-0.3V on low levels and between 4.8-5V on high levels, so I would like to know: what is considered a rising edge by the DAQ device? Is it a passage from a low level to a high one, or simply a quick voltage increase? If it is the latter, then, it would count every small (max 0.2 V) rising edge of the noise...? I really have no other idea of what may cause this...

Thanks

Maxime B.

Message Edited by Maxime on 06-28-2005 09:14 AM

[Tom_W_[DE]]

Hi Maxime-

The counter channels on your board will be governed by a voltage input low (VIL) value of 0.8V according to the specifications. The voltage input high (VIH) value is 2.0V. This means that anything below 0.8V is logic "low" and anything about 2.0V is logic "high."

I think it is likely that your comparator is giving spikes beyond these limits and is giving false counts. A count is considered anytime the line starts below VIL and moves upward beyond this threshold. Any noise on the lines will effect the count greatly.

If you are able to count correctly with a function generator but not the comparator then I would suggest that noise is definitely the problem. One way that you "square up" and dictate the threshold levels of a digital signal is with a Schmitt trigger device as described in this KnowledgeBase.

I would suggest employing this method if you're able to correctly count a function generator source because this indicates that the DAQ hardware is working properly and the comparator signal is the problematic piece in the system.

I hope this helps!

Thanks-