Sync counter inputs and analog inputs at low rpm with NI-USB 6343

[Brown@KTR]

I've searched the forums for the past week and have come up empty handed with respect to my particular situation.

Using a NI-USB6343 X Series Multifunction DAQ.

I have two counter inputs and three analog inputs.  The two coutner inputs are calculating "input speed" and "output speed".  I'm measuring each with a 60 tooth tonewheel (obtaining a TTL 0-5V) and the Low Frequency 1 Counter method. Min and max rpm of the input are 150rpm and 3000rpm, respectively.  I'm having problems with the output speed which is dependent on a particular gear ratio.  The highest gear ratio is approx. 6.4:1, therefore my output speed can be as low as 23.4rpm (which equals 23.4Hz when using a 60 tooth tonewheel).  In order to sync the counter and analog inputs, the sampling rate has to be less than the lowest signal frequency (ideally at least half of the signal frequency) going into my counter inputs or the task with throw error -201314 and I can't acquire any more coutner input data from either channel.  

I've come to terms with having to use a lower sampling frequency.  But even in some situations, the signal frequency (from the output speed) may dip below the sampling frequency for a couple of pulses (if a clutch slips) and the task throws the error and screws up my acquisition.  I've tried clearing the error, but even if the signal frequency rises above the sampling frequency the acquisition won't continue.  I've tried adding a stop task after clearing the error and then a start task, but this screws up the timing when I write the data to file. 

Is there a way to clear the error, stop the task and start it again without losing data. Ideally, I'd like to capture these clutch slips or any other speed differentials on the output.  So I would like a condition that says "if error -201314 true, output zeros instead of nothing". 

Also, if anybody knows a way to use a higher sampling frequency with this type of acquisition...I'm all ears.  I would like to sample at 100Hz or higher.

The VI is attached.

Thanks,

-Mike

[Myr.i.am.]

Hey brown_ktr,

You mentioned in your post that if you stop the task, clear it, and then restart it, it offsets the data when you write to a file.  Since your loop writes a fixed number of data points at every iteration (looks like 10 data points), you could try creating an array of 10 zeros in your case structure and outputting that to the file whenever the error occurs.

Myriam

Applications Engineer

National Instruments

[Brown@KTR]

Myr.i.am,

Thanks for the suggestion.  It works, but I had to get rid of the producer/consumer structure and just use a single loop.  There must be an issue with sending the data to the queue.  I guess I don't really need the producer/consumer structure anyway.

In the end, I might just find another piece of hardware (we have a Red Lion Digital Input Panel Meter) that can convert the frequency signals to analog signals and use those instead of the counters.  That way I can avoid using such a low sampling rate. 

Cheers.

[Myr.i.am.]

Hey brown_ktr,

You should be able to pass any type of data through a queue, as long as all of the data is of the same type.  Feel free to attach your code (or a screenshot) with the issue you're getting if you'd like me to take a look at it.

Thanks,

Myriam

Applications Engineer

National Instruments

[Brown@KTR]

I think I found the mistake. I forgot to initialize the array with zeros.  I just created the array constant and dragged it down so that it consisted of 10 elements but I didn't initialize it.

I haven't had a chance to run the program yet but I'm sure this is the problem. I'll try it again tomorrow.