Charting Frequency Measurements Over Time

[Surfmase]

Hi,

I'm new to this, and would like to know if my approach sounds reasonable and perhaps have some guidance in the execution.

I want to build an application that will primarily allow me to plot wire-feed-speed measurements over time. The reason I say over time, is becuase I wish to additionally read AI signals from a motor controller containing motor speed and current. And "time" sounds like the obvious way to relate the measurements.

I am playing with a USB 6210 and have an encoder attached to a wheel in the wire-feed system.  Using a counter input I can measure frequency and then calculate wire feed speed.  I started with this example and it sort of works for me.

https://forums.ni.com/t5/Example-Code/Use-Counter-Frequency-to-obtain-an-Encoder-Rotational-Speed/ta...

If I pull the wire for a second, the chart will start a display and continue charting long after the wire has physically stopped moving.  This has to do with the wait block.  If I reduce the wait time or simply remove it, the chart reflects more of what is physically happening.  However, if the wire stops moving, the chart stops charting.  This is where I get confused. I could essentially use this chart as is, but what if I want to read the AI data from the motor and compare it with the counter speed measurements.  I would need them to be synchronised over a delta t wouldn't I?  I have found other counter examples which read pulse width, frequency continuously and even synchronise with an AI, but I am missing the big picture with the timing.

Any clues?

Any other examples I should look at?

I'm also looking for some Labview beginner courses to expedite this process, only finding something hasn't been so easy.

Cheers,

[santo_13]

Please share the VI you've so far for the forum members to review.

There is a bunch of courses available on https://learn.ni.com/catalog

For LabVIEW, you can take up Core1, Core2 and there is a separate one for DAQmx

[Surfmase]

Hi,

This first one is the example from the link, just stipped down to a minimum.  The second one has AI channels added in.

cheers,

[Kevin_Price · Accepted solution]

