Help for Out of memory issues while saving MATLAB figures
6 vues (au cours des 30 derniers jours)
Afficher commentaires plus anciens
I run a MATLAB script that loads a .MAT file into the workspace and generates plots, saves them as MATLAB figures and .bmp files. The MATLAB script is run based on a daily schedule setup in the control panel "Task Schedule".
During the process of generating plots and saving them, following is the sequence of operations:
1. A new figure window is generated 1. The figure window is maximized. I use a utility for this that I found in the MATLAB user community "File Exchange" 2. Plot or subplots are generated 3. Figure saved as a MATLAB figure 4. Figure saved as a .bmp file
Here is the problem: When the MATLAB script is executed via the schedule, MATLAB stops after saving the first plot as a MATLAB figure. While executing the save command for .bmp file, there is an OUT of Memory error message. However, if I execute the MATLAB script manually, there are no issues in executing all the above steps for 35 plots. So, I fail to understand what is driving this error.
2 commentaires
Jan
le 20 Mai 2011
Please show the code, at least the command for saving to a BMP. Post a copy of the error message also. Can you determing the failing line using "dbstop if error"?
Do you close the figures after saving?
Réponses (1)
Jason Ross
le 7 Juin 2011
Task Scheduler jobs are run at a lower priority than interactive use. You can up the priority by editing the XML of the task in question. It also looks like Microsoft introduced the concept of "memory priority" in Vista and later, which makes the scheduled tasks prefer virtual memory.
If you google around, there are a number of workarounds to make your process work the same way as an interactive one.
I don't know if this is what's stopping you, but it seems like the task scheduler environment and normal desktop environment are different in terms of what they allow programs to do, since you can run more plots with the desktop mode.
3 commentaires
Jason Ross
le 13 Juin 2011
A number of things come to mind:
1. The service context in Windows XP allows you to check a tick box that says "allow this service to interact with the desktop". Is that checked or unchecked for Task Scheduler? WARNING: This behavior changes in Vista and higher, so don't rely on this to fix your problem. Although the tick box still exists, it doesn't do anything.
2. It's possible that calls you make on the remote machine that rely on the screen being available are returning nonsensical responses when the desktop is locked. I've definitely seen this happen before where a query to get the screen geometry that might expect something like "1280x1024" will return "0x0" or some negative number, which then confuses anything that expects a screen present. Although there may not be a way to effectively work around this, you might be able to at least determine if the screen is locked and handle the error more elegantly.
3. The XML thing may have been an enhancement for Vista that did not exist in XP, as I know MS made extensive changes to the way in which services interact with the desktop to support UAC to increase security, as noted in #1.
Voir également
Catégories
En savoir plus sur Printing and Saving dans Help Center et File Exchange
Community Treasure Hunt
Find the treasures in MATLAB Central and discover how the community can help you!
Start Hunting!