05-21-2012 07:00 PM
Hello,
I am trying to count the number of edges in a specified time interval (e.g. 1 second) using a DIO cDAQ module, 9401, with a chassis cDAQ-9174. This is used to count the number pf photons that hits an avalanche detector.
For the first example photon counter.vi, the task is started and the integration time is set by adding a 'wait until next ms multiple' within the while loop, however, this is not a very accurate way to time the interval in which edge counting occurs.
In the second example photon counter 2.vi, I set a pulse wave of frequency 0.25 Hz as an putput on PFI7 on my 9401 cDAQ module, that is shorted with a wire to the PFI 1. The PFI1 is used as the timing base for the sample clock in the edge counting task. I get an error as follows:
Device cannot be configured for input or output because lines and/or terminals on this device are in use by another task or route. This operation requires temporarily reserving all lines and terminals for communication, which interferes with the other task or route.
If possible, use DAQmx Control Task to reserve all tasks that use this device before committing any tasks that use this device. Otherwise, uncommit or unreserve the other task or disconnect the other route before attempting to configure the device for input or output.
Device: cDAQ1Mod1
Digital Port: 0
Lines: 7
Task Name: _unnamedTask<3>
It sounds like it is not possible to have output and input on the 9401 at the same time, can anyone pls confirm it? If not is there a way to time the integration time more precisely?
Thanks,
Mihai
05-22-2012 01:08 PM - edited 05-22-2012 01:14 PM
Hi Mihai,
The 9401 does have a caveat with setting line direction. However, you should be able to configure the line direction by nibble (i.e. lines 0:3 may be configured in one direction, and line 4:7 may be configured in another direction). There is a KnowledgeBase here that outlines the behavior, but essentially you have to reserve your tasks (using DAQmx Control Task.vi) before starting (or committing) them.
However, this shouldn't even really be necessary for you, as you can just use internal routes to accomplish the same thing. It sounds like you want to run a continuous gating period and report back the number of samples that occurred during each period, correct? If so, you can configure your task as shown in the attached VI.
Using the period task instead of an edge count with sample clock has the advantage of throwing out the first sample (which would represent an incomplete gating period) and it will reset the count after every gating period. Gating periods will be continuous with no gaps in between. If you want to use shorter gating periods which occur faster than the loop can keep up, you would need to read back more than a single sample per loop iteration.
Using the internal outputs prevents you from having to worry about reserving your tasks or making any external routing. In addition, those terminals which you were previously using to connect the counters together are now available should you need them for any additional tasks.
Best Regards,