6608 80 MHz timebase

I have a PXI system with a 6608 timer device in slot 2 and a 5122
digitizer in slot 3. I know that the 6608 has an internal 80 MHz
timebase, and I would like to use this timebase as a clock source for
the 5122 using LabVIEW. I would prefer to route the timebase
internally through the PXI backplane or a RTSI line, but would accept
routing the timebase to something like PFI 0 and wiring it externally
to the digitizer CLK IN. I have not been able to learn how to route
the timer's 80 MHz timebase to another line that the digitizer can use
for a clock source, and I have not learned how to use any digitizer
external clock source but CLK IN and PXI Star. Any help would be
appreciated in learning any of these things.
This has also been posted to the LabVIEW board, I'm posting here to cover my bases.

Hi Tim,
The 5122 digitizer can be synchronized with external sample clock only if this clock is routed on the CLK IN (front panel SMB connector) or the PXI_Star_Trigger of the card. In your scenario, it would be easiest to export the 80MHz timebase from the 6608 to the PXI_Star_Trigger line and then specify that the clock source for the 5122 is the PXI_Star_Trigger. Use the Daqmx_Connect_Terminals.vi to export the 80MHz timebase to the PXI_Star_Trigger line on the 5122. On the digitizer side, you will have to use a property node in order to specify the source clock. Please see the jpg attached below.
I hope this helps.
Regards,
Natasa
Attachments:
export_signal.JPG ‏11 KB

Similar Messages

PXI 6608 80 MHz timebase

I have a PXI system with a 6608 timer device in slot 2 and a 5122 digitizer in slot 3. I know that the 6608 has an internal 80 MHz timebase, and I would like to use this timebase as a clock source for the 5122 using LabVIEW. I would prefer to route the timebase internally through the PXI backplane or a RTSI line, but would accept routing the timebase to something like PFI 0 and wiring it externally to the digitizer CLK IN. I have not been able to learn how to route the timer's 80 MHz timebase to another line that the digitizer can use for a clock source, and I have not learned how to use any digitizer external clock source but CLK IN and PXI Star. Any help would be appreciated in learning any of these things.

Please see this post.
Regards,
Natasa

Can we lock 80 MHz timebase to PXI_CLK10 on PXI-6220 M Series DAQ?

I am using PXI-6220 to measure Frequency/Period of 32768 Hz clock signal, accuracy is very important. I have provided signal to measure on Gate input of Ctr 0 (PFI 9). I am using 80 Mhz Timebase. I want to Lock PLL to PXI back plane 10 MHz reference (PXI_CLK10) which in turn is locked onto the 10 MHz reference via PXI-5600 on Slot 2 (External 10 Mhz standard is connected). so far I don't see a way to lock PLL to PXI_CLK10. Is that possible at all? see the image attached to this message.
Attachments:
M Series DAQ Question.png ‏62 KB

Hello Abhatti,
Based on the diagram that you have attached, the M-Series card can PLL to a higher accuracy clock such as the PXI Clock_10. The way to configure this change using the DAQmx driver is route the signals using the DAQmx Timing RefClk.Src Timing property node. Once you place down this property node, and specify the RefClk.Src attribute, you select the PXI-Clk10 as your reference clock source. This will discipline the 80 MHz Timebase of the DAQ card to the 10 MHz reference clock of the PXI chassis. Which chassis are you using? Also, how have you PLL'ed the 10 MHz backplane clock to the PXI-5600 Downconverter?
Michael L.
Applications Engineer
National Instruments

PCI-6281 How to use80 mHZ timebase for A/d and D/A sample clocks

