Coverting a traditional NI-DAQ gated photon counting application to Ni-DAQmx with the PCI-6602

[justin_j]

Hi, I'm trying to convert a 2-channel gated photon counting module to NI-DAQmx. There seems to have been a paradigm shift in how the new VI's are defined as gates do not seem to be explicitly included anymore.

This module is intended to work with counters on a PCI-6602 card.

Counters 0 and 1 are run in buffered pulse width measurement mode. The signal source to be counted is attached to PFI39 and 35. The gate for each (to ensure synchronization)is set to RTSI0.

Counter 2 generates the gating pulse and the output is sent to RTSI0. It is triggered by a digital pulse on a DIO port.

The VI Two_channel_gated_photon_counter included in the attached library continuou
sly acquires 1 sample. In actual operation, a buffer it set up for each channel and one sample is acquired for a series of gate periods triggered by the a series of ditial pulses. At the end of the meaurement, the buffer is read out containing the full N samples

Since the 6602 is just supported in DAQmx as of last month, the documentation is sparse and intended for traditional DAQ. I would appreciate help in converting this VI. thanks

[Ames]

justin_j,

The terminology and VIs that are used in NI-DAQmx are definitely different than Traditional NI-DAQ. Below is a sort of general mapping that may help you when moving your application over to NI-DAQmx:

NI-DAQmx Counter VIs mapped to NI-DAQ Counter VIs

• DAQmx Create Channel.vi - Counter Group Config.vi


• DAQmx Channel Property Node.vi - Counter Set Attribute.vi, Counter Source.vi


• DAQmx Trigger Property Node.vi - Counter Set Attribute.vi, Counter Gate.vi


• DAQmx Property Nodes - Counter Set Attribute.vi


• DAQmx Start.vi - Counter Control.vi


• DAQmx Read.vi - Counter Get Attribute.vi


• DAQmx Stop.vi - Counter Control.vi

When you are doing your signal routing I recommend reading the
following KnowledgeBase and the one linked at the bottom of it. They both provide very useful information about routing signals internally and to RTSI using NI-DAQmx.

Using DAQmx Export Signal to Share Counter Pulses over RTSI (http://digital.ni.com/public.nsf/websea...


Ames
Applications Engineering
National Instruments

[gus]

You are correct, there has been a bit of a paradigm switch from traditional to mx for counters. The information Ames provided will covers many of the differences.

One thing I noticed from your description is that it sounds like you're not actually wanting to get your pulse width measurements in time, but rather in ticks (as they would come in traditional daq).

I'm attaching a modified example that sets the GATE ("input terminal" in mx terms) and SOURCE ("counter timebase source" in mx terms) to RTSI0 and PFI39, respectively. Another thing you should note is that the "units" on the create channel VI is set to "ticks". If you measure in seconds, then you have to provide a rate for the source. From your description, it appeared that the rate you have conne
cted to the SOURCE is the unknown that you're measuring.

Hope this helps.
gus....

[justin_j]

Gus and Ames,

Yes, I think this helps alot. You're exactly right in that my unknown signal is on the source, and the known is on the gate. This is 'backward' for this mode, but seems to be the only way I can have the 6602 count pulses in a gated manner. It therefore made no sense to specify a timebase rate and I kept getting errors.

I'll try your suggestions tonight. Also, would you mind reposting your example code in Labview 7.0? We haven't made the upgrade yet and it refuses to load your vi (7.1)

thanks

regards
justin

[gus]

Here's a version saved for LV 7.0.

[justin_j]

Gus,

Thanks. As it stands, your module gives an error in 7.0. It gives me a message saying I need to specify a counter timebase rate for the external source. I can do this with the Channel property node. Can I assume when it is in tick mode, that this value is arbitrary?

thanks

justin

[gus]

Yes, you can. Sorry, I left that off.

[justin_j]

I think it finally works. The last thing was that when running two counters at once(0 and 1), it refused to collect data from counter 1. Explicitly setting DMA to on for both channels mostly fixed this, altho it still dropped a few samples on counter 1.

Setting the timebase digital synchronization to true for each channel seems to have fixed everything. I assume this option is the equivalent of traditional synchronous counting mode.

Thanks very mcuh for your excellent help. I appreciate your and NI's commitment to support. I also look forward to when the transition to mx is complete and the documentation becomes more robust (so that we end users can stop bugging you with trivial questions.)

thanks again

regards
justin

[gus]

Digital synchronization is equivalent to "pad synchronization" in traditional daq. It isn't very well described in the traditional DAQ documentation. In the mx documentation filtering is described in the "Device Considerations" section for TIO. I should have mentioned the traditional synchronous counting mode too. If there is a chance that you will have two gates with no source edges then you should turn on synchronous counting, which is called "duplicate count prevention" in mx-terms. That attribute can be found in the channel property node under "Counter Input->General Properties->More->Advanced->Duplicate Count Prevention". It seems strange to me that you weren't getting data on both your counters. Let me know if the duplicate count prevention
enabled mode doesn't completely eliminate this problem.

gus....

[justin_j]

there is actually a large chance of no source edges between gate pulses. And I see now it still dropping samples and giving me timeout errors. Even upon enabling the duplicate count prevention, it is dropping samples.

I'll include where i am. In the library, it's two_channel_gated_photon_counter_2

I'd appreciate any comments. thanks again

regards
justin