LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Averaging multiple channels when button pressed

Solved!
Go to solution

I'd like to measure average torque, rpm, and electrical power of a test stand for motors and propellers. I'm measuring torque using a strain gauge module, rpm using a counter, and electrical power from an external instrument via VISA. I can acquire this data without any problems and graph it live on my front panel.

 

When I press an "average" button, I want LabVIEW to start taking a X second average of each reading and record them to a text file. X depends on what I input to a front panel control (ex: 2000 ms, 5000 ms, etc.). This feature lets me record the readings only when I see the torque, rpm, and power have reached steady-state.

 

I've implemented a bare-bones version of this in the attached VI for a single simulated channel. The producer loop acquires and plots the readings to a waveform chart. When I press "average", the consumer loop appends queue elements until X readings have been achieved and then computes the RMS value. The array size indicator value should match the averaging period control value.

 

My questions are as follows:

  1. Should I even be using queues and separate loops? Is there a 1-loop solution?
  2. How should I scale this up to multiple channels? I've made a rough VI with 2 channels, but I've encountered a logic error wherein I'm not appending the "stored" data correctly within the consumer loop. I'm trying to replace the appending-method with replacement of a pre-allocated array.
0 Kudos
Message 1 of 24
(293 Views)

Why is your wiring so messy?

"If you weren't supposed to push it, it wouldn't be a button."
0 Kudos
Message 2 of 24
(291 Views)

I tried to minimize wiring as much as possible. I didn't want to use sub-VIs so I could just upload 1 file to the forum. Do you have any suggestions to further organize the wiring?

0 Kudos
Message 3 of 24
(272 Views)

@aeroAggie wrote:

I tried to minimize wiring as much as possible. I didn't want to use sub-VIs so I could just upload 1 file to the forum. Do you have any suggestions to further organize the wiring?


Minimize wire bends and hidden wires.

"If you weren't supposed to push it, it wouldn't be a button."
0 Kudos
Message 4 of 24
(256 Views)

I realized I'm complicating the averaging function, but I can't work on this problem again for a few days (maybe weeks). I will post my 'fix' as soon as I can.

0 Kudos
Message 5 of 24
(252 Views)

I developed the attached code. I would appreciate review by another set of eyes. All files are saved for LV16, and the main file is "testbed". All other are dependent sub-VIs.

 

A producer loop "reads" data from N signals. When the "average" button is pressed, the consumer loop takes an average of M data points for each signal and writes the averages to a text file. In this instance, N = 3 and M = 10, but you can adjust as needed.

 

Some other controls handle the file location & name and any applicable headers for the output data file.

 

Note that the input signals must be scalars. If one of my input signals is an array (such as a DAQmx reading), then I must somehow downsize that array into a scalar (first value, last value, average, etc.).


Questions

  1. Are there any red flags with this structure?
  2. The ultimate goal (see original post) is to average readings from a torque sensor (DAQmx analog read), RPM sensor (DAQmx counter read), and an external instrument (VISA read). The torque output will be an array (size set by DAQ buffer), the RPM sensor output will be ???, and the instrument reading will be a scalar. I'm OK with reducing the readings into scalars before I feed them into my averaging code, but I'm curious if y'all have any better suggestions.

    For example, should I have multiple producer loops for each of the readings? That is, one loop that gathers DAQ analog readings, another loop for the DAQ counter readings, etc. I don't see a point since my goal is to calculate efficiencies, and ultimately the numerous DAQ readings will be divided by a far less number of external instrument (power analyzer) readings.

Thanks!

 

0 Kudos
Message 6 of 24
(189 Views)

Still a lot of zigzags on the wires; and many are jammed close together.  I'm not going to try to follow them.

"If you weren't supposed to push it, it wouldn't be a button."
0 Kudos
Message 7 of 24
(164 Views)

I don't know how to organize the wires without the cleanup feature moving them again.

Do you just not use auto-clean?

0 Kudos
Message 8 of 24
(157 Views)

Hi Aggie,

 


@aeroAggie wrote:

I don't know how to organize the wires without the cleanup feature moving them again.

Do you just not use auto-clean?


Autocleanup only works nicely for rather small/simple VIs.

When you want to cleanup larger/complicated VIs you need to implement your own coding style rules:

(When the arrays have the same size then you can also eliminate the FOR loop in the first case structure.)

 

I don't see how your VI is related to your problem description: there is only an array of (simulated) samples, but you asked for atleast 3 different data sources (analog input, counter, VISA)…

 

Btw. I suggest to rethink your program design: I don't think it's a good idea to access UI elements used in the producer loop also in the consumer loop, especially when you need property/method nodes to do so…

Best regards,
GerdW


using LV2016/2019/2020 on Win8.1/10+cRIO
0 Kudos
Message 9 of 24
(148 Views)

Hi GerdW thanks for the feedback.

 

@for loop: I will try to remove that for loop. Earlier, I encountered mismatched array sizes, so I used the loop to manually add along one array's dimensions. However, I think the "array size != 0" check I now have just before the case structure should alleviate that problem.

 

@how this addresses my problem: I don't know how to implement the averaging. I know how to create a VI to access data from the various sensors and instruments. I created this VI with dummy signals (the array of numeric controls) to try and code the averaging feature. In the future, I will replace the dummy signals in the producer loop with actual data from DAQmx and the instrument library. Does that make sense?

 

@Program design: Do you have any suggestions? How else can I reset the averaging button?

0 Kudos
Message 10 of 24
(128 Views)