Measure frequency from flow turbine using NI 9401 - error & questions

[ryanGus]

I am trying to measure the frequency of a square wave signal, that can vary from 36.6 to 917 Hz, with the attached VI, but I am getting error message 200430: "I/O type of the physical channel does not match the I/O type required for the virtual channel you are creating." I have attached a screenshot of the error message and I have attached the VI. I am measuring the output signal from the turbine using an NI 9401 "8-Channel, TTL Digital Input/Output Module" in an NI 9171 chassis. The turbine is hooked up to a 12 VDC power supply (grounded there as well) and the output wire of the turbine is wired to terminal 20 on the 9401 (DIO4).

I am confused as to why I am getting the 200430 error message since counter input is being used for the physical and virtual channels, as far as I can tell. Does anyone have any insight as to why I'm experiencing this error? Also, I'm using the "Low frequency with 1 Counter" measurement method, but how does one differentiate between what is considered low frequency vs. what is considered high frequency? Should I be using the "high frequency with 2 counters" measurement method instead?

[Kelle]

downloaded your VI and gave it a look.  It looks like you pulled the selection for the counter from another instance of the Create Virtual Channel VI, because it doesn't match up, which is why you were getting line and port.  Delete it and create it again from the current CI Freq VI and you will get the right options.  After you do that you will likely have an issue with your sample clock, because you didn't say what the source of the external source is.  You can just use implicit for what you are doing I believe.  The changes I have made below.  Give it a try and also take a look at http://www.ni.com/product-documentation/2835/en/#toc3 for more DAQmx knowledge.  Take a look at http://www.ni.com/tutorial/7111/en/ for a bit more counter knowledge.  You should be fine using low frequency though, because this module can read in much faster than the freq range you stated.

[johnsold]

Although it has nothing to do with the errors you are getting you may have other problems with the physical connections.

1. If the turbine is powered from 12 V, is the output compatible with the digital input voltage levels? Some turbines produce signals close to the power supply levels. A 12 V square wave could damage the DAQ input lines.

2. If the edges of the turbine output square wave are not fast enough, some counters may not count correctly. Multiple false counts or missing counts are possible, depending on the details of the counter input circuits. Often NI does not specify the required edge rates for counter inputs.

Lynn

[ryanGus]

Kelle,

I didn't realize that could happen when copying over code, thanks for figuring that out for me! I tried running the VI with the sample clock at a rate of 1 Hz, like in my origional VI, and, as you predicted, I got an error. Using Implicit for the daqmx timing solved that problem, and the VI works. However, I tried to integrate this frequency sampling code with simultaneous sampling of analog current input from my NI 9208, and, although it runs just fine for about 10 seconds, I end up getting error 200279 "Attempted to read samples that are no longer available. The requested sample was previously available, but has since been overwritten" (see attached picture).

I am trying to display samples every second with this code, which I am able to do by setting rate=1 Hz on the sample clock for the analog input signal, but I don't see how I can synchronize the sampling rate of the turbine frequency with the sampling rate of the analong input data. I think the error is coming up because the sampling rate of the clock for the counter is much higher, but I don't know how to get around that - any suggestions? Should I or can I clear the counter buffer at the end of the iteration to address this problem? If so, how would I do that? I have attached the VI for reference. Thank you!

[ryanGus]

Lynn,

That is a good point. I ended up reading signal and haven't had any problems, so I'm guessing that it is in the right voltage range. I plan to check it to be sure but I need to get ahold of a multimeter to check that since we don't have a voltage input module, and I can't read it with the 9401 digital input module from what I understand.

To your second point, I will have to look into that further. The sampling seems to be working for now, but I haven't specifically looked into whether I am getting any missing or false counts. Any recommendations as to how I could check for missed/false counts would be appreciated. Thank you!

[Roohcifer]

Hi ryanGus,

When you use implicit timing, the sample clock is actually the signal you're counting.  So every rising edge of your input signal is going to latch the counter register value into the FIFO that gets piped up to the host PC.  If you use sample clock timing, the counter will require you to provide it with a sample clock that will be responsible for latching count register values into the FIFO.  Since one task is implicit and the other is using a sample clock generated from the oscillator on the cDAQ, the two tasks are by definition using two unrelated clocks and will eventually drift and cause the error you are seeing.  There are two approaches to synchronize your two measurements:

