Data save from loop extremly slow

[LuluBono]

Hi everyone!

This is a very easy question for hc labviewers:

I hav this .vi attached, but it's very bad written. (I hav no time to write a better one now.)

The problem is that after a while it's becoming extremely slow, I guess becasue it's writing to an .lvm data file in every loop (at the end of the block diagram: picture)

http://s30.postimg.org/ag8dejn9b/image.png

Sadly I'm a beginner  and I don't know how to save data after every 10.000 loop at once (I think a case structure and an array needed), which would reduce my measurements from 3 hours to 10 min, it's like 168.000 data.

[LVCoder]

Is the new data appended to the same file or is it saved in a new file?

[LuluBono]

To the same file as it's part of the whole time series, but if it's much easier to write to another file than I'm okay with that.

[Hooovahh]

Writing to disk is a very non-deterministic operation.  You have no way to know how long it takes to write your data no matter how large or small.  You are at the mercy of Windows and you hardware.  If you have a platter style hard drive, it may need a few seconds to spin up.  This is likely not your problem but an example of how you can't control how fast this operation happens.

That's why most developers have logging in a separate running loop which is asynchornous from the rest of the application.  Most choose a producer consumer loop with a queue or user event to signal data to log.  This can also help do other things like you already mentioned where you can tell the consumer to log every second, but maybe it holds 30 seconds of data into memory, then dumps it all at once.  This will also reduce the total amount of time it would take to log, since this one write will be faster than 30 single writes.

Also using an express VI for writing to disk is quick and easy, but it is not efficient and a better way is to use the file primatives which keep the file reference open throughout the test, instead of opening it and closing it with every write.

But honestly, that code is bad, and shouldn't be used for anything.  It is not documented, it has no way of stopping, it has at least one loop which will starve the CPU taking 100% usage for no reason.  It has far too many un-needed property nodes.  And several style issues that would make modifying it a very unpleasent task.

I would highly suggest taking some free training to learn more.

NI Learning Center

NI Getting Started

-Hardware Basics

-LabVEW Basics

-DAQ Application Tutorials

3 Hour LabVIEW Introduction

6 Hour LabVIEW Introduction
Self Paced training for students
Self Paced training beginner to advanced, SSP Required
LabVIEW Wiki on Training

[LuluBono]

Thanks for your reply.

I agree with u, but sadly I still hav to measure with it  for 8-9 times a 60 sec long period, and I want to do it as fast as it is possible, without rewriting it completly or work for days for a better one.

For now I just need a way to make it a little bit faster.

[Hooovahh]

---

@LuluBono wrote:

I want to do it as fast as it is possible, without rewriting it completly or work for days for a better one.

For now I just need a way to make it a little bit faster.

---

Not trying to be mean but you have to show an effort.  If you don't have time to work on it, then neither do we.

[LuluBono]

Yes, you're right, I'm not expecting anyone to work instead of me, (and meanwhile I'm trin to find the right solution) I just posted in hope someone faced with the same problem and can give me a quick tip, without any energy investment, as I always do if I see a question and I know the answer immediately.