LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Null Offset LabVIEW Program

Hi Guys, I'm beginner in LabVIEW and wanted to ask about LabVIEW Program. My initial value (value without load) is not giving a zero value. So, I want to calculate the average of it and used it as deduction value to the real value (value with load). I'm making null offset program (value with load substract by the average of initial value or value without load). But, I think there's something wrong with my null offset program, because the average of initial value always giving a zero value. I'm using CDAQ 9188 and C Serues Module 9201 Dsub. Whats wrong with my progran? Please help

Download All
0 Kudos
Message 1 of 16
(3,740 Views)

What you're trying to do is commonly called a "tare" operation. Searching the forums with that term should give more results.

 

That aside, you're having problems probably because the number of samples you read is not controlled, and so could be 0.

Try wiring a constant value (for example, the 100 samples you're claiming to have when you wire the Mean VI) to the "number of samples per channel" input for the DAQmx Read (before the loop).

 

 


GCentral
Message 2 of 16
(3,727 Views)

Your image.png is hiding your wires.  So I can't tell what the 100 is wired up to.

 

But a problem I do see is that you are using Mean point by point.  That takes a running average of individual points coming in.  You wired up a waveform, but you can see by the red dot it is being coerced.  So a waveform of points is being coerced into a single scalar value.  If that Mean is set for 100 samples, you are averaging one real sample in with 99 zeroes (because the mean pt by pt hasn't run 100 times).  The result will be nearly zero.

 

Use the regular Mean function.

Message 3 of 16
(3,675 Views)

@pahlevi28 wrote:

Hi Guys, I'm beginner in LabVIEW and wanted to ask about LabVIEW Program. My initial value (value without load) is not giving a zero value. So, I want to calculate the average of it and used it as deduction value to the real value (value with load). I'm making null offset program (value with load substract by the average of initial value or value without load). But, I think there's something wrong with my null offset program, because the average of initial value always giving a zero value. I'm using CDAQ 9188 and C Serues Module 9201 Dsub. Whats wrong with my progran? Please help


Let's save you from your bad self.  You made some mistakes.

 

  • First, you probably want to use "Finite Samples" (In fact, I'm positive) in the timing vi.
  • Next when you call a read AI with "Continuous Samples" and Samples to read = -1 the vi immediately returns all the samples in the sample buffer- even if that is ZERO samples because you really just started the Task and 10mSec is a long time.  and yes, the mean of 0 samples is 0.
  • Pt by Pt isn't the right way to go either. Raven's Fan could go back and reread the help but, if there haven't been 100 samples sent in it uses only the ones that have been read in up til then (even if there are 0 samples). and yes, the mean of 0 samples is 0.

Just set your timing sample mode to "Finite Samples" (and you could even rely on Autostart and get rid of "Start Task.vi")


"Should be" isn't "Is" -Jay
Message 4 of 16
(3,662 Views)

@JÞB wrote:

Pt by Pt isn't the right way to go either. Raven's Fan could go back and reread the help but, if there haven't been 100 samples sent in it uses only the ones that have been read in up til then (even if there are 0 samples). and yes, the mean of 0 samples is 0.

 


Yep.  You're right.

0 Kudos
Message 5 of 16
(3,652 Views)

@JÞB wrote:
  • First, you probably want to use "Finite Samples" (In fact, I'm positive) in the timing vi.

I wouldn't jump to that conclusion.

 


@JÞB wrote:
  • Next when you call a read AI with "Continuous Samples" and Samples to read = -1 the vi immediately returns all the samples in the sample buffer- even if that is ZERO samples because you really just started the Task and 10mSec is a long time.  and yes, the mean of 0 samples is 0.

Indeed.  So we just have to give it X number of samples to read.  Since we want 1 second of data to average first, we just read 100 samples (100S/s is the data rate).  Inside of the loop, it is best to set it to around 100ms of data, so 10 samples per iteration.  I would also replace the indicator with a chart.


GCentral
There are only two ways to tell somebody thanks: Kudos and Marked Solutions
Unofficial Forum Rules and Guidelines
"Not that we are sufficient in ourselves to claim anything as coming from us, but our sufficiency is from God" - 2 Corinthians 3:5
Download All
Message 6 of 16
(3,641 Views)

@crossrulz wrote:

@JÞB wrote:
  • First, you probably want to use "Finite Samples" (In fact, I'm positive) in the timing vi.

I wouldn't jump to that conclusion.

 


@JÞB wrote:
  • Next when you call a read AI with "Continuous Samples" and Samples to read = -1 the vi immediately returns all the samples in the sample buffer- even if that is ZERO samples because you really just started the Task and 10mSec is a long time.  and yes, the mean of 0 samples is 0.

Indeed.  So we just have to give it X number of samples to read.  Since we want 1 second of data to average first, we just read 100 samples (100S/s is the data rate).  Inside of the loop, it is best to set it to around 100ms of data, so 10 samples per iteration.  I would also replace the indicator with a chart.


At the risk of sounding like Cal Borland...."I don't think so Tim..."

 

The use case the OP has described is to "Tare" individual measurements.  So you assuredly do not want the measurement buffer to continuously gather readings (Stale data will be read until the buffer overflow error occurs)  Take a "Finite" sample of "no weight" and subtract it from the discrete weights that are of interest taken at the time that is interesting.


"Should be" isn't "Is" -Jay
0 Kudos
Message 7 of 16
(3,615 Views)

Dear OP...

 

There are now disagreements over what you're trying to do... it seems like the following are your suggested options:

  • Carry out a brief (~1s?) measurement to get a mean value, then use that as the tare for a continuous measurement afterwards. The tare in this case will not be updated, but will be taken at the beginning of the VI each time you run it. This is the approach that appeared to be suggested by your original example, and was followed by my suggestions and then crossrulz's suggestion (which implemented the fix I suggested)
  • Carry out two fixed-length measurements, the first to get a zero value, then the second to make a measurement. This appears to be what JB (sorry, no attempts at your middle character, although I vaguely recall forum posts discussing how to appropriately insert it...) is suggesting. If you run the VI from another VI, this might be a better suggestion, because it will limit the time that this VI runs for. Advantage is that the "tare" value is close in time to the measurement value, and it's not possible to have an unexpectedly long run. Disadvantage: you can't easily view things if you're adding the weight 'interactively'...

RavensFan also pointed out a problem with your Mean usage - as he said, you should use the Mean.vi, not the PtByPt version (which accepts only a single point per call).

 

Can you clarify what you're looking for here, and suggest any further problems following the already posted advice?


GCentral
Message 8 of 16
(3,604 Views)

The most likely use of a "Weighing" program interfacing to a load cell

 

Capture1.PNGWeigh.png

Would be better shown with the example above.

 

Loads on a load cell generally don't "Pop" into or "Poof" out of existence.  Someone or something has to place them onto or take them off of the load cell.  nobody really cares about the weight when the transitions are being made (we use accelerometers for that measurement) 😄

 

So, a continuous acquisition Task makes absolutely no sense 


"Should be" isn't "Is" -Jay
Message 9 of 16
(3,582 Views)

So, a continuous acquisition Task makes absolutely no sense 

Disagree.  We regularly use load cells to measure dynamic loads, not just static ones.  Continuous acquisition with on-demand tare is entirely appropriate for these situations.

 

 

-Kevin P

CAUTION! New LabVIEW adopters -- it's too late for me, but you *can* save yourself. The new subscription policy for LabVIEW puts NI's hand in your wallet for the rest of your working life. Are you sure you're *that* dedicated to LabVIEW? (Summary of my reasons in this post, part of a voluminous thread of mostly complaints starting here).
Message 10 of 16
(3,564 Views)