Counter output jumps when power to encoder is cut

Hello all,
I am using a PXI-6251 DAQ board and a SCB-68 to read, via a LabVIEW DAQmx task, an optical encoder (720 counts / rev.) in radians. The data read from the encoder is nice and smooth while the encoder is running, but when the power to the encoder is cut abruptly, there is a jump in the number of radians read (about two or three). An oscilloscope connected at the SCB terminals shows a voltage spike of unreadable height when the power to the encoder is cut. How might such a spike cause a sudden increase in the number of ticks/degrees/radians read?
Thanks!
Slowpoke
Slowpoke
CLAD (believe it or not!), using LabVIEW 8.5
They don't call me "Slowpoke" for nothin'!

Hello Slowpoke,
Large voltage spikes can result in additional counter measurements. The TTL signal that you are measuring has to adhere to certain requirements. A TTL signal is low between the voltage of 0 to 0.8V and a high for 2 to 5V. Additionally, the maximum rise and fall time of the pulse must be less than 50ns. If this requirements is not met, the counter will give erroneous count values. For M-series cards with the DAQ-STC counter asic, the minimum pulse width has to be 10ns. If the signal does not conform to all these specifics, the count value will be incorrect.
One option you can consider, is if you have a 0-5V signal from your encoder that is high when the power is on and low when the power is cut off. This signal can be wired to the Gate of the PXI-6251. What does your voltage spike look like? Is it one large voltage spike or is there ringing/bounching as it settles?
Regards,
Sandra T.
Applications Engineer | National Instruments

Similar Messages

Counter output 2V when using gate and source at the same time..

I'm using NI TIO-6601.
I connected output of counter_0 to pfi 34 and pfi27 on hardware(CB-68LP).
pfi 34 is used for gate to counter_1 and counter_2.
With this gate, counter_1 and counter_2 generate pulse trains when the gate is in high state.
pfi 27 is used for source to counter_3.
With this source, I'm trying to let counter_3 count event on counter_0.
However, after this connection, the voltage from counter_0 is about 2V measured by Oscilloscope.
Also, counter_3 cannot count the event on counter_0.
Is there any problem on my connection ? or any tips for solving this problem??
Thanks in advance!!
p.s. It works when only two counters are working.
for example, when counter_0 generates pulse tra
in and output is connected to pfi_27, then counter_3 can count the event on counter_0.
Thanks again!

Hello,
Thank you for contacting National Instruments.
This issue may be related to amount of current the output of counter 0 can produce. You may want to try a different method for making these connections. Try routing your counter 0 output on to RTSI line 1. Then use RTSI1 as the gate for counters 1 and 2 and the source for counter 3. This way, you will not need to use two seperate PFI connections.
If you are using Trad. DAQ and LabVIEW you will need to use the Route Signal.vi. If you are using DAQmx, you will need to use the Export Signal.vi
Regards,
Bill B
Applications Engineer
National Instruments

Counter output becomes unsnchronized when gated with an other counter

