can't run example of DigPulseTrain-Cont-Buff-ExtClk

[skuo1008]

Hi all,

I was trying to run NI DAQmx example of "DigPulseTrain-Cont-Buff-ExtClk", but there is an error generated once the external clock is supplied at frequency of 1 Hz as specified in the example. Error message as the following and I am using x-series PCI-e:

Sample Clock pulse occurred before a pulse could be generated using the previous pulse specification. Use a Sample Clock that is slower than the pulse train you want to generate.
Task Name: _unnamedTask<0>

Status Code: -201318

Any help would be highly appreciated.

[Kevin_Price]

I don't see that specific example by name in my 2016 install, can you post the code?

The way changing pulse specs get dealt with is that there's some kind of preload/latching/timing mechanism where the ability to bring in new & different pulse specs is only "activated" by the completion of the previously loaded pulse specs.   Thus if you try to load up new specs before the previous ones were able to complete, you get an error like the one you saw.   A similar error is thrown in non-buffered mode when trying to change pulse specs on-the-fly too rapidly.

There's a similar functional example in 2016 under a different name.  In it, there are 2 pulse specs defined.  The first has high and low times of 1 sec, the second has high and low times of 0.5 sec.   To run from an external 1 Hz clock, you'll need the pulse specs to add up to just under 1 sec maximum.  (The counter's internal timebase won't exactly match the external clock so you need to allow a little bit of cushion in the timing specs.)

Try keeping the sum of high and low times to 0.99 sec or less if your example sounds similar.

-Kevin P

[skuo1008]

Copy code as the following:

int error=0;
TaskHandle taskHandle=0;
int32 i;
float64 dataFreq[1000],dataDC[1000],dutyStep;
char errBuff[2048]={'\0'};

// Generating data for duty cycle from 0.50 to 0.80 in 1000 steps
dutyStep = (DUTY_MAX-DUTY_MIN)/1000;
for(i=0;i<1000;++i) {
dataFreq[i] = 1000.0;
dataDC[i] = DUTY_MIN + dutyStep*i;
}

/*********************************************/
// DAQmx Configure Code
/*********************************************/
DAQmxErrChk (DAQmxCreateTask("",&taskHandle));
DAQmxErrChk (DAQmxCreateCOPulseChanFreq(taskHandle,"Dev1/ctr0","",DAQmx_Val_Hz,DAQmx_Val_Low,0.0,1.00,0.50));
DAQmxErrChk (DAQmxCfgSampClkTiming(taskHandle,"/Dev1/PFI0",200,DAQmx_Val_Rising,DAQmx_Val_ContSamps,1000));
DAQmxErrChk (DAQmxWriteCtrFreq(taskHandle,1000,0,10.0,DAQmx_Val_GroupByChannel,dataFreq,dataDC,NULL,NULL));

Can we estimate how long it will be for preload/latching/timing? I am planning to modify above to generate 2MHz pulses out of external pulse with frequency near 1MHz, but I wonder the phase delay among triggers would be too much to make it a non-practical method. I've got PCI-e 63xx here.

[Kevin_Price]

1. I program LabVIEW so I don't know details of the text API.  I generally follow what you're doing, but can't comment on specific function arguments.

2. I've not used the buffered pulse generation mode with a explicit external sample clock.  Frankly, I hadn't known it was available.  I've made assumptions about how I *expect* it would work -- each sample clock edge would cause the task to advance to the next pulse specs in the buffer.   If the sample clock is faster than the pulse specs, you'd get the error you reported.  If much slower, that would be fine.  That's my working theory for the sake of discussion.

