PCI express alternative to PCI 6602?

[thomas03]

Hi John

The PCIe6320 has come in!

I want to do buffered measurements on all 4 counters using the 100 MHz timebase.

You have mentioned that in implicit buffered period measurement the first sample is lost.

I have mentioned that it is not an issue for us to loose the first sample, which was not correct.

I did not consider that the 4 measurements need to be synchronized in time and in your Figure 7-11 for the X-series the time information

between counter arm and sample is lost.

Can i simply solve this by using buffered edge counters instead with a start arm trigger?

Can i use a DO channel for the latter task?

Thank you!    

best regards,

Thomas

[Kevin_Price]

1. Buffered edge counting ought to be a viable plan. 

2. For all tasks, you'll need to specify the 100MHz internal clock as the input channel for which edges will be counted and counts will be buffered.

3. The signal whose period you originally planned to measure will become the sample clock source for the task.  Each task will have a different sample clock this way, but all will be synced at t=0 by the arm start trigger.

4. You may need to handle counter rollover because a 32-bit counter rolls over in well under a minute at 100 MHz.  I'd recommend that you track this with the DAQmx boolean property "Terminal Count Reached".  As long as you query fast enough that the counter doesn't roll over *twice* between queries, you'll be ok.  Each TC rollover event will cause this property to return a 'True' exactly 1 time when queried.  Subsequent queries after the same rollover will return a 'False'.  After the next rollover, 'True' is again returned exactly once on the first query thereafter.  And so on.

-Kevin P

[John_P1]

Kevin's description is exactly the workaround that you will need to use.

Furthermore, if the count is returned as U32 then the handling of overflows becomes relatively simple.  Subtracting consecutive samples as U32 will always give the number of ticks between sample clocks as long as there are less than 2³² ticks between samples (just under 43 seconds if using the 100 MHz timebase).  For example, 0 - 4294967295 (terminal count on a 32-bit counter) would be equal to 1 if both numbers are U32 datatype.

Best Regards,

[thomas03]

Kevin and John, thanks for your answers!.

On they way following your instructions i got stuck.

I plugged one detector on the input of PFI9.  The NI testpanel nicely counts the TTL pulses (5V, 35ns), about 500 per second.

But with the Ainsi example "Cnt-Buf-Cont-ExtClk.c" i do not get any proper reading with following content in the errBuff:

Multiple Sample Clock pulses were detected within one period of the input signal. Use a Sample Clock rate that is slower than the input signal. If you are using an external Sample Clock, ensure that clock signal is within the jitter and voltage level specifications and without glitches.

Property: DAQmx_Read_RelativeTo

Requested Value: DAQmx_Val_CurrReadPos

Property: DAQmx_Read_Offset

Requested Value: 0

Task Name: _unnamedTask<0>

Status Code: -201314

I have played with parameters like sample rates but always get the same result.

Maybe there is a problem with the driver?

I am using CodeGear C++ Builder 2007 and downloaded the latest nidaqmx.lib file for Borland here

http://digital.ni.com/public.nsf/allkb/B09727F89DA3A06C86256F430071D88E

Could you please give me another hint? 

Thomas

[John_P1]

Hi Thomas,

I'll assume that you are using DAQmxSetCICountEdgesTerm to set the source of your edge count task to be the 100 MHz timebase (see Kevin's previous suggestion).  Even if you aren't doing that however, it's perfectly OK to have the sample clock running faster than the source terminal for an edge count task, so despite the text of the error I don't think this is the issue (but you do need to use the internal timebase as the counter source for your application to work in general).

The particular error you are seeing is generated in hardware when a sample clock edge is detected before the count value can be latched into the on-board FIFO.  Typically this comes up for sample-clocked period measurements, which require a complete period of the input signal in order to return a value on the sample clock edge.  Hence, the message suggests to use a Sample Clock rate that is slower than the input signal.