Dear all
i'm using a PCI-6602 to generate a range of different pulse trains / retriggered pulses. Ctr0 is running at the experiments base frequency (T0) and is configured like this:
Error = DAQmxCreateCOPulseChanTicks(T0TaskHandle, "Dev1/ctr0", "", "20MHzTimebase", DAQmx_Val_Low, 0, T0Low, T0High);
Error = DAQmxCfgImplicitTiming(T0TaskHandle, DAQmx_Val_ContSamps, 0);
A second counter (Ctr2) produces pulses synchronized with T0 but with n times longer period:
Error = DAQmxCreateCOPulseChanTicks(BlockTaskHandle, "Dev1/ctr2", "", "20MHzTimebase", DAQmx_Val_High, 0, BlockLow, BlockHigh);
Error = DAQmxCfgImplicitTiming(BlockTaskHandle, DAQmx_Val_ContSamps, 0);
Error = DAQmxCfgDigEdgeStartTrig(BlockTaskHandle, "/Dev1/Ctr0InternalOutput", DAQmx_Val_Rising);
A third counter (Ctr3) produces retriggered pulses from Ctr2 that will serve as a gate for the 4th counter output:
Error = DAQmxCreateCOPulseChanTicks(BlockEnableTaskHandle, "Dev1/ctr3", "", "20MHzTimebase", DAQmx_Val_Low, 0, BlockEnableLow, BlockEnableHigh);
Error = DAQmxCfgDigEdgeStartTrig(BlockEnableTaskHandle, "/Dev1/Ctr2InternalOutput", DAQmx_Val_Rising);
Error = DAQmxCfgImplicitTiming(BlockEnableTaskHandle, DAQmx_Val_FiniteSamps, 1);
Error = DAQmxSetStartTrigRetriggerable(BlockEnableTaskHandle, true);
Ctr4 should now output pulses at the frequency of Ctr0 but only when Ctr3Out is high. I tried along the lines of:
Error = DAQmxCreateCOPulseChanTicks(TriggerTaskHandle, "Dev1/ctr4", "", "20MHzTimebase", DAQmx_Val_Low, 0, TriggerLow, TriggerHigh);
Error = DAQmxCfgImplicitTiming(TriggerTaskHandle, DAQmx_Val_ContSamps, 0);
Error = DAQmxSetPauseTrigType(TriggerTaskHandle, DAQmx_Val_DigLvl);
Error = DAQmxSetDigLvlPauseTrigWhen(TriggerTaskHandle, DAQmx_Val_Low);
Error = DAQmxSetDigLvlPauseTrigSrc(TriggerTaskHandle, "/Dev1/Ctr3InternalOutput");
This works in terms of gating, but the gated pulses are no longer synchronized with the Ctr0 (they "move" through the gate when looking at it on an oscilloscope).
DAQmxCfgDigEdgeStartTrig does not work for Ctr4 as it is not possible to use start and pause in the same task (at least that's what the error message said).
I tried to synchronize using:
Error = DAQmxSetArmStartTrigType(TriggerTaskHandle, DAQmx_Val_DigEdge);
Error = DAQmxSetDigEdgeArmStartTrigSrc(TriggerTaskHandle, "/Dev1/Ctr0InternalOutput");
Error = DAQmxSetDigEdgeArmStartTrigEdge(TriggerTaskHandle, DAQmx_Val_Rising);
which works if i uncomment the three PauseTrig lines (no more drifting pulses, but no gating either). Using it all together produces no errors but the gated pulses still walk through the gating window.
Any help is deeply appreciated
Best regards
Christian

Hello Wolfgang
thank you for your reply. I finally managed to get the 6602 to do what i want it to. The key was to use
Error = DAQmxSetDigEdgeArmStartTrigSrc(TriggerTaskHandle, "/Dev1/Ctr2InternalOutput");
instead of
Error = DAQmxSetDigEdgeArmStartTrigSrc(TriggerTaskHandle, "/Dev1/Ctr0InternalOutput");
and to make sure that Ctr4s task was started after the tasks of Ctr0 and Ctr2.
Now Counter 4 is pulsing at the frequency of Ctr0 (even with selectable delay and pulse width) but only when Ctr3Out is high without the need for an external AND gate or other hardware.
Best regards
Christian

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

Pause the counter output in DAQmx

Hi~
I used two counters output on PCI-6602 card in LV7.1 to generate a PWM to control the velocity of two motors that control the position of mechanism.(Encoder was set on the motor.)
When I set the same duty cycle in two counters, the position of two mechanisms were different(Two mechanisms were the same),that means one velocity of motor was fast, the other was slow.
May I pause the counter output of the fast motor to wait the slow motor??
====================
●LV Version：LabVIEW7.1
●OS：WindowsXP(SP1)
●Hardware：PCI-7344, PCI-6602, PCMCIA 6024E

Assuming you're using DAQmx, you can set up a Pause Trigger for each of the counters. (A similar function can be done in traditional NI-DAQ too). You could, for example, configure 2 different digital bits to be used to pause the 2 PWM counters independently. The way 'Pause Triggering' works is that the counter's pulsetrain only goes to the output pin when the pause trigger signal is in the correct logic state. This can be set to be low or high by programming.
You may also want to characterize the speed difference of your actuators, and give them correspondingly proportional PWM duty cycles. That would do a better job of keeping them in sync throughout the motion.
A feedback signal would give you even better options for control.
-Kevin P.

Movie playback lags SMPTE counter, self-corrects when advance by frame

Recently playback of my QT movies has begun to lag the SMPTE counter by about 15 frames. At any given point when playback is stopped, the timecode burn in the QT reads appx 15 frame behind the SMPTE counter. Curiously, when I advance by 1 frame (using key command), or advance by measure, or jump to marker, pickup clock of region, etc., the video instantly snaps forward to the exact SMTPE code in the counter. Lag only occurs during playback. This actually makes the problem worse, because I can't merely change the start time of the movie to compensate.
I've been using Logic for years without any sync problems. The problem is not file specific — the same lag occurs in Logic sessions I did just weeks ago with no sync problem.
Any thoughts or insights much appreciated.

Solved it – hope this helps someone else.
By moving (and saving elsewhere) my Logic preferences, I narrowed it down a preferences problem. Turned out to be my setting for plugin delay compensation – not an early suspect, given that it is for AUDIO. I had it set to "All", in order to eliminate the several frame shift rendered to my bounces when using the AdaptiveLimiter. After setting it to "audio tracks and instruments", the video lag ceased.
It will difficult to remember to change that setting every time I bounce a final mix, but at least the problem is solved.

Counter Output/Counter Input PXI Signals Behaving Erratically

Question for all your LabVIEW guru's out there,
I am running a frequency loopback test using the NI PXI 6229 MIO DAQ card. I am generating a "Counter Output" pulse train signal which feeds through my device under test and then back out of my device under test and back into the PXI 6229 for a "Counter Input" frequency measurement. Both the "Counter Output" and the "Counter Input" are assigned different PFI lines using DAQmx in LabVIEW.
I have 4 lines to test on my DUT. All four lines run this same frequency measurement but with different PFI lines on the PXI 6229. Each line is test independently.
This is my setup for the 4 lines:
Path 1: P2.0 (Counter Output - Pulse Train) -> DUT (Device Under Test) -> P2.1 (Counter Input - Frequency Measurement)
Path 2: P2.2 (Counter Output - Pulse Train) -> DUT (Device Under Test) -> P2.3 (Counter Input - Frequency Measurement)
Path 3: P2.4 (Counter Output - Pulse Train) -> DUT (Device Under Test) -> P2.5 (Counter Input - Frequency Measurement)
Path 4: P2.6 (Counter Output - Pulse Train) -> DUT (Device Under Test) -> P2.7 (Counter Input - Frequency Measurement)
where:
P2.0 = PFI8
P2.1 = PFI9
P2.2 = PFI10
P2.3 = PFI11
P2.4 = PFI12
P2.5 = PFI13
P2.6 = PFI14
P2.7 = PFI15
I have a LabVIEW VI which generates the "Counter Output" and reads the "Counter Input" frequency. I am seeing weird behavior from the PXI 6229 card. I can test "Path 1" and "Path 2" and the frequency I read is what I generated. No issue there. However, when I test "Path 3" and "Path 4" the frequency measurement is erratic. The readings are two different frequencies repeated over and over again and none of those frequencies are the expected frequency which was generated out of the "Counter Output." If I reset the card, and start by testing "Path 3" and "Path 4" the frequency readings are correct and the erratic behavior is gone. However, when I try to then test "Path 2" and "Path 1" now those lines have the erratic frequency issue. I can continue resetting the card and see same issue. The PFI lines that I test first will always pass.
To summarize:
Steps Taken:
1. Test Path 1 = SUCCESS
2. Test Path 2 = SUCCESS
3. Test Path 3 = Erratic Frequency (Two Frequencies repeated over and over again in my frequency results array)
4. Test Path 4 = Erratic Frequency (Two Frequencies repeated over and over again in my frequency results array)
5. Reset the PXI 6229 Card
6. Test Path 3 = SUCCESS
7. Test Path 4 = SUCCESS
8. Test Path 3 = Erratic Frequency (Two Frequencies repeated over and over again in my frequency results array)
9. Test Path 4 = Erratic Frequency (Two Frequencies repeated over and over again in my frequency results array)
I am wondering if Port 2 (P2.0-P2.7) on the 6229 card has certain dependecies and this is why I am seeing issues. I am trying to get around this issue so that I don't have to always reset the card.
Are P2.0-P2.3 (PFI8-PFI11) and P2.4-P2.7 (PFI12-PFI15) treated differently or require different setup? How do I resolve this issue?
Thanks so much!

I have a theory...
The DAQ card follows a policy called "lazy uncommit" wherein the terminal used for the output will continue to be connected to the counter even after the task has completed (until the terminal is needed for something else). So as you run more tests, the counter output will end up driving more lines. This behavior should be easy enough to confirm.
As the DAQ card drives more lines, I'd imagine this affects the actual signal. You could scope it to check, but it sounds like either the rise/fall times are becoming longer or some extra noise is being introduced on the line.
The readings are two different frequencies repeated over and over again and none of those frequencies are the expected frequency which was generated out of the "Counter Output."
This implies you are picking up an extra edge during transitions--this isn't too uncommon if the signal is noisy since there is no built-in hysteresis on the DAQ card. I would expect the measured frequencies to have periods that sum to either the full period or the semi-period of your actual signal (depending on how many duplicate edges are detected).
Suggestions are as follows:
To stop the DAQ card from driving multiple PFI lines, it would probably be easiest to just programmatically reset the device in between your tests (using DAQmx Reset Device). If you can't reset the device (e.g. because you are running some other task that can't be interrupted) then you can instead configure a dummy task that uses the PFI line in question as an input.
To stop the DAQ card from picking up multiple edges during transitions, you should configure a digital filter on the input terminals. If you reset the device it sounds like this might not be necessary... it's up to you if you want to configure this or not.
Best Regards,
John Passiak