Does anyone know how to use the 80 mHZ internal clock as the timebase for my A/D and D/A sample clocks rather than the default 20 mHZ timebase?
I am using straight NI-DAQmx version 8.3 with C code. No Lab View, no Measurement Studio.
I have an application which uses the D/A to generate a sequence that is collected by the A/D. The D/A is clocked out at an integral multiple of the A/D clock. In order to maintain this integral relationship I can only use a limited set of Sample Clock Timebase Divisor pairs (as returned by DAQmxGetSampClkTimebaseDiv). This means that am further from my desired base frequency than normal. For example, using the degault 20 mHZ timebase, if I want a 2000 hz center fequency, the closest I can get is 2003.205 hz.
I cannot find anyway to use the 80 mHZ internal clock as the timebase for my A/D and D/A sample clocks. If I could, it would be possible to get closer to my desired center frequency.

Post is responded to in the multifunction DAQ forumn.
PCI-6281 How to use80 mHZ timebase for A/d and D/A sample clocks
Have a good one.
Michael D
Applications Engineering
National Instruments

Counting (interneal timebase)events with only one counter

Hello,
i am using a PXI-6115 card. This card is external clocked with 8 MHz. But I want to measure only about every second. So I divided the external clock with the internal counter 0. This works fine.
Now my problem. Now I want to know the external clock rate. Is it possible to build a pulse period measurement with only one counter??
I thinking of counting internal timebase- pulses with counter 1 and to start and stop the counter 1 by the output of counter 0.
Is this possible and how??
Thanks for help, Ruediger

Yes, there's a way to measure pulse periods with a single counter. The trick is to perform a buffered period measurement and sum the periods. The size of the buffer will determine the quantization/roundoff error.
The source of this error is that you have no control over the initial phase relationship of your external clock and your internal timebase. There's a nominal ratio between the two frequencies, and you'd start by expecting ratio * (buffer size) total cycles counted.
However, your actual count must be an integer, so you'll get either the next-highest or next-lowest integer, but you can't predict or control which one.
Example: If you collect 1 period at 8 MHz using the internal 20 MHz timebase, you'll capture either 2 or 3 e
dges from your timebase, implying a measured frequency of either 10 MHz or 6.6667 MHz.
If you collect 1001 periods, you'll capture a total of 2502 or 2503 timebase edges, implying a measured frequency of either 8.0016 MHz or 7.9984 MHz.
Notes:
1. In many cases, you can set up for buffered event counting, using the internal 20 MHz clock as a source and your external 8 MHz as a gate.
The advantage is that the buffered values already represent cumulative time so you don't need to sum them.
A disadvantage would be that the internal 24-bit counter value will roll-over in less than 1 second at 20 MHz. I typically capture periods and then sum in software because I can convert to floating point between capture and sum if necessary to produce both high-resolution and long duration measurements.
2. You should typically ignore the very first value in the buffer and work only with the others. If you want to capture 1001 legitimate periods, size the buffer for at least 1002
-Kevin P.

How Can I Driving the PXI Backplane Clock with a PXI-6608?

How Can I Driving the PXI Backplane Clock with a PXI-6608?
Is the PXI Backplane Clock the timebase of the PXI Trigger BUS?
How Can I use a PXI-6608 as the timebase of the PXI Trigger BUS?
Thanks!

Hi,
The 6608 must be in slot 2 of the chassis. Once you make a call to the DAQ driver, the OCXO on the 6608 will be routed to the PXI_Clk 10 line.
More information on the backplane and routing clock signals can be found in these Knowledge Bases:
http://digital.ni.com/public.nsf/websearch/5EC370419A5ECA7A86256CFC0061C528?OpenDocument
http://digital.ni.com/public.nsf/websearch/D5B8D4D3B67DF1E086256BF8007BBF93?OpenDocument
I hope this helps. Have a Great Day!
George

Change timebase on Counter Source