In your case, the problem is probably that there are glitches on the sample clock signal and the hardware is trying to latch samples in too quickly.  The digital front-end is different on the 6602 compared to X Series cards, so it would not necessarily be unreasonable that you are picking up glitches on one card and not the other (although I certainly wouldn't have foreseen this behavior).  However, you can use digital filtering to remove these glitches on the X Series (see user manual) assuming your input pulses are over 20 ns wide.  Try setting the following properties:

DAQmxSetSampClkDigFltrEnable(taskHandle, TRUE);

DAQmxSetSampClkDigFltrMinPulseWidth(taskHandle, 0.00000002);

The above will pass any pulses wider than 20ns, and will reject any pulses less than 10ns (pulses in between 10 and 20 ns might be detected or might be ignored depending on the phase of the 100 MHz timebase relative to the signal).  You can increase the pulse width in increments of 10 ns if desired--you'll probably want it a little bit higher as long as your input pulses are wide enough.

If your input pulses are too short for digital filtering, then you'll probably need some sort of external buffer to clean up the signal.  You could use a re-triggerable single pulse generation to clean up the signal (trigger a pulse off of the external signal--it will ignore triggers while it is still being generated), but this would only let you use 2 channels at one time.

Best Regards,

[thomas03]

Hi John,

It works, the digital filtering does it just as you said. Great, thanks a lot!!

I moved on using two detectors with two tasks. Works, but they are not initiated by the arm start trigger yet.

As far as i understand it from other posts i have to set it up for both counter tasks like this (is this correct?)

DAQmxSetArmStartTrigType(taskHandle1, DAQmx_Val_DigEdge);
DAQmxSetDigEdgeArmStartTrigSrc(taskHandle1, "PFI?");
DAQmxSetDigEdgeArmStartTrigEdge(taskHandle1, DAQmx_Val_Rising); 

And i have to create a third task to create a rising edge on PFI? with DAQmxCreateDOChan.

On the 6320 there are only 4 digital outputs: P1.<0:3>  corresponding to the PFI 6:9.

But how do i write to those?

DAQmxErrChk (DAQmxCreateDOChan(taskHandle3,"Dev1/port1/line0:3","",DAQmx_Val_ChanForAllLines));

...Doesn't work.

Thanks, again and again...

Thomas

[John_P1]

Hi Thomas,

Sounds like it's coming along nicely. 

The counters themselves don't generate an arm start trigger internally so you do need a way to generate the signal.  A digital output task should be a very reasonable way to do so.  You are correctly specifying how to use the signal on the PFI line as an Arm Start, so I bet the problem is probably with your DO task.  

The 6320 actually has 24 bidirectional DIO lines (8 on each port).  Port 0 is for clocked DIO, and Ports 1 and 2 contain PFI lines.  The lines on any of the ports may be used for static DIO which is all you really need to start your generation.  Line direction is configurable on a per line basis.  For good measure I tried setting up counters on my PCIe-6353 to use PFI0 as the Arm Start, then use p1.0 in my static DO task (they are the same pin).  The counters did in fact start simultaneously and I didn't have to make any external connections.  The code went something like:

CreateTask

Create Channel

Start Task

Write Line (low)

Write Line (high)

Write Line (low)

Clear Task

The 1st write is to ensure that there is a rising edge regardless of the previous state of the DO line.  The 3rd write is there assuming you don't want to leave the line high after you are done with it.  I wouldn't put more than a single line in your task.  You may arm all 4 counters off of the same PFI line which is what I assume you would want to do. Make sure to run the DO code after the counter tasks have started.

If you're still having issues feel free to post the DO portion of the code.

Once you get everything working you should probably add in digital filtering for the arm start PFI lines (you have to set the same value for the same PFI line in each task).

Best Regards,

[thomas03]

Hi John,

Yesterday i accidentally opened the wrong spec file.

It is kind of difficult to program the DOs of the PCIe-6320 correctly using the specifications of the PCI-6230…

Thank you and shame on me!

Arm Start triggered buffered edge counting is working!

Could you please let me know how to add filtering also for the trigger.

I attached my c++ snippet.

But guess what. I am stuck again!

Well, at least I prefer to get your strategic advice in which direction to proceed.

My two detectors, depending on the amount of light they receive, produce count rates per second anywhere between 50 and 3'000'000.

Apparently the DAQmxReadCounterU32 command waits until at least one sample has come in. If that takes a few milliseconds for one detector (seeing a low light level)

the 127 sample FIFO buffer for the other detector (seeing high light level) will easily overflow. Eventually i want to read 4 detectors.

Should/can I read the counters from different threads? Are there better options?

Looking forward to hear from you!

Thomas

[thomas03]

Ok, I found it myself in the c reference.

To avoid waiting time and only read samples into the buffer in case they are availible one simply sets the numSampsPerChan to -1.

DAQmxErrChk (DAQmxReadCounterU32(taskHandle1,-1,10.0,data1,1000,&read1,NULL));

Before i ask too many stupid questions in one thread I suggest to close this one.

The NI-documentation for c++ has been fairly confusing to me but also not too frustrating

as the great support on this site has easily compensated for that.

I conclude that for my application the PCIe-6320 is a much more powerful alternative to the good old 6602.

John, please don't forget to post me how to add the filter for the trigger. thank you

You may have the last word.

[Kevin_Price]

I'm still no use on C syntax, but can give you some general ideas:

1. The fact that the 'Read' waits for at least one sample *might* be a behavior you can change by looking into a boolean property setting known as "duplicate count prevention." 

2. You could read the individual counters from separate threads to keep the timing independent.

3. Or you could stay in one thread with the following strategy: before trying read a sample, first query to see how many are available.  If none, don't read from that counter.  Otherwise, read all available.  (In LabVIEW, there's a default behavior to read "all available" when you request the # to read == -1.  However, if there are none available to read, the call still blocks for the duration of the specified timeout.  This same behavior is probably available via C, and you can improve the responsiveness by specifying a very small timeout.)

4. You aren't limited to the on-board FIFO buffer.  DAQmx will deal with moving data from the board into the system RAM buffer you specified when you configured timing.   So you don't generally need to read <127 samples at a time.  You should be fine reading 100's or 1000's at a time.  Note: if you need to deal with >1MHz bursts, I'd suggest you increase your configured buffer size to accomodate.  (DAQmx does do some degree of automatic buffer sizing, but I'm not sure it'll choose a big enough size in your case here.)

-Kevin P