How to disable (turn off) a counter output

I have a similar question up on the the board but I thought I would ask it in another way to make it simple and straightforward.
Can an E-series counter output be disabled (and enabled) quickly through some software command? When I say " disabled" I mean switched off to a TTL low state. I have tried both the "disable" counter control command and gating the counter with a TTL signal. Both methods leave the output pin in whatever state the output happens to be in at the time of the command or gating. I need a disable function where "disabled" automatically sets an OFF or LOW on the output. I am using this to generate a pulse train where the pulse train switches off at certain times, and I cannot have the output remain high at these times.
I am using traditional DAQ but if there is a method in DAQmx that works I'd be willing to try it...

Have you tried using the following vi with a reset command (search in help, it works with the E series counters)
Counter Control
This VI controls groups of counters. Control operations include starting, stopping, and setting the state of active acquisitions. This VI works with DAQ-STC and NI-TIO-based devices.
Control code 1 (reset) reinitializes the counter back to the default settings.
~~~~~~~~~~~~~~~~~~~~~~~~~~
"It’s the questions that drive us.”
~~~~~~~~~~~~~~~~~~~~~~~~~~

Display counter output on graph

I have two counters generating continuous digial pulse trains from my PCI 6010, and I'm trying to display the output on a graph. I've got the output of one counter connected to an AI line that leads to a waveform graph, but I can't get anything on the graph. I've measured the output via external means, so I know the counters are generating the appropriate pulses.
Eventually I'd like to have some sort of indicator for each counter that indicates whether the counter is in the 'on' or 'off' state, but I figured getting the counter outputs to diplay on a graph would be a good first step.
My VI is below; the display part that isn't working is at the bottom of the case structure.
Thanks.

