Does a vi sleep at night?

[Raymond Tsang]

Hi LAVAs!

I've a monitor program for some motors. Basically, it stops the motors when there's an error, and logs the status of the motor every 1 sec.

When I ran it overnight, and checked the logfile next morning (while it was still running), I found that there is a 13 hour interval with no data recorded. Apparently, the data logging resumes after I come back.

I've checked the hibernation/standby setting in Windows and it was set to be Always On.

I've attached the screenshots of the simplified version of my programs here.

Thanks in advance for any comments!

Raymond

[LAVA 1.0 Content]

Is the (network) drive available during the night?

You could try the same approach to log data on the FP (once every 15 minutes or so)

Maybe your computer is set to hibernation by some group policy?

Do you log the user off? (or does this happen automatically?)

Ton

[Raymond Tsang]

QUOTE (Ton @ Aug 20 2008, 05:18 PM)

Is the (network) drive available during the night?

You could try the same approach to log data on the FP (once every 15 minutes or so)

Maybe your computer is set to hibernation by some group policy?

Do you log the user off? (or does this happen automatically?)

Ton

Thanks for your reply!

1. this is the local drive.

2. what is FP?

3. i've checked the settings on the screensaver page. i guess that's the only place i can set hibernation policy, right?

4. no. when i came back to the computer, the user is still logged in.

[JiMM]

QUOTE (Raymond Tsang @ Aug 20 2008, 02:13 PM)

Thanks for your reply!

1. this is the local drive.

2. what is FP?

3. i've checked the settings on the screensaver page. i guess that's the only place i can set hibernation policy, right?

4. no. when i came back to the computer, the user is still logged in.

FP=Front Panel

[Raymond Tsang]

QUOTE (JiMM @ Aug 21 2008, 02:18 AM)

FP=Front Panel

OK. Thanks, JiMM!

I will try to write the log to a text field on the front panel. (i suppose this is what you suggest, Ton?)

[giopper]

QUOTE (Raymond Tsang @ Aug 20 2008, 08:13 PM)

...

3. i've checked the settings on the screensaver page. i guess that's the only place i can set hibernation policy, right?

...

What about some power saving settings

(e.g. switch off the hard disks) in the BIOS?

Do you get any error message from LV?

G

[Raymond Tsang]

QUOTE (giopper @ Aug 21 2008, 07:17 AM)

What about some power saving settings

(e.g. switch off the hard disks) in the BIOS?

Do you get any error message from LV?

G

Let me check the BIOS.

I got a "Generic File IO error" from LV.

[Maca]

QUOTE (JiMM @ Aug 21 2008, 04:18 AM)

FP=Front Panel

I obviously spend waaaaay too much time using RT as I read this as compact Field Point, but front panel makes much more sense.

It seems like a very interesting problem.

Just a thought, but you stated that you checked the hibernation settings on the power options page accessed through the display properties page. did you also check that "system standby" and "turn off hard disks" on the "power schemes" tab were both set to never?

As to the group policys concern that a fellow member has raised, is your computer part of a domain?

[crelf]

QUOTE (Raymond Tsang @ Aug 20 2008, 08:49 PM)

I got a "Generic File IO error" from LV.

Is you disk set to power down after a timeout? (ie: powersave) Can you post the code? Or at least a screenshot of the general area where the error is generated?

[Raymond Tsang]

Thank you all for your comments!

1. I've checked that all the stuff hibernation/powersave/hdd turnoff/... are set to never.

2. My computer is not in a domain.

3. i didn't try to write to FP, but if i disable file io at all, it runs smoothly.

In fact, I have just successfully run the vi overnight (20+ hours). But the computer has become very irresponsive.

I checked the task manager to see that labview is using >110MB of RAM. Does it look like a memory leak or sth like that?

Are there any memory leak checkers (like Valgrind) for LabVIEW?

Ray

[Raymond Tsang]

I think the problem i have is memory leak.

I turned off (using a case structure wired with a FALSE) each component of the vi one by one and look at the "Profile performance and memory" found that, the leak comes from a "Cluster to Array".

Now the problem is how to convert a cluster to an array without using "Cluster to Array"??? :headbang:

Puzzled Ray

[Francois Normandin]