I can't open anything newer than LV 2020.  It'll help to go to File->Save for Previous Version... and then choose something like maybe LV 2016 for back-saving.  A lot of us "regulars" work on equipment with careful version and config control, and may go some years between version upgrades.   (Where I'm at, we made major changeovers at 2013, 2016, and 2020.)

You may have a kinda tricky problem here though, depending on what kind of freq resolution and quantization you're able to accept.

The *easy* approach would be to share the AI sample clock with your counter task.   But then your counter task would either be an encoder position task or an edge-count task.  You'd then have to calculate speed from the delta positions and delta times.   There are then 2 issues.

1. The delta positions will be quantized and you'll have a +/- 1 count uncertainty.  Depending on your sample rate, this could represent a fairly large % error.   Faster sample rates lead to greater quantization error in this kind of setup.
2. The act of doing a numerical derivative to calculate speed will *amplify* this quantization error.

In the frequency approach you tried so far, quantization error comes from the timebase used to measure the frequency.  This often ends up being +/- 1 count out of maybe 10000 or so, making a pretty small % error.  Plus, it correlates directly to speed so you no longer amplify the error with a division operation. 

    So you could get good speed data if you use the encoder signal as your AI sample clock.  But again, 2 issues.

1. Sampling only occurs when the encoder is moving.  You're blind to the AI signals when you aren't sampling them.
2. You have some further work to do to translate from what you captured (Freq and AI vs. encoder position) to what you probably want (Freq and AI vs. time).   This part isn't too bad though -- acquisition time is just the cumulative sum of 1/Freq.

What kind of encoder rates do you expect?   What % error can you tolerate in your speed data?  How important is it to monitor and observe AI signals when there's no encoder motion?

-Kevin P

[Surfmase]

Hi Kevin,

Thanks for your response.  You may remember helping me with the same task last year, only then I was using DAQExpress.  Now I'm working with Labview, trying to build up my understanding of the environment.

Here are the files backsaved to 16.

At first take it appears the frequency approach is the better of the two, purely error based. I think ultimately it isn't tragic if I'm blind to the AI signals when the encoder isn't moving.  I would like to notice slip, which would be the motor moving and the encoder not moving, but if this is the compromise to avoid large quantization errors, then I can probably live with it.

According to the harmonized standard for my products' measuring equipment: "the tachometer shall be +/- 1% of the full scale reading." Since my tachometer is the encoder with up to 300kHz resolution, I would need < +/- 3kHz error.  Hmmm, My maximum speed would produce 5kHz; I'm not sure if this would necessarily be a bad choice of encoder.  I would at least feel more confident if the error were < +/- 50 Hz.  I could be thinking about this all wrong too.

Thanks for the tip about summing the periods, I'll look for ways to do this.

Cheers,

[Kevin_Price]

There's a 3rd option too.  If the AI task used a Start Trigger which was the same signal that the Ctr task used as an "Arm Start" trigger, that would start both streams of data acq with the same t0 marker.

From there, the Ctr task can proceed with Freq measurement, implying a variable sample rate, while the AI task works at a constant rate.   You'd need to post-process the Freq data to come up with cumulative time that you could then correlate to AI.

There are still tricky parts such as dealing with long time periods with no encoder motion.  For one thing you need to handle timeout errors you might get and for another thing you may need to try to deal with counter rollover issues.  These would happen every 50-some seconds  (32-bit max count value divided by 80 MHz timebase) when there's no encoder motion.   You'd need to query for them and count them up so you can account for them when converting from Freq to Time.   For each such rollover, the real count is 2^32 *bigger* than the reported count.  Then you've got to use that to account for what the *real* Freq must have been for that interval.

-Kevin P

[Surfmase]

Hi Kevin,

I've used this VI for a few different trial runs.  I'm using the same approach as before to eliminate "extra" work which is at the moment over my head.

You'll see I've eliminated the timing block from the counter channel.  The excel file 160 V20... shows the data which was written to file.  Because the time appears in the first column I have created scatter plots in excel for the 3 channels with this time as the X axis.  All appears normal.  If I count the number of measurements over delta 1 sec. I have 122 measurements.  At this speed the counter should be sending 550 pulses per second.  Obviously with no explicit timing I don't expect any certain measurement frequency.

The thing is, with a timing block on the counter channel (implicit, continuous) things start to get wierd.  In my waveform graph the two analog signals from the motor reflect what is physically happening.  The counter signal sending wire-speed will continue long after the motor has physically stopped, as if the measurements are queued and coming in delayed.  This can be seen in excel spreadsheet WFS test2: the two analog signals drop off after around 1 sec. but the wire-speed continues until nearly 4 sec.  What is going on here?  Additionally the number of measurements over delta 1 sec. is 150.  Why would I still not have the 550 measurements per second corresponding to pulses per second?

I need to test each system at different speeds. Does having the frequency measurement as timebase allow me comparable testing at different speeds?  Should I consider other means of aquiring the wire speed, such as laser?  Although one of these that I have read about gives a pulsed output signal.

Cheers and Thanks,

[Kevin_Price]

By eliminating the call to DAQmx Timing, you lose the ability to time-correlate any counter frequency measurement to your AI data.  You won't have data representing a continuous stretch of time, just lots of individual frequency queries at unknown times.   This is the reason you don't get as many readings as you expected.  Software timing can't do the job, you *need* to use one of the 3 hardware-based timing approaches I outlined previoiusly.

In the posted code, you also removed the DAQmx Timing call from your AI task.  I'd expect your AI task to *also* go into unbuffered, software-timed operation, but I see that you also call DAQmx Read with NChan NSamp.  Do you actually receive more than 1 sample per read?

Time to do some homework so that the stuff that's currently "over your head" becomes more comprehensible.  Start from a shipping example that does buffered counter frequency measurement.  It'll use DAQmx Timing and retrieve an array of measurements in the Read call.  Save a copy under a new name in a work area of your choosing and start focusing on how you might construct a time vs freq XY graph.  

    Experiment with and research the "Arm Start Trigger" for counter input measurements.  This goes along with the 3rd approach I mentioned previously, which is the best one to aim for.

-Kevin P

[RobertZamora52]

I'm using a USB 6210 with an encoder on a wire-feed wheel. Using a counter input, I can compute wire feed speed. This is how I started and it worked for me.

[Surfmase]

Hello RobertZamora,

Which of the above methods from Kevin did you use?  Do you use an arm start trigger?