LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Strain sampling data

I keep getting this error about increasing my buffer size. I don't know much about strain gauges. I am using quarter bridge I with NI9236. I used continuous sampling but no matter how much I change samples to read and rate, my VI keeps crashing. 

 

I have the samples to read: 1k and rate 1kHZ. I have no weight applied to the strain gage and the valves aren't consistent. 

mo00_0-1583525950475.png

mo00_1-1583525984740.png

 

 

0 Kudos
Message 1 of 8
(2,719 Views)

Please upload the VI.

From your pictures, it's impossible to be sure, but I'd guess you have some incompatibility between the DAQ Assistant settings, or else there's something behind the error dialog that's causing slowdown etc.

 

You're also only taking one value for your calculations, which is odd since you said you're reading 1000 at a time... this is a problem due to the Dynamic Data Type (DDT) blue wires - you could probably clear those type of errors up by reading this (Learn 10 Functions in NI-DAQmx and Handle 80 Percent of Your Data Acquisition Applications) and then using it to switch to DAQmx.


GCentral
0 Kudos
Message 2 of 8
(2,680 Views)

Here is my VI

0 Kudos
Message 3 of 8
(2,639 Views)

I actually need it to be quarter bridge 2 for temperature compensation. If you could advise how to set this up, because I tried selecting that and it gave me an error.

0 Kudos
Message 4 of 8
(2,637 Views)

The express VI is set up for finite sampling not continuous sampling as you stated in your original post. Are you still getting this error with finite sampling?

0 Kudos
Message 5 of 8
(2,633 Views)

I was playing around with the settings between finite and continuous sampling and no, I'm not getting the same error. My data looks different for finite vs continuous and I'm not sure which mode to select.

 

I've change samples to read: 300 and rate(hz): 200.

Do these look like more appropriate values? Should I still switch to DAQmx for my calculations?

0 Kudos
Message 6 of 8
(2,627 Views)

There are a lot of combos of sample rate and # to read that can be made to work, including both combos you've mentioned.

 

In all honesty, what you need to do next is take a step back, and develop a better *understanding* of what you *need*, what else you *want*, and a bit more about programming with DAQmx (follow the link from cbutcher back in msg #2).

 

I (and many other knowledgeable folks around here) either can't or simply won't spend time figuring out the opaque inner workings and caveats of the various DAQ Assistants and those much-maligned (but for good reason) Dynamic Data wires.  They're limiting and of no use to us.  There's just no upside from delving in to them.

 

 

-Kevin P

 

 

-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).
0 Kudos
Message 7 of 8
(2,617 Views)

When you have done more reading you will notice a pattern of people telling you that the express VI's, especially the DAQmx ones often introduce more problems than they solve. You are better off converting them to code (right click on the express vi and generate  DAQmx code) I have not used these express VI's much because of these warnings so I am not 100% sure that this will be part of your problem.

 

Are you seeing this error immediately, or does it take a little while to appear/does it appear when you start doing something else with your PC (Openning excel for example)?

 

The error you are seeing means what it says on the tin. The loop where you are reading data takes too long so when you go back to read data the hardware buffer has overflown. If you have set your VI up exactly as the one you have posted except with continuous sampling selected I am not sure what is slowing the loop down. As a general rule it is good practice to not do any signal conditioning in your data read loop. It is better to send the data out in a queue to a data processing loop where you can filter and display your data. (FYI, filtering data is very CPU intensive, as is updating front panel indicators such as graphs with lots of data, if your computer is not very high spec this might be part of the problem).

 

If your data looks different with finite sampling I suspect you are missing data points. between the reads. If this is acceptable stick with finite sampling, you sample data when you can and you avoid these buffer overflow issues. If you want a continuous stream of data you need continuous sampling and will need to fix this error.

 

If I were you I would do the following:

- Generate DAQmx code, read the detailed help for each block it has created to make sure that it is doing what you want

- In your DAQmx loop have as little as possible. Ideally your read vi. If this works reliably start adding extra stuff to your loop, like displaying the data, filtering etc

- If it starts falling over when you are doing stuff with your data, send it to another loop via a queue. Google producer consumer design pattern.

 

Let us know if you are still having problems

 

Niatross_0-1583777322055.png

 

Message 8 of 8
(2,585 Views)