LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

sudden stop of File writing

Solved!
Go to solution

Hello Together,

 

I've searched the Forum but didn't find any solution, so here's my Issue:

 

I'm having a quite large QMH which logs every change in an Logfile via Logfile VI, which is a small modification from the Boiler example

(sorry for not posting the whole VI, as this is very large)

 

Problem:

suddenly the VI Stops wring during writing:

(see incomplete content)

 

stopped during writing the time stamp

WWolf78_0-1643027022093.png

 

or

 

stopped during writing the name

WWolf78_1-1643027045235.png

 

 

I use this VI ONLY within Cases of the message handler loop, so the VI can't be called parallel:

 

WWolf78_2-1643027142844.png

 

 

at the end of the Logfile VI I save the refnum back in the MHL Custer, whereas the information is kept in a shift register

WWolf78_3-1643027243732.png

 

 

previously I had similar problem were my consumer loop was sending very much queues within a short time, but I fixed this with smaller delay, but this problem is new.

 

I'm additional confused, as the Logfile VI can't called parallel and the error line is passed through the vi, and the refnum is forwarded.

 

maybe the problem is located by fast acces and Windows accessing the file, but I don't know how to check this

 

any suggestions?

 

 

LV 2015, SP 1

Win 10 Enterprise,

Intel Core 7, 3GHz, 16.0GB RAM

 

0 Kudos
Message 1 of 27
(465 Views)

Where does that file refnum get closed?  I'm guessing it closes as soon as any of your loops stops.  It would then be possible that the file was closed right when the Write File function was called.  We would need to see a lot more of your code to do a proper diagnosis.


GCentral
There are only two ways to tell somebody thanks: Kudos and Marked Solutions
Unofficial Forum Rules and Guidelines
"Not that we are sufficient in ourselves to claim anything as coming from us, but our sufficiency is from God" - 2 Corinthians 3:5
0 Kudos
Message 2 of 27
(446 Views)

the "close file" is only in the exit Case:

WWolf78_0-1643031714347.png

 

 

as mentioned before, the refnum is in the cluster which gets stored in the shift register in the MHL Loop

0 Kudos
Message 3 of 27
(443 Views)

additional: the access to the logfile is only within this VI, nowhere else

and within this VI the refnum is stored back in the cluster

0 Kudos
Message 4 of 27
(436 Views)

@WWolf78 wrote:

 

Problem:

suddenly the VI Stops wring during writing:

I use this VI ONLY within Cases of the message handler loop, so the VI can't be called parallel:

at the end of the Logfile VI I save the refnum back in the MHL Custer, whereas the information is kept in a shift register

previously I had similar problem were my consumer loop was sending very much queues within a short time, but I fixed this with smaller delay, but this problem is new.

I'm additional confused, as the Logfile VI can't called parallel and the error line is passed through the vi, and the refnum is forwarded.

maybe the problem is located by fast acces and Windows accessing the file, but I don't know how to check this

any suggestions?

 

LV 2015, SP 1

Win 10 Enterprise,

Intel Core 7, 3GHz, 16.0GB RAM

 


Maybe it's not a sudden stop?
Maybe it a sudden accumulation of the small delays causing you a big delay?
(Can't see the code so can't comment).
but if the delay is based on the ms timer 😉 you'll have the potential for some great fun if you're not careful (about every 50 days after PC restart).

James

CLD; LabVIEW since 8.0, Currently have LabVIEW 2015 SP1, 2018SP1 & 2020 installed
0 Kudos
Message 5 of 27
(423 Views)

Hi James W,

 

sorry, I'm too deep in my code, so I missed explaining this issues:

 

for my logfile and the user I regularly send messages to the MHL, like this one:

WWolf78_1-1643034619894.png

 

by communicating to an external system I get 1 message every 20ms, which I read and storage within an array:

 

 

WWolf78_0-1643034582073.png

 

last Time I had an Message VI within this  loop, which caused the previous error.

Solution thereby was to put an Message before and after the "data acquisition" loop and adding smaller delay in this way:

 

WWolf78_2-1643034795596.png

 

so no delay which could accumulate..

 

0 Kudos
Message 6 of 27
(406 Views)

How do you limit the log file size?

 

~~~~\Oh, magic 8-Ball, does the sudden stop happens when the log file hits 2Gb?~~~~~

 

It is decidedly so.


"Should be" isn't "Is" -Jay
0 Kudos
Message 7 of 27
(394 Views)

there's no limit but it seldom exceeds 5mb:

 

WWolf78_0-1643037379891.png

 

the system creates an logfile on every start, even for tests, so some files are 2kb.

the longer tests (with the failed writing) are the larger ones, but stil between 2-5mb

 

0 Kudos
Message 8 of 27
(390 Views)

@WWolf78 wrote:

additional: the access to the logfile is only within this VI, nowhere else

and within this VI the refnum is stored back in the cluster


If the reference is first stored in a VI that stops running, the reference will become invalid. Even if the buffer never stopped running.

 

Any (native LabVIEW) reference becomes invalid when the top level data space where it was created stops running.

 

A quick hack would be to test the reference, and reopen the file if the reference became invalid. Or to simply always open\write\close...

0 Kudos
Message 9 of 27
(384 Views)

I'm guessing that your timer eventually gets out of sync with your messages and you start catching only parts of the message.  Might want to re-think your communications - e.g., if the messages come in every 20 ms, just wait for a message instead of trying to sync with the message timing.

Bill
CLD
(Mid-Level minion.)
My support system ensures that I don't look totally incompetent.
Proud to say that I've progressed beyond knowing just enough to be dangerous. I now know enough to know that I have no clue about anything at all.
Humble author of the CLAD Nugget.
0 Kudos
Message 10 of 27
(376 Views)