Jump to content

Does a vi sleep at night?


Recommended Posts

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

Link to comment

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.

Link to comment

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

Link to comment

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

Link to comment

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?

Link to comment

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

Link to comment

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

Link to comment

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

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

Link to comment

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.

Link to comment

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

Link to comment

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

Link to comment

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

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.

Link to comment

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

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

Link to comment

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

Link to comment

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

Link to comment

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?

Link to comment

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.