Once your code goes into the inner while loop your graph will never be updated since it will only execute one time. In order to update the graph continually you will need a parallel which handles the graph updates. A good way to pass data between the parallel tasks is a queue.
Mark Yedinak
"Does anyone know where the love of God goes when the waves turn the minutes to hours?"
Wreck of the Edmund Fitzgerald - Gordon Lightfoot

Please help with C code to synchronize counter output to analog input

Hi All,
I am using NI DAQ USB-6353 with text-based C code to control it. I would like to send a continuous pulse train from the DAQ to pulse a power supply, which then activates an electron beam producing current to be read by the analog input port of the same DAQ. I would like to keep only the analog samples during the pulse peak and samples of a couple pulse widths right after. I am successfully to generate a pulse train using the sampled clock from a counter output channel, but fail to use the same clock to synchronize the pulse train with the analog input. DAQmxReadAnalogF64 is not called by the static function EveryNCallback set for the analog input task. Am I doing something wrong with the following codes? It would be great if it turns out only I am using the wrong sampled clock name of the counter ("dev1/PFI8") for the analog input. Or is something more fundamental that a counter cannot be sync. with an analog input?
Would someone be able to send me a link to an example in C or C++ or visual basic showing how to synchronize a buffered sample clocked digital pulse train from a counter output channel to an analog input? To simplify the post, the below codes do not include the static functions EveryNCallback and DoneCallBack, but I can send them if needed.
Many thanks in advance for your help,
Thuc Bui
//setting operation parameters
double initDelay = 0.0, freq = 10;
double dutyCycle = 0.0001;           //thus pulse width is 10 microsec
unsigned highTicks = 4;   //per period
unsigned numSamplesPerPeriod = highTicks / dutyCycle; //40000 samples/period
unsigned lowTicks = numSamplesPerPeriod - highTicks;      //per period
unsigned sampleRate = 2*numSamplesPerPeriod*freq;       //800000 samples/s
//create counter
TaskHandle counterTask;
int errCode = DAQmxCreateTask("", & counterTask);
errCode = DAQmxCreateCOPulseChanFreq(counterTask, "dev1/ctr0", "",
                                 DAQmx_Val_Hz, DAQmx_Val_Low,
                                 initDelay, freq, dutyCycle);
