12-09-2018 04:51 PM
Hi!
I have a problem when acquiring the information, in my VI it is required to take the analog voltage signal of 3 instruments with a speed of 10 samples per second. Only that I have the problem when saving the data in excel. Attached the VI, in case someone could help me. I have been trying to solve this problem for 2 months :'' (
12-09-2018 04:53 PM
I am using a cDAQ 9188 with NI 9239
12-09-2018
04:57 PM
- last edited on
05-06-2025
12:00 PM
by
Content Cleaner
I can't open your newer version (I'm only on LV 2016), so please include an older version or a Snippet of your code, so that I can better assist you.
This error is an overflow error, so you're likely assigning too small of a buffer, or not reading the data fast enough.
Cheers
--------, Unofficial Forum Rules and Guidelines ,--------
'--- >The shortest distance between two nodes is a straight wire> ---'
12-09-2018 04:59 PM - edited 12-09-2018 05:00 PM
@JoseGo94 wrote:
Hi!
I have a problem when acquiring the information, in my VI it is required to take the analog voltage signal of 3 instruments with a speed of 10 samples per second. Only that I have the problem when saving the data in excel. Attached the VI, in case someone could help me. I have been trying to solve this problem for 2 months :'' (
2 months? I'm surprised you hadn't searched the forums for error -200279 or asked for help earlier!
You'll find that error is for a buffer overrun, you code isn't keep up with processing the DAQ data as it comes in. Something in your code is running too slow and that is likely the writing to an Excel file. You would have found the general recommendation is to pass the processing off to another loop using queues in a Producer/Consumer architecture.
12-09-2018 05:03 PM
This is my code
12-09-2018 05:03 PM
I'm really new to this, I have no idea how to fix it
12-09-2018
05:04 PM
- last edited on
05-06-2025
12:00 PM
by
Content Cleaner
@RavensFan wrote:
You would have found the general recommendation is to pass the processing off to another loop using queues in a Producer/Consumer architecture
RavensFan is likely correct that your file I/O is the issue.
Edit: Yup, looking at your code, you need to separate the File I/O from the acquisition, otherwise the acquisition will always overflow since it is much faster than the File I/O.
Here's some info about the Producer/Consumer architecture:
The Producer/Consumer architecture is based on a producer loop adding data to a queue and the consumer loop dequeueing the data. The process-intensive or time-hogging code goes in the consumer loop to free up the producer loop to run at the speed you need it to run.
For example, you have code that acquires data every 100ms and needs to write that data to file. It takes 50ms for the acquisition code to run and 80ms for the write-to-file code to run. Uh Oh! You're now taking 130ms per loop and your application is backing up. Now you move the write-to-file code to a consumer loop and enqueue data to it from your producer loop. Voila! Your 50ms code and 80ms code run in parallel and can both keep up with the 100ms period.
Here's an example:
Cheers
--------, Unofficial Forum Rules and Guidelines ,--------
'--- >The shortest distance between two nodes is a straight wire> ---'
12-09-2018 05:08 PM
This is my VI
12-09-2018 05:26 PM
Right, so please adapt your VI to operate the same way as my example given above.
You have a single WHILE loop including both acquisition and file I/O, so you need to separate out the File I/O so the acquisition isn't slowed down. This is just good programming practice even if your File I/O is fast enough.
You could also white chunks of data at a time to File I/O instead of every single data point. I don't have the correct add-on installed to see your Express VI configurations, but potentially you can tinker with those.
Cheers
--------, Unofficial Forum Rules and Guidelines ,--------
'--- >The shortest distance between two nodes is a straight wire> ---'
12-09-2018 08:12 PM
I managed to acquire the amount of data required (10 samples / second). Only that there is a delay between the physical measurements and the data that I acquire. For example, my LVDT changes 1.1 in to 0.5 in, while the numerical value of labview is still 1.1 in.