Hi,
I'm using the NI-6221DAQmx board for testing a motor control board. I use both counters, one for controlling the motor and one for measuring the frequency of a feedback signal.
Frequencys I'm measuring are between 50 and 300 Hz. The feedback line with the signal is connected to counter 0 gate.
This is working very fine up to a frequency of about 250 Hz. Then I receive some strange sample values. 5 samples OK, 1 exactly at 4000 (ticks), then 20 samples OK and one bad.
So, I wanted to change the timebase on the counter source from 80MHz to a lower frequency. But if I do this by routing the signal of the timebase to PFI8 my read function results a timeout.
I can't find an examplecode for VB6 for changing the counter source, but the user manual of the card tells that this is possible.
Does anybody know the problem of the bad samples, or can tell me the correct coding for changing the counter source?
earny

Hi earny,
Counting the 80 MHz timebase takes about 53.69 seconds to roll over--the rollover is the usual reason to want to use a lower frequency timebase and doesn't really apply to your situation. I don't believe that the timebase is the cause of your problem. However, to answer your question, you may set the counter timebase with a DAQmx Property. In VB.NET you use CounterTimebaseSource in the CIChannel class.
What I think is more likely happening is that you are seeing a small amount of noise or glitching on your line, which is resulting in the card reading duplicate edges on some transitions. This would manifest itself as reading in an occasional high frequency (e.g. 4000 ticks of the 80 MHz timebase is a 50 microsecond period).
I suggest to try using digital filtering (see M Series User Manual). With digital filtering enabled, the counter would only register pulses larger than {125 ns, 6.425 us, or 2.56 ms). If your max frequency is only 300 Hz, you should be able to safely set the 2.56 ms digital filter, which is guaranteed to pass through any signal up to ~390 Hz. Any high frequency glitches that occur during the transition of your signal would be filtered out.
To enable digital filtering and set the minimum pulse width, use the CIChannel.FrequencyDigitalFilterEnable and CIChannel.FrequencyDigitalFilterMinimumPulseWidth properties.
I hope this helps, let me know how it goes!
Best Regards,
John Passiak

Pulse train generation fails with certain values for "number of samples"

I'm generating a retriggerable analog output signal, and so I'm using a counter as the sample clock (see: Retriggerable AI Using Retriggerable Counter). I am finding that, above a certain number of samples, and only for certain values of the number of samples, the counter task gives me error -200305, "Desired finite pulse train generation is not possibe." The error crops up only when actually starting the task.
The analog signal that I'm trying to generate will be about 800 kHz, so my counter is set to run at the same frequency. I find that the counter task works fine if the number of samples to generate is anywhere between zero and 671,088 samples. Setting the number of samples to 671,089 gives the error above, as does 671,090 samples and so on. However, using 671,096, the counter task works fine. After that, the counter seems to output fine only if the number of samples is divisible by 8.
The only thing I can think of is that (617088 samples) / (800000 Hz) = 0.839 s. At the internal clock rate of 20 MHz, 0.839 s is 2^24 samples, and it is a 24-bit counter on this hardware. So if it's this internal counter rolling over, that's fine and I can work around that. But if that's the case, what I don't understand is why increasing the number of samples in increments of 8 samples still works.
The hardware is a PXI-6733 board, running with LabView 7.1.1 and NI-DAQmx 8.1.