errCode = DAQmxCfgSampClkTiming(counterTask, "dev1/PFI8", sampleRate, DAQmx_Val_Rising,
                           DAQmx_Val_ContSamp, numSamplesPerPeriod);
//create analog input
TaskHandle aiTask;
double minVolt = 0.0, maxVolt = 1.0;
errCode = DAQmxCreateAIVoltageChan(aiTask, "dev1/ai0", "", DAQmx_Val_Diff,
                                 minVolt, maxVolt, DAQmx_Val_Volts, "");
unsigned bufferSize = 10* numSamplesPerPeriod;
errCode = DAQmxSetBufInputBufSize(aiTask, bufferSize);
errCode = DAQmxCfgSampClkTiming(aiTask, "dev1/PFI8", sampleRate, DAQmx_Val_Rising, DAQmx_Val_ContSamp, numSamplesPerPeriod);
errCode = DAQmxRegisterEveryNSamplesEvent(aiTask, DAQmx_Val_Acquired_Into_Buffer,
                                        numSamplesPerPeriod, 0, EveryNCallback, 0);
errCode = DAQmxRegisterDoneEvent(aiTask, 0, DoneCallBack, 0)
//start aiTask first
errCode = DAQmxStartTask(aiTask);
//then counterTask
errCode = DAQmxStartTask(counterTask);

