Synchronizing two counter frequency inputs with multiple analog inputs

[BikeBandit]

Hello all,

I'm fairly new to LabVIEW and I'm trying to collect data from multiple sources with synchronized timing on the acquisition but I'm having trouble figuring it out. My problem is that I've got two counter frequency inputs, one optical tachometer reading one pulse per revolution, and a max machinery flow meter with a k factor of 12000. I can't seem to figure out how to sync the timing with my multiple analog inputs. I've been attempting to get the tachometer  to sync with the analog inputs first by following the example linked here. (https://decibel.ni.com/content/docs/DOC-10785) So far each time I run it I either get a timeout error on the DAQmx read or a "Multiple sample clock pulses were detected" error (see attached image).  It seems if I slow the sampling rate way down to say 10 hz and ensure that the tachometer signal is over 800-1000 RPM (13-17 Hz) before starting the VI then the program will run without errors until the RPM drops below that threshold then the "Multiple sample clock pulses" error occurs.  The code is attached below.

Does anyone know of a more effective way of syncing counter frequency inputs with analog inputs?  I'd like to have a VI that can show 0 RPM (and eventually 0 flow as well, but I think I need to figure out the timing of one counter before I add another as it seems I can't have two counters in the same task). Any help on this would be greatly appreciated.

LabVIEW version 13.0

cDAQ-9178 Chassis with NI 9401 for the two counter inputs and NI 9205 for the analog inputs.

Thanks!

Richard

[BikeBandit]

Bit of a shameless bump here as I'm still trying to figure this out. 

A more general question then is for anyone that has built a VI with a counter RPM input did you worry about syncing that data up with the analog data or was the difference negligible?  If I make a much simpler VI like the one attached then the program works ok but I don't know how well the data syncs up because the loop is being slowed by the counter read VI (In fact at very low RPM the counter will delay the loop long enough the buffer on the analog fills and causes an error). 

Any help on this would be greatly appreciated.  I imagined this would be a fairly straightforward problem when I first started this as I figure there must be countless VI's using a counter RPM input that needs to at least roughly sync with analog data but I can't seem to find any obvious solutions to this problem.

Thanks again,

Richard

[BikeBandit]

Maybe third times the charm? 

So I've finally got a good handle on why the VI is having problems at low RPM though I'm somewhat embarassed how long it took me to do that 🙂

Because I have the counter time synced to my Analog input task if it doesn't see at least two pulses between the two clock pulses set by the analog input task I get the -201314 "Multiple sample clock pulses" error. This seems fine at first as it just sets a minimum RPM that I can measure and it's well below the area I'm interested in so no problems there.  I tried a simple error handler that would clear the error when it happend assuming the loop would keep iterating until the RPM went above that minimum at which point I would get a signal again. This is not the case, the read function just continues to spit out the -201314 error even after the RPM is back in the readable range. So then I tried adding two case structures so that when the error occured it would stop the task, clear the error, and then start the task again on the next loop iteration (Code Attached). This also doesn't work as the error shows up again on the stop task and then AGAIN on the start task on the next loop iteration. It seems this error is not actually being cleared and once it happens it stays with the task regardless of what the error cluster is carrying. 

Anyone have any ideas?  The only solution I can think of is to just clear all tasks and recreate them each loop iteration until the RPM is readable again but that strikes me as a horribly clunky solution.

Richard 

[John_P1 · Accepted solution]

I know the error requires restarting the task at least (this particular error puts the hardware in a state that can't be recovered from while the task is running--I've been down this road before) but I'm surprised you'd have to clear and re-create the task entirely.  Then again, I've had to do this to workaround other issues in the past.  It is clunky, and ought to be considered a bug if this is indeed the behavior.

Honestly, regardless of this bug, the way that the hardware deals with the situation of multiple sample clock edges makes sample clocked frequency measurements basically unusable for purposes of synchronization (in my opinion anyway) if you might encounter a frequency slower than your sample clock.  You're supposed to be "synchronizing" the measurement, but this really no longer applies if you have to restart the task over and over again (whether you have to clear it or not).

Workarounds can get kind of creative (which is not really a good thing).  For example, you could configure an implicit frequency measurement to keep a buffer of frequencies and use an edge count task (source is the frequency signal, sample clock is the AI sample clock) to correlate the index of your frequency buffer to the appropriate AI sample clock edge.

Best Regards,

[BikeBandit]

Hey John,

Thanks for your reply. Seems I come across your posts all over the place while I was researching on the forums so it's awesome all the help you give around here.

As it turns out the code attached in my previous post does in fact work and you do not have to clear the tasks as I feared.  I had made that as an example at home where I couldn't actually run it but I had tested what I thought was the same code at work previously.  As it turns out the code I'd run at work cleared the error before stopping the task and that seems to have made the difference. It's not perfect as it gives me a minimum measurable reading of about 1000 RPM but the engines I'm testing never run below that so it's acceptable if not ideal. 

thanks again,

Richard