LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

How to append data to save file without overwriting? Using create file / write to file / close file

Solved!
Go to solution

Hello,

 

I assume this is a relatively trivial task; however, I cannot seem to figure this one out. I've tried adding a set file position to end between the create and write to, removing the close file, and several other things I could think of to no avail. The program takes three sets of experiments from the for loop with N wired to the "How many scans?" control, but the output file never has more than one set of data inside. 

 

Have attempted to change to write to delimited spreadsheet function as well; however, it never even adds data to the file in my current set up, just replacing the write to file within the for loop. Would rather add appending using this setup (create/write/close) than attempt to use this function.

 

**The code is within stacked sequence 5. I'll attach the main VI as well as the subVI which creates the file. Sorry in advance for spaghetti wiring.

Download All
0 Kudos
Message 1 of 24
(2,921 Views)

Hi.

I can't open your vi as i'm still on LabVIEW 2016.

However the problem you explain seem to be just a bad setting of the function. Could you save it in LabVIEW 2016 so i can check it ?

0 Kudos
Message 2 of 24
(2,903 Views)

Thanks for the reply, there are two loops I have implemented for this, one pretty much encapsulates all the code, which is supposed to create more than one file if greater than one. The other loop, only goes around the portion of code which collects data, and is post creation of the file. How do I save as 2016?

 

Edit: Looks like I can save as 2016 using the save as previous option; however, I will be recording data for about an hour. If I can revert it before I go for lunch I'll post the code in 2016 in about an hour or so. 

0 Kudos
Message 3 of 24
(2,898 Views)

Hi.

It's seems in didn't edited my answer fast enough for you to see the correction. Could you save your vi in LabVIEW 2016 so i can open it ?

 

Edit : Ok, i saw your edit. I'll wait for it.

0 Kudos
Message 4 of 24
(2,891 Views)

I just edited my last response, check above. Sorry about that. 

0 Kudos
Message 5 of 24
(2,886 Views)

See if these work. I believe they're 2016 now.

Download All
0 Kudos
Message 6 of 24
(2,873 Views)

@etvg wrote:

 

however, it never even adds data to the file in my current set up, just replacing the write to file within the for loop. Would rather add appending using this setup (create/write/close) than attempt to use this function.

 


Nobody here is willing to look at code with deeply stacked sequences full of local variables and with the labels of terminals and value property nodes hidden. Is this intentionally obfuscated?

 

I still give it a try:

  • If you keep the file open, you don't need to set the file position to the end, this will happen automatically.
  • You only conditionally write to the file (There is a case structure around it!), so we need to know about a few things:
    • What are the values of the value property nodes and thus the resulting boolean wired to the case at each iteration of the loops?
    • Note that there is a glaring race condition where "loop it 2" gets a new value and you read from a value property node of that same indicator in parallel. Not even the compiler team at NI will be able to tell you what will happen first, but the outcome critically depends on the execution order. Why not eliminate the value properties and use a plain wire?
    • Similar problem exists everywhere, e.g. you write to the waveform|reference terminals and to local variables of these same terminals (what a waste!!!!!) while you are reading local variables of these terminals in two other places in parallel! Race conditions galore!

If you want to solve this, create a tiny example that only does the file writing and test until it works correctly. If you can't get it to work, ask here for help. Nobody want to use a machete to try to get through the jungle of the current code.

Message 7 of 24
(2,861 Views)

Interestingly enough that case structure is from the inherited code and actually doesn't even do anything. It's hooked to a Rube Goldberg false constant. As for the values of the property node values, I'll have to get back to you on that as I am currently collecting data on that code and only have legacy code which isn't entirely the same on another machine. Surprisingly the code doesn't have any errors from race conditions in it's current state. 

0 Kudos
Message 8 of 24
(2,854 Views)

@etvg wrote:

Surprisingly the code doesn't have any errors from race conditions in it's current state. 


Probably because tiny frame shifts are impossible to detect in the data and maybe because of incredible luck that things execute in the order they should. The tiniest edit or recompile (or version upgrade) can of course change this order to the worse!

0 Kudos
Message 9 of 24
(2,850 Views)

@etvg wrote:

It's hooked to a Rube Goldberg false constant.  


If the resulting boolean is always false, nothing would ever get written to the file.

 

0 Kudos
Message 10 of 24
(2,848 Views)