Synchron analog in and counter in for speed / voltage /current measurement error -201314

[AM86]

Hi all

Application Purpose:

At the moment I am developing an application to measure voltage, current and speed of a controlled motor. Therefore, I am using 2 analog inputs and one counter input of a multifunction daq x-series (NI-USB 6341). The counter is connected with an optical encoder mounted on the motor shaft. The aim is, to have a synchronized measurement values of analog input and counter values, visualized in a graph or diagram. Therefore, I am using the analog in sample clock as reference clock for the counter task. 

Issue:

As attached, I am getting in trouble at lower frequency values (zero rpm). Because of the intended use of the test system, it is not possible to avoid that speed value, Consequently always error -201314 pops up at low frequency. 

Issue Description (only german)

Fehler -201314 bei AI_COunter_Test.vi

Mögliche Ursachen:

Innerhalb einer Periode des Eingangssignal wurden mehrere Sample-Takt-Impulse erkannt. Verwenden Sie eine Sample-Rate, die kleiner ist als das Eingangssignal. Wenn Sie einen externen Sample-Takt verwenden, stellen Sie sicher, dass er die Bedingungen hinsichtlich Jitter und Spannungspegel erfüllt.

Task-Name: _unnamedTask<2C>

Does any of you already had this problem or similar issues? Would be great if you could give a tip or possible solution to try. 

Thanks, 

AM86

[Kevin_Price]

I haven't really explored the behavior of sample-clocked frequency measurements in the absence of the "frequency" signal.  This knowledgebase article related to pulse measurements may provide some further insight, I'd expect freq measurement to behave similarly.

I expect this is probably a non-recoverable error -- once it occurs, the task will never return data again until you restart it.  If that's the case, you'll need to use a different method to measure speed.

The simpler approach is to configure the counter task for edge counting using the same AI sample clock.  Then missing encoder edges won't produce errors and you can take a derivative to calculate speed.  (Note that numerical derivatives add "noise" to your measurement and it's often appropriate to add curve fitting or other processing that helps suppress this noise.)

There's another approach that's significantly more complicated where you use "Implicit Timing" to measure individual encoder pulse intervals.  Then you also have to worry about handling DAQmx Read timeout errors, use of an "Arm Start" trigger to sync t=0 for the two tasks, and do some post-processing resampling because the tasks will not take samples at the same time any more.  And even after all that, use of an X-series board exposes you to yet another complication that I've complained about.

I'd advise the simpler edge-counting-and-derivative approach.

-Kevin P