LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Event at a specific moment of a data acquisition

Hi!

Thanks for your answer, I'll try what you suggested in the next few days, even though I don't see any noise going beyond the specified limits... since I've tried many other things, I have no other idea of what may cause this. It is really worth trying.

Thanks; I'll post back with the results in a few days.
0 Kudos
Message 11 of 22
(1,452 Views)
Maxime,

If you're still stuck on the "counts too fast" problem, could you post the code you used to generate a pulsetrain with your own DAQ device? It sounds like you were toggling a digital bit using software timing in a timed loop -- did you ever try the similar measurement using your DAQ board's other counter?

Under DAQmx, it's fairly easy to have your edge-counting counter get its edges from another counter's output. You may need to right-click the DAQmx terminal and select "Show Advanced Terminals" in order to see the choice for, say, "Ctr 1 Internal Output".

My internet connection is far from my LabVIEW box or I'd post you a sample to test. I can probably do it later if no one beats me to it.

-Kevin P.
ALERT! LabVIEW's subscription-only policy came to an end (finally!). Unfortunately, pricing favors the captured and committed over new adopters -- so tread carefully.
0 Kudos
Message 12 of 22
(1,450 Views)
Maxime,

Here's an example that simply routes signals internally from one counter's pulsetrain output to the other counter's edge-counting input. This method should be immune from issues such as external noise. To be 100% sure, you could disconnect your DAQ card cable either at the PC or at the terminal block so the card is isolated from other signals.

This vi will let you start and stop the pulsetrain at will, and will also let you change the pulsetrain frequency on-the-fly. The edge-counting counter just keeps counting regardless.

If you still get a counts-too-fast kind of problem, post back and describe any details you can think of...

-Kevin P.
ALERT! LabVIEW's subscription-only policy came to an end (finally!). Unfortunately, pricing favors the captured and committed over new adopters -- so tread carefully.
0 Kudos
Message 13 of 22
(1,439 Views)
Hi!

I just got some time to work on this again, so I tried to use a Schmitt Trigger, like suggested by Tom W.  I used a 74LS14 chip, with Vcc = 5.05V (same as comparator), placed at the output of my comparator.  The results are, in my opinion, very strange.

I used Paint to draw what I was seeing on the oscilloscope (see Output pictures.zip), both at the output of the comparator and at the output of the Schmitt trigger.  I first drew a "far" view (about 2 periods) and a "close" view (50µs-wide around the rising edge).  A wider trait in the drawing means a wider trait on the scope (= more noise).  It is quite easy to see that the output of the Schmitt trigger has a lower "high" voltage and contains much more noise than its input, which I find quite strange after reading the knowledge base and the datasheet.  This signal is counted even faster than the output of the comparator (no big surprise, considering the rising edge picture).  I really have no idea about where all that noise could be coming from.  From what I've read, the output of the Schmitt trigger should at least be as good as the one from my comparator, which is really not the case.  The results are the same with any in/out pair of the chip.

Answer to Kevin Price: I know that the VI I made wasn't the best for accuracy, but my only goal with this VI was to create a constant frequency signal (close to 60 Hz) that I could use to simulate the output of the comparator.  It worked well and was completed in less than 5 mins.  But I know that, should I have needed a better accuracy, there are far better ways to do this, and I have to say that I didn't know how to do it the way you suggested.

Until, I get an answer about what's happening with the Schmitt trigger, I will put it aside for now and try to investigate the source of the noise in my comparator during the week.

Thanks for your help!

Maxime B.

Message Edited by Maxime on 07-19-2005 09:43 AM

0 Kudos
Message 14 of 22
(1,407 Views)
Maxime,

I can expain one part. The output voltage of the 74LS14 is lower because of the nature of the internal circuitry of TTL logic devices. Even though it is often described as a 0 to 5 volt signal, TTL is actually defined as ranges of voltages. A low output is 0 to 0.4 V and a high output is 2.4 to 5 V with the typical switching threshhold about 1.4 V. So a 0.2 V low and 4.2 V high are quite reasonable.

