Multifunction DAQ

cancel
Showing results for 
Search instead for 
Did you mean: 

rare error in counter

HI
I am using counter 0 &1 of PCI6014to measure two different 60 tooth gear drive's RPMs.I have modified count Edge(DAQ-STC).VI for my application. I am getting my RPM correctly for most part of my experiment. But I experience some rare error in my values(approximately 1 error in every values). I have checked my signal and it seems to be good.But the count attribute jumps to a very large value.

Can someone help me in understanding this error. I have attached my VI with this message.
Download All
0 Kudos
Message 1 of 6
(2,887 Views)
Hello,

The count attribute is most likely jumping suddenly to a large value do to false edges or noise in your signal. The counters on the PCI-6014 require TTL level signals. The signals must have the specified rise and fall times require for the TTL specification. If there is noise on your signals, the noise could be causing false counts on the line. You may need to place some low pass filters on your lines in order to remove any high-frequency noise that may be causing this jump in counts.
0 Kudos
Message 2 of 6
(2,886 Views)
Thanks Bill. I have already checked my TTL signal and also checked by replacing my signal with a laboratory grade TTL signal and extra shielding. I still have this problem.

I have also found that this error usually occurs when 1) I move to some other window or application,2) when I move or click my mouse, 3) when I return back from screensaver status to normal display. I think that this could be due to some system delay before which this loop executes, in addition to my sleep time. Could it be due to this delay that the counter accumulates more edges?

I have also noted that if I do not observe an error at the begining of my experiment, I never observe any error through out my experiment and if I observe an error at the begining of my experimen
t then I keep geting this random error. Please sugggest.
0 Kudos
Message 3 of 6
(2,886 Views)
It is hard to say exactly what is causing your large measurements but your additional comments gives me a clue.

When you see this issue it is not in the VI you supplied but in another VI that has the graph.

I susppect you are running into the indeterminism of Windows. This prompts me to suggest you go to a hardware time acquisition. By using one counter's output to gate the conter and your TTL pulse to incremet it, you will be able to avoid the peculiarities of Windows.

What I am genarally guessing is happening now is;

The is no garentee when the start of the counter and the start of your wait. The wait will timeout when the next even multiple of 1 second occurs in the millisecond wait timer. If the starting of the timer is delayed because Windows wants
to go refresh some window that you may or may not want to look at, then the conter does not start when you expect or the wait timer.

Going to a hardware timed scheme, you do not have to worry about windows.

Ben
Retired Senior Automation Systems Architect with Data Science Automation LabVIEW Champion Knight of NI and Prepper LinkedIn Profile YouTube Channel
0 Kudos
Message 4 of 6
(2,886 Views)
Thanks Bill. I had worked with hardware timing initially. But my problem is that I have to measure two different RPMs, and I have only 2 counters in PCI 6014. This constriant made me go for a looping arrangement. Is there any other way other than hardware timing?
0 Kudos
Message 5 of 6
(2,886 Views)
If I want to get good numbers, I use hardware timing or LV Real Time.

I will not rule out getting good numbers without it. I am sure some may say that it can be done.

Ben
Retired Senior Automation Systems Architect with Data Science Automation LabVIEW Champion Knight of NI and Prepper LinkedIn Profile YouTube Channel
0 Kudos
Message 6 of 6
(2,885 Views)