QUOTE (Raymond Tsang @ Aug 21 2008, 08:47 PM)

I think the problem i have is memory leak.

I turned off (using a case structure wired with a FALSE) each component of the vi one by one and look at the "Profile performance and memory" found that, the leak comes from a "Cluster to Array".

Now the problem is how to convert a cluster to an array without using "Cluster to Array"??? :headbang:

Puzzled Ray

What is the history length of your "Load Cell2" waveform graph? Could that be the reason your vi is becoming sluggish as you add more points?

http://lavag.org/old_files/monthly_08_2008/post-10515-1219368951.png' target="_blank">

I would be surprised to discover a memory leak in Cluster to Array.

[Raymond Tsang]

QUOTE (normandinf @ Aug 22 2008, 10:33 AM)

What is the history length of your "Load Cell2" waveform graph? Could that be the reason your vi is becoming sluggish as you add more points?

http://lavag.org/old_files/monthly_08_2008/post-10515-1219368951.png' target="_blank">

I would be surprised to discover a memory leak in Cluster to Array.

Even if I unwire the graph, the leak is still there.

In fact I found whenever I convert the cluster into a string for writing to file in "datalogger", i have a memory leak in the "main program" as seen in "profile performance and memory". I tried the following things:

1. Unbundle cluster, cluster to array, array to spreadsheet string

2. Unbundle cluster, format string

3. Cluster to array, array to spreadsheet string, concatenate strings

4. Number to fractional string, concatenate strings,

and other permutations.

All leaking...

Is the passing of a cluster to the datalogger from the main program causing it?

Ray the Leaker

[Francois Normandin]

Could you post your VIs? (Not just screenshots)

Maybe we can find an explanation if we try it first hand...

[Raymond Tsang]

QUOTE (normandinf @ Aug 23 2008, 06:53 AM)

Could you post your VIs? (Not just screenshots)

Maybe we can find an explanation if we try it first hand...

Many thanks!

Here it is. This is the unsimplified version.

[Francois Normandin]

I had to put all the FlexMotion VIs in a "Disabled Diagram"... other than that I've run your VI with a log every 2ms (500Hz) to simulate an accelerated night's worth of data.

So far (11:37AM the next day in simulated time, as I write these lines), I don't have any memory increase and the logfile is over 3.2MB already. (>70 000 lines) This would be 19 hours of data at 1Hz acquisition.

If your logfile is limited to a few MBytes, than I would suggest the problem lies in the FlexMotion VIs.

Use simulated data (I use the "random number" function) to replace your FlexMotion VIs outputs. If you strip the Flex VIs and still get the memory leak, then it is either system specific or you have another program/service interfering.

Sorry buddy, but there's not much more I could do at this point.

[Raymond Tsang]

QUOTE (normandinf @ Aug 23 2008, 06:44 AM)

I had to put all the FlexMotion VIs in a "Disabled Diagram"... other than that I've run your VI with a log every 2ms (500Hz) to simulate an accelerated night's worth of data.

So far (11:37AM the next day in simulated time, as I write these lines), I don't have any memory increase and the logfile is over 3.2MB already. (>70 000 lines) This would be 19 hours of data at 1Hz acquisition.

If your logfile is limited to a few MBytes, than I would suggest the problem lies in the FlexMotion VIs.

Use simulated data (I use the "random number" function) to replace your FlexMotion VIs outputs. If you strip the Flex VIs and still get the memory leak, then it is either system specific or you have another program/service interfering.

Sorry buddy, but there's not much more I could do at this point.

You don't have to be sorry! I really appreciate your help and of course your time and effort to try out my program!

Now I have ruled out memory leak as the cause, because i don't see any more memory usage increase over time, using "profile performance and memory".

I tried to run the program overnight again. The File IO error occurred, as always, around midnight 12am to 1am, which is a common time when people surf the net before going to sleep. So I suspect that maybe somebody is using VNC or other stuff connecting to the DAQ computer.

As to whether the problem is system-specific, I will run a disk check... or what else do you think of?

Desperate Ray

[giopper]

QUOTE (Raymond Tsang @ Aug 20 2008, 12:20 AM)

...

and logs the status of the motor every 1 sec.

Hi Raymond,

in your subVI "logger(TXT)" you open the log file,