The thick traces and the noise you are seeing is probably part of the problem. The little dips in the tops of the far view pulses look to me as though you may have a power supply problem. If the 5 volt power supply is dipping down slightly at a 60 Hz rate, it can produce waveforms like that.

I suspect that you have a ground problem, noise on the power supply, poor bypassing, or some similar issue that is causing your multiple transitions problem. The Schmitt trigger should clean up the comparator edge sufficiently to prevent multiple counts.

Lynn
0 Kudos
Message 15 of 22
(1,400 Views)
Hi and thanks for your answer!

First of all, I wanted to mention that the 5V voltage supply of the Schmitt Trigger is obviously not the same as the one of the comparator, since the comparator is using a ±12 V voltage supply (not a 5V! My mistake...).

There is indeed noise on the 5V power supply, but with a frequency of 120Hz.  In the very worst case, the peak-to-peak amplitude of this noise can be close to 0,5 V (beign normaly of 0.25 V).  0.5 V is quite much, since the recommended supply voltage of the 74LS14 is 4.75-5.25V (a 0.5V range).  This probably explains the malfunctionning of the chip.  However, the ±12V supply, powering the comparator, doesn't have any noise in it, which I find quite strange, considering that all of these are taken from the same DC power supply.

I'm continuing to investigate this...

Thanks!

Maxime B.
0 Kudos
Message 16 of 22
(1,393 Views)
Hi!

For some reason, the oscilloscope I was using was quite limited in the range that I could observe while zooming.  Now, I just found that the noise of my comparator signal was located in the falling edge (the falling edge was oscillating betwen 0-4V!), thus resulting in the rising edge noise at the output of the Schmitt trigger.  I simply  added a RC low-pass filter between the comparator and the trigger and now, my output signal is near-perfect and, more importantly, is counting correctly.

I can now resume my work to resolve the problem I had at the very beginning of this thread, using the method sugested by Kevin.

I'll post back if I have other problems.

Thanks!!!

Maxime B.
0 Kudos
Message 17 of 22
(1,381 Views)


@Kevin Price wrote:
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.


I tried the method you suggested, and the first step worked fine.  However, I didn't find how to use the first counter's output to trigger the second counter, since the trigger isn't the timebase itself.  I also tried to do it like suggested by Tom, using the terminal count pulse (note: I counted down, so the terminal count was 0 and no calculations were necessary... it was easier), but I'm still stuck at the same point.

I didn't find any useful information on how to trigger a counter with another signal, neither in the examples or on the site.  If there is some, please point me to it.

Thanks (again!) in advance!

Maxime B

Message Edited by Maxime on 07-20-2005 03:04 PM

0 Kudos
Message 18 of 22
(1,372 Views)
Attached is a screenshot of how you might configure for the method I described:
 
1. The first counter is set to use the comparator output as it's "tick source." 
 
2. I then placed a DAQmx Channel property node to query for the 1st counter's output terminal and passed it in as the start trigger for the 2nd counter.   In the sample attached, I also set it as a start trigger for the AI task, though you may want to change that.
 
3. Also note that the AI sampling clock was specified as the "tick source" for the 2nd counter.
 
4. Finally, note that I started the 1st counter after the 2nd counter.  This ensures that the 2nd counter is already "ready and waiting" before the 1st counter generates a pulse.
 
5. You may need to further modify the sequencing / synchronization of the AI with respect to the counters to suit your app.
 
-Kevin P.
ALERT! LabVIEW's subscription-only policy came to an end (finally!). Unfortunately, pricing favors the captured and committed over new adopters -- so tread carefully.
Message 19 of 22
(1,365 Views)
Thank you so much!

The example worked, except that I had to use the initial delays instead of the low ticks to create the necessary delay.  I've posted an image of the resulting VI.

I now have one last (hopefully!) question: the digital event is currently configured using MAX and used by other VI's (not at the same time), and it is using one of the digital lines.  Would there be a way to route (either internally or by adding wires on the board) the output signal of the second counter to this digital line?  It is not really important to accomplish this, since I would probably only have to change a few connections and modify simple things inside a few VI's, but, still, I would prefer if I could keep the actual connections like they are right now.

Thanks again!

Maxime B.
0 Kudos
Message 20 of 22
(1,350 Views)