3. Do you really have a system or process that makes this kind of extreme fine tuning on duty cycle meaningful?   Each increment is a duty cycle change of 0.0003.

   At 1000 Hz pulses as posted, that's 300 nanosec per 1 millisec period.  At your proposed 2 MHz pulses, that's 150 picosec per 500 microsec period.  That's orders of magnitude more resolution than your board will be capable of (10 nanosec nominal timing resolution.)

   I don't have solid info on the nature of preload/latch timing for new pulse specs.  I doubt it's *less* than 10-20 nanosec (1-2 cycles of the 100 MHz timebase) or more than 100's of nanosec.  At high proposed sample rates such as 1 MHz, you'll also need to consider possible limitations due to the rate that pulse specs buffered in system memory can be transferred over to the board.

   Overall I'd suggest you take a step back, assess what you're doing and why, and make sure that you're coding and troubleshooting toward something that's both feasible to do and which makes a meaningful difference.  You seem to be attempting to push some limits.  I'd advise struggling through that only if it's likely to be worthwhile.

-Kevin P

[skuo1008]

I was searching around the feasible ways to carry out my project and came through this example comes with NI package. I just don't understand why NI provide some examples actually not working. 

I am not going to change duty cycle but I do want to generate doubled rate of pulses out of external supplied 1MHz pulses. I started with 2 Hz pulse generation out of provided 1 Hz pulses as I was playing with the example with fixed duty cycle of 0.5, the same error message shows up even I make external pulses slower than 1 Hz. I have no idea how to make it work.

[Kevin_Price]

I'm not sure what to suggest next b/c I still don't have a clear idea what's really important for your app.

1. Which timing edge(s) matter from the incoming pulses (presumably connected to PFI0)?  Rising?  Falling?  Both?
2. Which edge(s) of the output pulses need precise timing placement relative to the incoming pulses?
3. Which of the following is more important?
   • generating output pulses at double the frequency of the incoming pulses, whatever the freq may be (up to 1 MHz)
   • generating output pulses at 2 MHz that have a controlled timing relationship to the incoming pulse edge(s), whatever the freq may be (up to 1 MHz)

Generally, what's the meaning of the input pulses?  What are they coming from?  Why do you want to double their rate?  What are your output pulses doing in your system?

I'm trying to offer help, but I first need to be able to clearly distinguish the must-haves from the nice-to-haves from the don't cares.

-Kevin P

[skuo1008]

Thanks for your feedback. Please take a look at the following:

1. Which timing edge(s) matter from the incoming pulses (presumably connected to PFI0)?  Rising edge.
2. Which edge(s) of the output pulses need precise timing placement relative to the incoming pulses? Rising edge.
3. Which of the following is more important? generating output pulses at 2 MHz that have a controlled timing relationship to the incoming pulse edge(s), whatever the freq may be (up to 1 MHz)

All I want to do is to have the (nearly) doubled pulses in sync with given pulses at the rising edge and that's all I care. Is it possible? Thanks.

[Kevin_Price · Accepted solution]

If you want to double the freq of an incoming square wave:

- configure a DI task using "change detection" as the sample timing type

- use the "export signal" function to route the internal "change detect pulse" signal out to a PFI pin

Your X-series device will need to be spec'ed to handle 2 MHz of digital changes (two transitions per cycle of the 1 MHz signal)

   This method will simply emit brief pulses immediately following every transition of the input signal.  If the input signal is square (i.e. 50% duty cycle), you'll get a frequency doubling effect.  Your output pulses will be nowhere near square with a very small duty cycle.

If you want to generate pulses at a fixed 2 MHz regardless of input freq:

- configure a continuous pulse train with low time = initial delay = 20 nanosec (the minimum allowed) and high time = 480 nanosec

- set the task to be start triggered off the rising edge of PFI0

   This method will generate a fixed 2 MHz pulse train with rising edges offset from PFI0 by ~20 nanosec initially.  If the input signal varies, the output pulses will not adjust or correct.

If you want to generate at 2 MHz while staying synced with a variable freq input signal:

   I tried, but I don't see a good way to do this one.  The attempts all eventually got to a point where it was necessary at the time of the incoming rising edge to already know when the next edge would arrive.  By definition, that's future-predicting which won't work for a scenario with a variable input freq.

-Kevin P