Hmmm, multiples of 50 & 100? Now I'm puzzled again.
Here's how to make sense of the 100 kHz timebase idea though, even if it turns out not to be the right explanation. For a retriggerable finite pulse train, you actually use a pair of counters. If you were to program it manually, you could set your output counter to generate a continuous pulsetrain at 800 kHz using the internal 20 MHz timebase. This output counter would also be configured to use the other counter's output as a digital level-based pause trigger. So the 800 kHz pulsetrain is only output while the other counter's output is, say, high.
The other counter is configured for retriggerable pulse generation. The pulse duration or high time should be set for (# pulses) / (800e3 pulses/sec). This other counter can be configured to use the 100 kHz timebase, so its high time would then have to be an integer multiple of 10 usec.
So let's see... An 800 kHz pulsetrain is possible with a 20 MHz timebase (exactly 25 cycles). A 700 kHz (28 + 4/7 cycles) or 900 kHz (22 + 2/9 cycles) is not. So when you request those other frequencies, you actually get a near approximation. I dunno if DAQmx can be queried for the actual value correctly or not -- I recall an early version that reported back whatever freq you had asked for rather than what it actually used. Queries based on ticks (rather than time or freq) did return what was actually used, as I recall.
Let's suppose a request for 700 kHz gets truncated to 28 cycles of the 20 MHz timebase making a 1.4 usec period. Then 50 of those periods becomes 70 usec, which is evenly divisible by the 100 kHz timebase. Bingo! (Note: 70 is the least common multiple of 10 and 1.4)
Now suppose the request for 900 kHz turns into 22 cycles of the 20 MHz timebase, or a 1.1 usec period. Now it takes 100 of those periods to get to 110 usec, which is also evenly divisible by the 100 kHz timebase. Bingo again! (Note: 110 is the lcm of 10 and 1.1).
Did you follow the method here? It should help you figure out expected results for various output freqs and #'s of samples.
-Kevin P.

How to count frequency of two signal at the same time ?

Hello every one
please help me with this one i am really stuck.
The situation   : I have two square wave signal, and i want to measure the frequency of both of themat the same time.
the problem : Error -50103 occurred at DAQmx Read (Counter DBL 1Chan 1Samp).vi:3
Please see the attachement.
i also have 3 analog inputs to be measured.
but i dont have any problem with the analog inputs,,,multiple analog inputs can easily be measured,,,,,but the prob lem is in the digitl (square wave ) signals.
Attachments:
i want to use two counter input.GIF ‏54 KB
two counter tasks1.vi ‏250 KB

NI has an excellent overview of the accuracy and tradeoffs of the different freq measurement methods titled "Making Accurate Frequency Measurements." To boil down the essence of it, the (possibly) increased accuracy of the 2-counter method depends on a relatively long collection / accumulation time which would in turn typically limit the rate at which you could update your measured freq value.
Now let me offer some friendly but blunt advice. LabVIEW makes it easy to collect data. However, there are many other factors affecting the usefulness of that data. I support the dictum: "It is hard to measure *well*."  Choice of sensors, their sensitivity to environment, various sources of noise, an understanding of the decision to be made from the data, programming methods, etc. And even more etc.
What I mean is that just because a hardware freq measurement can be performed that is precise to 1 part per million, it would be very RARE in a test that ALL of those 6 significant digits prove useful. In your app, the measurements are presently only approximately correlated in time. And the gap of blind time between measurements will usually represent a much longer period of time than the measurement itself.
Analogy: suppose you had a 100 minute film at 25 frames/sec for a total of 150_000 frames. Now start selecting individual frames that are separated by some random # of frames between about 200 and 500. In the end, you may end up with a sequence of 400 frames in the correct order. Each individual frame is VERY accurate, but the collection of all of them can zip by in 16 seconds and not give you a much understanding about the movie.
What would usually work out much better is to sacrifice some accuracy in order to collect a greater quantity of frames. You trade off the instantaneous accuracy for the overall coherency.
Sorry, got on a roll...   Back to your question. My own preference is almost always to avoid consuming hardware resources when not truly necessary. I've been toying with counters for many years and have still never once deployed an app using a 2-counter frequency measurement. I do the 1-counter measurement and save the other counter(s) for other purposes.
If you've got an M-series board, the 80 MHz timebase allows you to measure a 500 kHz pulsetrain with a quantization error of only about 0.06% (1 part in 160). There's a pretty fair chance that whatever physical process emits that pulsetrain isn't appreciably more stable than that
-Kevin P.

I want to create a TTL pulse. The stepper motor I'm trying to control responds to a high to low edge, when the low pulse width is greater than 0.5 microseconds. What is the best way to go about creating a pulse like this?

I'm using the NI PCI-6025E card connected to an SCB-100 wiring peripheral. I'm programming the DAQ card using LabVIEW 6.0.2 on a win95 box.
My first attempt has yielded some surprising results.
I created a vi with a single while loop set to true. Within that while loop is a two frame sequence. Both frames use the "Write to Digital Line.vi".
The first frame sets the line in wire to false.
The second frame sets the line in wire to true.
The device channel on both frames has been set to my user defined channel nam
e -> clock.
clock --> sets the DIO0 channel to be digital write out.
Using an oscilloscope and some wires I hook ground to the SCB-100's digital ground and I hook the probe to the DIO0 channel. What I see are two different pulses alternating between one another. One has a pulse width of 5ms and the other has a pulse width of about 50ms. You seem to get a grouping of one type of pulse followed by a grouping of the other type of pulse.
Obviously this is very strange and not what I want. It is also far too slow. So I'd like to know if anyone knows how to do this properly. Remember I only need a low pulse width of 0.5 microseconds.
Thanks,
Any help or guidance would be much appreciated.
Scott

Scott,
You don't need to use a digital line to create a TTL pulse. The PCI-6025E has two onboard general purpose counters. You can use one of these counters to create a single pulse of the desired pulse width. For an example of how to program the counters on your board, refer to LabVIEW's Search Examples>>I/O Interfaces>>Counters>>Pulse Generation>>DAQ-STC based.
The advantage of using a counter over the digital line is that it allows you to control the timing of the pulse through hardware and not software. Thus, it is inherently faster, and the timing resolution is more accurate. The counter will count down an internal 20 MHz timebase to create the pulse delay and the pulse width.
For more information on the hardware capabilities of your board, you can refe
r to the User Manual online at www.ni.com/manuals.
Hope this helps.
Regards,
Erin

How to filter starttrigger on counter output precisely

HW PCI6602
Measurement studio 2008 (C#)NI-DAQmx 9.02I’m trying to trig a camera using the output from a counter.
The camera should be trigged when the counter input pulse width is larger than approx (filterPulseWidth 10us).To do this a have set up the following tasktask.COChannels.CreatePulseChannelTime(counter, "TriggerTaskChannel", COPulseTimeUnits.Seconds, COPulseIdleState.Low, 0, 80E-6, 0.007); task.Triggers.StartTrigger.Type = StartTriggerType.DigitalEdge; task.Triggers.StartTrigger.DigitalEdge.Edge = DigitalEdgeStartTriggerEdge.Rising; task.Triggers.StartTrigger.Retriggerable = true;task.Triggers.StartTrigger.DigitalEdge.DigitalFilterMinimumPulseWidth = filterPulseWidth; task.Triggers.StartTrigger.DigitalEdge.DigitalFilterEnable = true;Unfortunatly this filter has the following behaviour”If the period of the filter clock timebase is tfltrclk, this filter guarantees topass pulse widths that are 2*tfltrclk or longer and to block pulse widths thatare tfltrclk or shorter. A pulse with a width between these two ranges may ormay not pass, depending on the phase of the pulse with respect to the filterclock timebase”.It means that I have no sharp distinction on my filter as one would when applying a filter to an ordinary pulse width measuring task. Implementing this with via the software in a callback is to slow.The bottom line is that I would like to generate a pulse on my counter output when the trigger/counter input is greater than say 10us. The output pulse could be predetermind as in the sample code above or as long as the filtered input (I.e counter just pass filtered input to my output).How can this be done? BR
Jongas
Solved!
Go to Solution.

Hi Jongas,
Is it OK if the trigger is sent once the pulse hits 10 us, rather than
on the exact falling edge? I'll assume the exact timing isn't as important, but you would like the trigger to occur very close to the falling edge (within a couple of us). The important thing is that we trigger as close as possible to when the PWM has hit 50% duty cycle.
Some brainstorming:
Digital Filtering on the 660x Isn't the Best for This:
Digital filtering might not be as practical here on your 6602 due to the region of uncertainty between 5 and 10 (or 10 and 20) us pulses. The TIO boards count two consecutive edges of a filter clock to determine when to pass a signal through so the guaranteed rejected pulse width is always half of your guaranteed passed pulse width (providing an external filter clock timebase that is synchronized with your external signal could potentially reduce this uncertainty but I honestly haven't tried this before and I would imagine it is not going to be very straightforward).
X Series Alternative:
Our X Series devices use a different method of digital filtering that would work better for you. If a hardware change is an option (and you can use PCIe) then you might consider this. You could use the 20 MHz timebase as your filter clock timebase and could guarantee to pass 10 us (200/20M) and reject 9.95 us (201/20M). The 6320 is currently our lowest cost X Series board. A couple of points about this solution:
1. To configure the PFI filter, you need to use some sort of dummy task to
access the property nodes. Here is an
example of this (although it is written in LabVIEW).
2. You can route the filtered PFI signal to be exported on another PFI line, but this will reserve Counter 3. This is documented in the Device Routes tab of Measurement and Automation Explorer.
3. The filtered output will be 9.95-10 us delayed from the input signal, so you could trigger the camera off of the rising edge of the filtered output directly and be fairly close to the actual falling edge.
External AND Gate Alternative:
You could configure a Counter Output to generate a re-triggerable pulse with a 10 us initial delay (to be triggered off of the rising edge of your PWM signal). Assuming the pulse is short enough to complete before the next period of your PWM signal, the counter output would only be high at the same time as the PWM signal if the signal was longer than 10 us. Use the external AND gate to combine these two signals and the result would be the trigger for your camera (the rising edge would correspond to 10 us after the PWM signal first goes high).
If you wanted to you could make the counter output pulse a little longer (say 8 us) and trigger the camera off of the falling edge out of the AND gate (a.k.a. rising edge out of a NAND gate) which would line up with the exact falling edge of the PWM signal. Don't make the CO pulse too long or it will overlap with the next period of the PWM.
Another Idea:
One idea that I keep coming back to is to use the internal rollover event of a counter input task (a pulse is generated whenever a counter rolls over on its Internal Output which can be routed to a PFI line). I don't think this will work, but the idea in theory would be to:
1. Set Default state to known value (e.g. 2^32-200).
2. Gate the Counter so it only counts during the time PWM is high. Have it count the 20 MHz timebase.
3. Reset the Counter to default state on the falling edge of the PWM signal.
4. The counter would rollover if 200 pulses occurred of the 20 MHz timebase (10 us), and the Counter Output could be routed to a PFI line to trigger the camera.
The problem is that there is no good way to reset the counter except for an encoder measurement (Kevin has already made a nice suggestion about this). A Pulse Width Measurement would technically reset the counter, but you cannot currently set the default value of a Pulse Width Measurement task so there is no way to make the rollover happen prematurely).
Configuring an encoder measurement and working with the multiple counters on the 6602 to produce appropriate A,B, and Z signals might be a method to look into further, but at this point I think you'd be better off with an external AND gate.
I don't want to say it's impossible with just the 6602, but I can't think of a straightforward way to go about it without external hardware (although maybe I can sleep on it and think of something later... how many counters do you have to work with?).
With your current NI Hardware, I think your best bet is to go with an external AND gate. If you're planning on purchasing an X Series card the digital filtering idea is actually not a bad way to go.
I hope this is helpful!
Best Regards,
John Passiak

Using external clock on a 6062E DAQ card

In my application I need to use an external clock (2 MHZ) to sample 10 channels at 40 KHz each. I connected the external clock to PFI_7/Startscan, enabled the ND_IN_CHANNEL_CLOCK_TIMEBASE and ND_IN_SCAN_CLOCK_TIMEBASE using The Select_signal function. If I use only two channels (instead of 10) everything works fine. If I try to increase the number of channels to more than 2 I get a digitized waveform with points missing (one every 2). I tried to decrease the sampling rate to 4 KHz per channel, but the problem persisted. For 2 channels everything is always fine, but for more than 2 I get the same error in the digitization pattern.
The relevant lines of my codes are attached
Thank you for your help
Enrico Gratt
on
Attachments:
Sample_code.pas ‏3 KB

Enrico,
I have a couple of questions. Do you see the same amount of missing data regardless of how many channels (more than 2) you are acquiring? If you use the internal 20 MHz timebase, can you successfully acquire all 10 channels at 40 kHz?
Spencer S.

How do I configure a counter to generate pulses using DAQmx?

How do I configure a counter to generate pulses using DAQmx?
Is says in the DAQmx C reference help
"CtrnInternalOutput—The signal at this internal terminal is where the pulsed or toggled output of the counter appears. The output of a counter pulses or toggles when the counter reaches terminal count. When counting down, the counter reaches terminal count when the count reaches zero. When counting up, the counter reaches terminal count when the counter rolls over. To configure the counter to toggle or generate pulses, use the Export Signal function/VI with Counter Output Event as the signal name."
I've tried this but can't get it to work, I may have the parameters wrong or something. The DAQmxExportSignal() function is very unintuitive to me. Here is my counter config code...
int ret = 0;
ret = DAQmxCreateTask("",&task_);
errorMsg(ret);
if (ret != 0)
throw ret;
// Configure the counter
ret = DAQmxCreateCOPulseChanTicks( task_, "Dev1/ctr0", "", "/Dev1/PFI8", DAQmx_Val_Low, 0, divider, divider );
errorMsg(ret);
ret = DAQmxCfgImplicitTiming( task_, DAQmx_Val_ContSamps, 1000 );
errorMsg(ret);
// Change to pulse mode
ret = DAQmxExportSignal( task_, DAQmx_Val_CounterOutputEvent, "/Dev1/Ctr0InternalOutput" );
errorMsg(ret);
// Start the counter
ret = DAQmxStartTask(task_);
errorMsg(ret);
The above code works fine, in toggle mode, if I just comment out the DAQmxExportSignal() part.
HELP!!!
Stefan

The problem is due to the DAQmxExportSignal call. By default, when you create a counter output pulse train task, the driver will automatically set the output of the counter to toggle when the count for each high ticks and low ticks expire. The driver also automatically routes the signal present at Ctr0InternalOutput terminal (the output of the counter internal to the device) to the Ctr0Out terminal (the I/O pin available externally). Using the line
ret = DAQmxExportSignal( task_, DAQmx_Val_CounterOutputEvent, "/Dev1/Ctr0InternalOutput" );
will tell the driver to tristate the Ctr0Out terminal and not output the signal to the external I/O pin. Using the DAQmxExportSignal function is generally only useful if you want to route the signal to some other terminal internal to the board without having the output show up on the external connector, route the signal to some other external pin other than the default pin, or if you want to have the output show up at multiple locations.
If you want to change the output behavior from toggle to pulse, you need to use the DAQmxSetExportedCtrOutEventOutputBehavior function. However, this is generally only useful if all you care about are edges (not the duty cycle of the pulse train), and you want to generate higher frequency signals. For example, with a 20 MHz timebase as the source of your counter, you can only generate a 5 MHz pulse train by default. This is because the minimum value for the low and high ticks parameter is 2 (20 MHz / 4 = 5 MHz). By changing the output behavior form toggle to pulse, you can generate a pulse train at 10 MHz since the output is now pulsing instead of toggling. However, the width of each pulse is not programmable so you will no longer have a 50% duty cycle signal. I don't remember exactly what the width of each pulse is, but I believe it's in the neighborhood of 50 - 100 nanoseconds in width. I hope this information helps.

How to generate 250 ns pulses at a 200 Hz rate?

Hello,
I am working with the NI PXI 6229.
I will trigger the input sampling at 1kHz.
And I want to create an output at 200Hz, which is in synchronisation with the 1kHz.
This output at a rate of 200Hz, should exist out of 250ns long pulses.
This should be a digital output.
How should I implement this?
Thanks

Hello Boris,
If the precise 250 ns duration is important then you'll have to use both counters to do this.
The first counter will be used to simply divide-down the external signal. You can change the output mode to "pulse" instead of toggle so that it will issue a pulse every N ticks of your external signal. In your case, N would be 5. If you're using LabVIEW then this example shows how to configure your first counter (except you would pulse after 5 ticks instead of 2). The pulse width would be based on the timebase used and is not configurable in pulse mode, so you can't get the 250 ns pulse from this one counter alone. You could alternatively use the default "toggle" mode and just select a number of high and low ticks that add up to 5. Neither of these choices would give the 250 ns pulse you need though.
The 2nd counter will be configured to issue a single 250 ns pulse every time it receives a trigger. The source of the trigger would be the output of the first counter (can be routed internally). This example is a good starting point, 20 ticks of the 80 MHz timebase is equal to 250 ns (you can change the instance of the create channel VI if you prefer to let the driver do this scaling for you).
Best Regards,
John Passiak

Data log rate of Counter Period acquisition

I'm measuring and recording the period of a digital input pulse train (input to NI9421 card on a 'C' series DAQ chassis and recorded via LabVIEW SignalExpress 2009). The 'Counter Period' acquisition step is configured to use '1 Counter' measurement method.
In order to record the data I have to use '1 Sample (On Demand)' Acquisition mode.
When I review the recorded data, how can I determine:
a) the sample frequency of the recorded data points ?
b) the absolute timestamp of any data point ?
The log file has no information regarding the recording frequency, and from my experiments this seems to change based on the measured period of the input.
Any ideas??
Solved!
Go to Solution.

