Solved! Go to Solution.
Internal clock (sorry for the mistake).
In the beging of the examples I often see :
* This example shows how to measure pulse width on the counter's default input
* terminal (see I/O Connections Overview below for more information), but
* could easily be expanded to measure pulse width on any PFI, RTSI, or
* internal signal.
But I don't understand how am I suppose to do, to measure pulse width on any PFI input gate ?
On an M-series device, like your USB-6251, you cannot select a 'real' internal clock for correlated DIO. You can however route the AI, AO or Counter clock. You can simply do this by selecting e.g. the aisampleclock (/Dev1/ai/SampleClock) as the source in the ConfigureSampleClock method. To achieve a rate of 2kHz, you should simply specify a rate of 2000 to the same method to achieve a rate of 2000 samples/second.
When measuring pulse width on any of the PFI (or RTSI pins), you are actually just routing the pins to the counter source. So in the end you are still using the counter to measure the pulse width, which limits the number of signals to measure at the same time to 2 in your case. You can select a PFI pin as source for the counter by setting the CountEdgesTerminal property. To see what pins can be routed to the counter source internally, check the device properties in the Measurement & Automation Explorer. The device routes tab gives a nice overview of all possible routes on your device.
Ok I see, I will try with another way. I would like to do the less cabling as possible and reduce the external clock.
Now I'm trying to use two tasks on two different channels without counter, so on port0.0 and port 0.1, and trying to buffer it, then to get the raw data (0,0,0,0,1,1,1,…) and to process it in C#.
But when I’m trying to launch the task I get this error:
I assume that is because, both task trying to access to the same resource, but I don’t see which it is…
Maybe the internal clock or a buffer ?
This is indeed true. However, nothing holds you from putting the lines togheter in one task and reading them out this way. Afterwards you can then process them again using C# 😉
Yes that's what I'm doing basis on this example :
C:\Users\Public\Documents\National Instruments\NI-DAQ\Examples\DotNET1.1\Digital\Read Values\ReadDigPort_ExtClk\cs