Error 1 at Get File Size

[Olly85]

Thanks, will implement those changes now. Did that get rid of the bug though??

[Olly85]

Ok,

So I've tidied up the code and placed almost all the functionality inside the FGV. The bug is still present though...

Any more ideas???

Is anyone else replicating the bug which I am seeing??

Thanks,

Olly

[GerdW]

Please post your current VIs. What do you mean by "almost"?

Please include all file ref handling in the FGV. And I would also advise to include some sanity checks in the FGV, e.g. check for invalid references on each "Get" call…

[Olly85]

I'll upload the current VIs shortly, been working on the code in the project so need to port it over and get it checked again.

I have moved ALL file ref handling inside the FGV. What I meant by almost was I have left out code that is handling the writing to the log.

I have put code in to check for an invalid reference and it occurs when the error does. But that doesn't really solve my problem, it would just provide a poor work around (i.e. create a brand new file everytime the reference decides it wants to give up).... why is a reference becoming invalid when I am switching from the subVI back to the main application? Why does it only happen when I log multiple lots of data from the subVI?

There is something strange going on here I just can't put my finger on. Have you been able to replicate the behaviour I am encountering or is it just me...?

Thanks,

Olly

[GerdW]

Hi Olly,

I have been replicating the error, but no time to investigate it. (As having work of my own.)

Now I'm waiting for your reworked VIs…

[rolfk]

LabVIEW has a somewhat special way of dealing with refnums. It remembers in whose top level hierarchy a refnum was opened and when that top level VI goes idle (stops executing) then the refnum will be automatically closed. This is most likely your problem. You have probably a code section that starts, does all kind of initialization including your file refnum, then launches your main program as top level VI and after that quits itself. This can't work.

You have to make sure that the Top level VI in whose hierarchy the refnum was opened stays active for the entire time you want to use that refnum. Since you are using an FGV to manage your file IO, this probably is most easily done by only initializing the file name in your initialization sequence, and let the VI in the actual logging case check for Not A refnum for the file refnum. If that function returns true Open the refnum with the path you stored during initialization and do your thing then store the refnum in the shift register. If the Not a Refnum is false, skip the File Open function.

[Olly85]

Rolfk,

That sounds like the answer! From what I've been seeing that would explain the behaviour perfectly!

Many thanks, will have a go at modifying the code and let you know how I get on!

Olly

[Olly85]

Success! Kind of!

rolfk, it looks like you are right, but I feel I'm still missing a part of the puzzle....

So my FGV now initially checks if it is a valid refnum, if not it takes the file path and reopens the connection and stores the new refnum. It works, but not straight away. After I go back to the main application it will fail to log any data (though it doesn't report any error anywhere), then after x amount of attempts it will suddenly spring into life and start logging.

Is there some sort of delay before I can reopen a file or something? It seems a little strange that it doesn't work and then just starts all of a sudden...

Will upload a demo of it shortly...

Thanks for your help 🙂

Olly

[Olly85]

Ok,

So here's an updated version of the code. Like I said above, it kind of works, except that when you initially return to the main application it doesn't seem to be logging for the first couple of attempts...

Any ideas anyone?

Thanks,

Olly

Code attached is LV2014 & LV2011

[Olly85]

Fixed (finally). Forgot I needed to set file position to end.

Time to relax for a while 🙂

Thanks all for your help