sudden stop of File writing

[WWolf78]

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

or

stopped during writing the name

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

[crossrulz]

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.

[WWolf78]

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

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

[WWolf78]

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

[James_W]

---

@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

[WWolf78]

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:

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

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:

so no delay which could accumulate..

[JÞB]

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.

[WWolf78]

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

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

[wiebe@CARYA]

---

@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...

[billko]

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.