Hi Xavier,
Thank you very much for getting back to me. I really appreciate it. I followed your advice with the option 2 and simplified my code by using one of the NI C example templates to generate the below codes (also attached). I was able to see the pulses generated with an oscilloscope, and on the same oscilloscope I could see the ouput pulses of the electron beam probe. Unfortunately, the below code via DAQmxReadAnalogF64 reports of no data read from the probe and finally times out. Below is the error message given by this function. I did check the connection of the analog input wires to make sure they were connected to pin 1 (A0+) and 2 (A0-) because I was using the terminal configuration DAQmx_Val_Diff. Do you see any obvious errors I have made in my codes?
Thanks a lot for your help,
Thuc Bui
Task started, waiting for trigger...
Acquired 0 analog samples DAQmx Error: Some or all of the samples requested have not yet been acquired.
To wait for the samples to become available use a longer read timeout or read later in your program. To make the samples available sooner, increase the sample rate. If your task uses a start trigger, make sure that your start trigger is configured correctly. It is also possible that you configured the task for external timing, and no clock was supplied. If this is the case, supply an external clock.
Property: DAQmx_Read_RelativeTo
Corresponding Value: DAQmx_Val_CurrReadPos
Property: DAQmx_Read_Offset
Corresponding Value: 0
Task Name: _unnamedTask<1>
Status Code: -200284
End of program, press Enter key to quit
********************** C Code **************************************************
#include <stdio.h>
#include "NIDAQmx.h"
#include <math.h>
#define DAQmxErrChk(functionCall) { if( DAQmxFailed(error=(functionCall)) ) { goto Error; } }
int main(void) {
int32 error = 0;
char errBuff[2048]={'\0'};
TaskHandle taskHandleDig=0;
TaskHandle taskHandleAna=0;
double  timeout=10;
double minVol = -1.0, maxVol = 1.0;
double initDelay = 0.0;
double freq = 10.0;
double pulseWidth = 1.0e-5; //10us
double dutyCycle = pulseWidth * freq;
unsigned hiTicks = 4;
double sampleRate = hiTicks/pulseWidth; //samples/s
unsigned lowTicks = ceil(sampleRate/freq) - hiTicks;
unsigned nSpPeriod = hiTicks + lowTicks;
unsigned numPulses = 1;
unsigned nSpCh = numPulses*nSpPeriod;
double sampleRate2 = ceil(2.0*sampleRate);
unsigned sampleMode = DAQmx_Val_FiniteSamps;
/*********************************************/ /*/ DAQmx Configure Code /*********************************************/
DAQmxErrChk(DAQmxCreateTask("", &taskHandleDig)); DAQmxErrChk(DAQmxCreateTask("", &taskHandleAna));
DAQmxErrChk(DAQmxCreateAIVoltageChan(taskHandleAna, "Dev2/ai0", "", DAQmx_Val_Diff, minVol, maxVol, DAQmx_Val_Volts, ""));
DAQmxErrChk(DAQmxCfgSampClkTiming(taskHandleAna, "/Dev2/Ctr0InternalOutput", sampleRate2, DAQmx_Val_Rising, sampleMode, nSpCh));
DAQmxErrChk(DAQmxCreateCOPulseChanFreq(taskHandleDig, "Dev2/ctr0", "", DAQmx_Val_Hz, DAQmx_Val_Low, initDelay, freq, dutyCycle));
DAQmxErrChk(DAQmxCfgSampClkTiming(taskHandleDig, "/Dev2/PFI12", sampleRate2, DAQmx_Val_Rising, sampleMode, nSpCh));
unsigned bufferSize = nSpCh;
DAQmxErrChk(DAQmxSetBufInputBufSize(taskHandleAna, bufferSize));
DAQmxErrChk(DAQmxSetBufOutputBufSize(taskHandleDig, bufferSize));
/*********************************************/ /*/ DAQmx Write Code /*********************************************/
DAQmxErrChk(DAQmxWriteCtrTicksScalar(taskHandleDig, 0, timeout, hiTicks, lowTicks, NULL));
/*********************************************/ /*/ DAQmx Start Code /*********************************************/
DAQmxErrChk(DAQmxStartTask(taskHandleAna)); DAQmxErrChk(DAQmxStartTask(taskHandleDig));
printf("Task started, waiting for trigger...\n");
/*********************************************/ /*/ DAQmx Read Code /*********************************************/
double* dataAna = new double[nSpCh];
int32 numReadAna = 0;
int errCode = DAQmxReadAnalogF64(taskHandleAna, -1, timeout, DAQmx_Val_GroupByChannel, dataAna, nSpCh, &numReadAna, NULL);
printf("Acquired %d analog samples\n",numReadAna);
if (numReadAna) {
    unsigned nPts = (numReadAna < hiTicks)? numReadAna : hiTicks;
   for (unsigned n = 0; n < nPts; ++n) {
         printf("%6.3f ", dataAna[n]);
    printf("\n");
delete [] dataAna;
DAQmxErrChk(errCode);
Error:
if( DAQmxFailed(error) )   DAQmxGetExtendedErrorInfo(errBuff,2048);
if( taskHandleDig!=0 && taskHandleAna!=0 ) {
/*********************************************/   /*/ DAQmx Stop Code   /*********************************************/
    DAQmxStopTask(taskHandleDig);
    DAQmxClearTask(taskHandleDig);
    DAQmxStopTask(taskHandleAna);
    DAQmxClearTask(taskHandleAna);
if( DAQmxFailed(error) )   printf("DAQmx Error: %s\n",errBuff);
printf("End of program, press Enter key to quit\n");
getchar();
return 0;
Attachments:
Correlated DIO AI_Sample_Clock Dig Start.c ‏6 KB

"loopback" counter output without wiring

Cross posted from another forum for more visibility:
Basically, I have a counter output being generated on a trigger line. It's just a pulse at defined intervals of 1 hz. The problem is, the card that is generating the output needs the trigger itself, but if it is using the trigger line to output the trigger itself, it can't read it. I know I can get around this with a timing and synch card, and possibly with external wiring, but is there any way to do this all in the backplane?
In summary, can I have a AO card generating a counter output on a trigger line use that output as a trigger for itself in some way, without extra wiring or a 6672 card?
CLA, LabVIEW Versions 2010-2013

Jeff·Þ·Bohrer wrote:
Greg,
What are you really triing to do? your post is a bit more cryptic than usual.
My instinct says "a single board RIO" would do the trick. but, that's a lot of capability to throw at a simple PFIO line. What did you get yourself into this time?
NO NO NO. No sbRIO. Did NI pay you to help market now?!
All I want to do is have a digital pulse, which I can use as a start trigger for ALL my AI and AO. Some tasks stop and restart while others keep running continuously. When the select tasks restart, they need to sync back up with the continuously running tasks, and they do so by using this start trigger again. This is not a clock sync, think of it like a "wait until next ms multiple." I resolve this by having a digital pulse happening every "x millseconds" which I use as my start trigger. If a task restarts, it will again wait for this pulse.
The problem is, if I am generating this trigger on PXI1Slot12/PXI_trig0, I cannot also trigger off of this trigger line in slot 12.
CLA, LabVIEW Versions 2010-2013

How to use counter output pulses to trigger analog input?

Hello all,
I hope the kind people using this forum can help me, a lowly beginner LV programmer! I have been attempting to create a VI that produces a user defined number of TTL pulses, separated by every n seconds. Each TTL would be outputted to a stimulator, which in turn generates its own TTL. Using the stimulator-generated TTL, I would like to trigger finite analog data acquisition (e.g. for every TTL, trigger the collection of a data sweep that contains 4000 samples (collected at 4000 Hz), with 1000 samples collected pre-trigger. I would like to also be able to see each data sweep as it is triggered on a chart. As I understand things (lots of online/book/forum reading), I should be using the counter output to generate my TTL pulses, and syncing each counter produced TTL with analog input, as well as using a reference trigger. Also, the AI part should be started first, so that I don' t miss any counter outputs. If it matters, I also need to use one of the AI channels to acquire the TTL, so I can see my stimulator-induced responses to the stimulator in time.
I am able to generate the TTL pulses from the counter output, but I am having a problem with the AI part. I am unsure how to sync the counter output with AI. Also, since I need to acquire pre-trigger samples, I would be needing to acquire samples continuously, but when I set 'continuous samples' on daqmx timing, the VI doesn't work (hence why's its set to 'finite samples').
I hope someone out there can help, as I have been at this for what seems ages, with limited success. I am using a USB-6259 and LabView v8.2. Thanks!
Attachments:
RC001 v_1.vi ‏49 KB

Hello,
Due to the fact that analog tasks themselves are not retriggerable, a
pulse train produced by a counter is always used as the sample clock
for the analog input task in order to recreate a retriggerable effect
for analog input. This can be done by creating a finite pulse train set
to retriggerable using the DAQmx Trigger Property Node, or the pulse
train could be continuous and just be gated by another signal. Neither
of these methods can be properly applied in hardware to create a
retriggerable reference trigger. You can however implement something
similar in software by just stopping and restarting your reference
triggered analog input task within a loop. There will be some delay
between when the task is stopped and restarted, as these events require
software intervention, but if there is enough time between when each
trigger signal is generated, there should not be any noticeable delay
or missed samples.
I have attached an example of this!
Mark B
===If this fixes your problem, mark as solution!===
Attachments:
RC001 v_1mod.vi ‏25 KB

Setting the counter output mastertimebase divider?

Hello
I want to output single short pulses with varying pauses. My MuFu DAQ card has 20 MHz master clock rate and 24 bit counter (Good ol'6052E). When I try to output 1 µs with a pause duration of more than 839 ms, I get an error due to mismatch of clockrate and counter bit size with short and long duration. This is explained in great detail in the corresponding help:
2/ counter clock rate <= X <= 2^24 / counter clock rate. with counter clock rate = master clock rate / divider
0.1 µs <= X <= 16777215 / 20Mhz = 839 ms
I could strech my limits by manually setting the CO.CounterTimebaseMasterTimebaseDivider to 10. But I've searched all property nodes I could find but I have not found this property.
Does anyone know where it is hidden, and to which values it can be set?
Thank you
Michael

Hi Michael,
Unfortunately that property doesn't exist. There are a few "Divisor" properties available for other subsystems (e.g. see Analog Input timing block diagram below).
However, you'll notice in the above diagram that the valid divisors of the master timebase are only 1 or 200 (which then gives the AI Sample Clock Timebase). You can get similar behavior on the counter by specifying to use the 20 MHz timebase or 100 kHz timebase for your source. However, using the 100 kHz (1/10 us) timebase is going to prevent you from properly generating the narrow 1 us pulses that you require.
So, you can use 20 MHz or 100 kHz without any additional resources, but 100 kHz wouldn't allow you to have a 1 us pulse, and 20 MHz won't let you have a high or low time of greater than ~839 ms. You could generate frequencies in between these to use as the counter timebase (either use the frequency output or use the second counter to generate the desired frequency, or perhaps configure a dummy analog task) but of course there would always be a tradeoff between the resolution of the pulse and the maximum time between pulses.
If you do have the 2nd counter available, here is my suggestion to get the best of both worlds:
1. Configure a counter output to generate a pulse every N seconds (I suggest configuring the output to generate at 1/N frequency at 50% duty cycle). When you configure this counter, DAQmx will choose an appropriate timebase for you. When N is less than ~1.67 seconds, DAQmx will use the 20 MHz timebase (since both the high and low time would be under the 839 ms). When N is > 1.67 seconds but below ~335 seconds, DAQmx will use the 100 kHz timebase. If you intend on modifying the rate of the output (to something above 1.67 seconds) after the task has started you would need to make sure to specify to use the 100 kHz timebase rather than relying on the DAQmx default. You can't use a built-in timebase if you want to generate a delay greater than 335 seconds, but if you wanted to you could handle this case by checking for it and configuring the frequency output to generate an even lower timebase.
2. To generate the actual output signal, configure a retriggerable single pulse generation to be triggered off of the signal generated above. This signal will be based off of the 20 MHz timebase (assuming you configure a pulse width less than ~839 ms) and so will give you a good resolution on the available pulse widths that you can generate.
In summary, doing this would let you decouple the resolution of your generated pulse width from the resolution of the delay between the pulses. The downside is that it uses two counters.
The other option which I previously mentioned (and what you were asking about) would be to find a timebase that meets the two requirements: 1) fast enough to generate a narrow pulse and 2) slow enough to not roll-over between pulses. You have 100 kHz and 20 MHz available to you, but you can generate intermediate frequencies using the frequency output. If you plan on using a counter to generate the timebase instead, you should consider the other option which decouples the two counters.
Of course, using a device with a higher counter resolution (most newer DAQ devices use 32-bit counters) would probably also resolve your issue depending on the full range of delays that you need. The downside here is the cost of new hardware.
Best Regards,
John Passiak

Counter Output

Hello
I am using DAQ PCI 6221 card for analog inputs and outputs, I am using both the counter outputs for controlling temperature, by putting heaters On and Off through the digital pulse train I am getting from counter outputs.
But I am having a problem with the counters that even if I change the Low time and High Time the pulse I get just dont changes accordingly,
changes timing effects from next time when I run the VI, I am attaching the VIs(CTR1.vi and CTR0.vi are similar just change the channel name) involved in this, first I am acquiring the temperature and then comparing it with low and high limits and taking an action whether to On or Off heaters.
High Time and Low time are required because as soon as I reach near to set temperature I increase the Low time and vice versa.
Could anybody please tell me where I am wrong??
Attachments:
Show Alarm SV.vi ‏14 KB
CTR1.vi ‏37 KB
Dig Pulses2.vi ‏117 KB

Are you trying to change these values once the task has started running? Consult this KB for information on how to do to this:
"Why Can't I Change the Duty Cycle on My Continuous Pulse Train?"
To summarize, you'll need to use DAQmx channel property nodes to set the pulse width and frequency.
Elijah Kerry
Senior Product Manager, LabVIEW
Follow my Software Engineering for LabVIEW Blog

Counter Output Pin on PCI-6229

I am using NI-DAQmx 7.3 C API with (among others) a PCI-6229.
I have used DAQmxSetCOPulseTerm() to connect a counter output to a terminal other than the default. It seems to work- the output pulses do, in fact, appear at PFI 6 (the terminal I'm using for testing). But the pulses continue to appear at the default output pin as well.
Is that expected?
In order to reverse the situation, I used DAQmxResetCOPulseTerm() just before calling DAQmxClearTask(). The function returns zero, but if I subsequently make a new task to do pulse output from the same counter, pulses appear at both PFI 6 and at the default pin.
Am I missing something?
John Weeks
WaveMetrics, Inc.
Phone (503) 620-3001
Fax (503) 620-6754
www.wavemetrics.com

Salvador Santolucito wrote:
Hi John,
I would suggest using the DAQmxTristateOutputTerminal. I have tried what you are doing in LabVIEW and I'm seeing the exact same results. When I set the default pin to tristate, the counter output does not show up on it.
-Sal
Thanks for trying it and confirming what I saw, and thanks for the pointer to DAQmxTristateOutputTerminal.
John Weeks
WaveMetrics, Inc.
Phone (503) 620-3001
Fax (503) 620-6754
www.wavemetrics.com

Counter output jumps when power to encoder is cut

Similar Messages

Maybe you are looking for