1.  If you do not need precise synchronization (typically, a couple of ms difference between the counter and analog measurements), then you can (a) get rid of both timing VIs and (b) add a Wait Until Next ms Multiple VI in your while loop with 1000 ms wired as the input.  This will software time your acquisition and poll the modules every second for their most recent sample each time your loop iterates.  This is fine for your application because your acquisition is slow and will work as long as you don't care about precise sync.

2.  If you do need precise synchronization, change the timing type on your counter task from Implicit to Sample Clock, and make the source of the sample clock the AI sample clock used in your AI task.  This will ONLY work if both modules are in the SAME cDAQ chassis.  If they are not (and I suspect they aren't since one device is called cDAQ1Mod1 and the other is cDAQ3Mod1), then you will need to export the sample clock from cDAQ1 and import it on cDAQ3 through a physical line - PFI lines on the chassis, if yours has them, or through any parallel digital module.  You will also need to ensure that your counter task is started before your AI task so that you do not miss sample clock edges on the slave task.  If you want to go down this synchronization route, then please provide us with a full description of your hardware, distances between chassis, and what other modules you have available in each chassis.  If the software timed scheme described in section 1 is good enough, then I would recommend going with that because it is much simpler to implement.

Finally, just to have good coding practices and error handling, you should be clearing your DAQmx tasks after the loop is stopped with the DAQmx Clear VI and stopping your while loop if you have any errors.  You can use a Compound Arithmatic block and configure it for an OR operation in the loop before the stop terminal.  You can then wire the error wires directly into it along with your Stop button boolean output.  That way, your loop will stop if your tasks error out.  I would recommend looking at some examples in Help>>Find Examples.  In the Browse tab, select Hardware Input and Output>>DAQmx, and you should be able to find software timed and hardware timed examples for analog and counter tasks with best error handling practices implemented.

Good luck, and let us know if you need further help!

Regards,

[ryanGus]

David,

Method #1 works for getting rid of the error but now I have run into some other problems.

1) The program runs fine when I wire the digital signal from the turbine to CTR 0 GATE (terminal 16 on the 9401), but it does not work when I wire the digital signal from the turbine to CTR 0 SRC (terminal 14). From what I have read, I am supposed to hook up the signal to CTR SRC rather than CTR GATE. Can someone explain why the output is good when using GATE but not when using SRC?

2) Since the results described in 1) seemed to work (using GATE), I hooked up another one of these turbines to the 9401 on CTR 2 GATE (terminal 17), and I hooked up the digital output of the pump (which also has a digital output whose frequency varies linearly with flow rate) to CTR 1 GATE (terminal 22). A screenshot of the output from the program with all three signals hooked up - which should all display the same flow rate because they are in-series - is attached. In that image, you will see that Turbine T1 (middle row of graphs) reads pretty much the same flow rate as the output from the pump (top row of graphs). The odd thing is, the same exact type/model of turbine (Turbine T2, 3rd row of graphs), hooked up to another CTR GATE terminal, displays a very noisey signal. After looking at that signal for a while, and adjusting the flow rate up and down, I noticed that the max frequency of the noisey signal does change with flow rate but it is just very noisey, in fact, the max frequency that the noisey signal displays is the same steady frequency that the other turbine displays. Anyone know why the Turbine T2 (CTR 2 GATE, terminal 17) is so much more noisey? Any ideas on how to fix this? I have attached the VI that I'm using.

Thanks for the recommendation on the task clearing, I'll work on getting that into my programs soon.

[Roohcifer]

Ryan,

1)  Per p.62-63 of the 917x user manual, you route the signal whose frequency you want to measure to the gate (not the source), and you route a known timebase (this is done by default) to the source.  Since we know the frequency of the source (the cDAQ's onboard timebase) the cDAQ can count that source's edges during the period of your signal whose frequency you want to know and take the inverse of the product of the number of timebase edges and the timebase period to get your signal frequency.  You can change which physical PFI line is routed to your counter's gate by using the Counter Input Frequency Input Terminal property in a DAQmx Channel Property Node.

2).  Swap the "noisy" signal input with the "good" signal input to see whether the "noise" is coming from your instrument or if it is tied to a particular counter or physical pin.  If the noise is coming from your instrument, scope the line and post a trace on here.  Depending on the type of noise, there may be a digital filter you can enable on the cDAQ.  Else, you may be able to use some external signal conditioning to remove the noise.

Regards,