point to its end, write the new data and close it.

You do this operations each time the subVI is called,

which probably means every second.

Although it shouldn't be a problem,

I suggest to move the "open" before the main loop

and the "close" after exiting the main loop.

In fact, you do not need to open/close the file

each time you have to write new data:

you can open it once at the beginning and

pass the file reference to the subVI which

will be used to write the data every second.

The file will be accessible anyway

(e.g. with a text editor like Notepad)

even when it is already opened by LV.

When you stop the main loop, then you close the file.

Probably this is not related to your "file IO error"

but still I would avoid to open/close every second.

G

[Raymond Tsang]

At last, I managed to capture a screenshot of the error..

It looks like a LabVIEW internal error... Any idea what this means?

Ray

[Francois Normandin]

QUOTE (Raymond Tsang @ Aug 24 2008, 06:12 PM)

Just to confirm... How do you check that there is no memory increase?

I simply monitored it in the Task Manager. It's not perfect because it monitors everything else along with LabView, but if you had a reference of some kind that was opened repeatedly and never closed, you'd have had an increase in system memory usage.

QUOTE (giopper @ Aug 23 2008, 10:18 PM)

Although it shouldn't be a problem,

I suggest to move the "open" before the main loop

and the "close" after exiting the main loop.

I agree. And when writing to file, the file position will automatically be at the end of what you just wrote. Hence, no need to tell the file to go at the end, except if some other program could access this file at the same time and set position differently.

[LAVA 1.0 Content]

QUOTE (giopper @ Aug 24 2008, 04:18 AM)

Probably this is not related to your "file IO error"

but still I would avoid to open/close every second.

Maybe this will prevent any resource to close the file.

QUOTE (Raymond Tsang @ Aug 25 2008, 12:12 AM)

At last, I managed to capture a screenshot of the error..

Error 6 is a 'Generic File IO'

You should disable any anti-virus, scheduling software, screensaver, energy saver utility. Disconnect the PC from the network.

And sit with the PC while the program crashes. If it happens you should look for any new processes started.

Ton

PS Perfmon can give you the memory usage over time of any process, it is included on every windows PC

[Raymond Tsang]

QUOTE (normandinf @ Aug 23 2008, 07:44 AM)

I had to put all the FlexMotion VIs in a "Disabled Diagram"... other than that I've run your VI with a log every 2ms (500Hz) to simulate an accelerated night's worth of data.

So far (11:37AM the next day in simulated time, as I write these lines), I don't have any memory increase and the logfile is over 3.2MB already. (>70 000 lines) This would be 19 hours of data at 1Hz acquisition.

If your logfile is limited to a few MBytes, than I would suggest the problem lies in the FlexMotion VIs.

Use simulated data (I use the "random number" function) to replace your FlexMotion VIs outputs. If you strip the Flex VIs and still get the memory leak, then it is either system specific or you have another program/service interfering.

Sorry buddy, but there's not much more I could do at this point.

Which version of LV did you used?

Can you try really running it for say 10-12 hours at 1Hz? I also had no problem in "accelerated" data taking.

Really appreciate your help!

Ray

[Götz Becker]

QUOTE (normandinf @ Aug 25 2008, 02:54 AM)

I simply monitored it in the Task Manager. It's not perfect because it monitors everything else along with LabView ...

This is one of my common usecases for the Process Explorer it shows the CPU and memory consumption of single processes (along with many other nice info).

[Raymond Tsang]

QUOTE (Götz Becker @ Aug 28 2008, 10:22 PM)

This is one of my common usecases for the Process Explorer it shows the CPU and memory consumption of single processes (along with many other nice info).

Nice info!

However, I guess I already know where exactly the memory leak is. It leaks whenever I convert a number to a string, which I cannot avoid.

I guess it may be a bug in LabVIEW 8.5, although unlikely?

Do you guys think the memory leak will go away when I compile it as an application?

Ray

[Chris Davis]

QUOTE (Raymond Tsang @ Aug 29 2008, 03:59 PM)

However, I guess I already know where exactly the memory leak is. It leaks whenever I convert a number to a string, which I cannot avoid.

Error 6 is often associated with a network share being unavaliable when trying to write to it. Are you by chance writing this file to a network share?