Hi a.yearsley,
The counters on the 1st generation cDAQ chassis (9172) do not support sample-clocked period measurements. I'm assuming you are using this chassis since you mentioned that you have the module in slot 5 or 6.
Your edge count workaround is very similar to the High Frequency 2 counter method. In either case, you specify a time duration and count the edges of your external signal during this time. The 2nd counter is used to generate the gate signal for the specified time duration. Your measurement error with this method is up to 1 period of the external signal, so it is more commonly used with higher frequency signals (I'm not sure what the frequency of your signal is).
The standard 1 counter method counts the number of ticks of an internal timebase (80 MHz) during one period of your input signal. Since the signal itself is what is gating the measurement, the sample is latched into the buffer on the edge of the signal and is not clocked independently. If desired, you could configure Implicit Timing, which would give you a period measured for every edge of the input signal.
Taking the above idea one step further, you could just configure an edge count task with the 80 MHz timebase as the source. Use the external signal as a sample clock. The only difference between this and using the standard period measurement with implicit timing is that the counter is not reset after every sample. This might make it easier to keep track if you want to log a sample every x seconds (i.e. once the total count passes a certain value). You can find the period by subtracting consecutive counts and multiplying by the period of the timebase (12.5 ns). The counter would rollover after about 53.69 seconds, but if you read the count as U32 there won't be any problem with the subtraction (0000 - FFFF = 1 if the numbers are U32).
If you are on a 2nd generation cDAQ chassis (e.g. 9174, 9178, 9188), then you actually do have support for a sample-clocked period measurement. You can choose whether or not to enable averaging. The 9178/9174 user manual has diagrams showing the sample-clocked frequency measurement which is essentially the same thing (the driver inverts the period measurement to obtain frequency). You must guarantee at least 1 edge of your external signal between sample clocks if using this method. The clock can come from a number of sources--I would probably recommend using another counter to generate it.
Best Regards,
John Passiak

6608 80 MHz timebase

Similar Messages

Maybe you are looking for