I just loaded a very large file (over 1200 solids) in X5 MU1, shaded it, and rotated it. When first loaded Mastercam was using about 1.3GB. After shading it went up to 1.6GB. Rotating did not affect the memory usage at all. I then turned shading off and tried rotating and I did observe a slight memory leak. I suppose it would be enough to cause problems over time but it does not seem to be nearly as large a leak as what you are seeing. Are you running any third party apps with Mastercam?

What version of Mastercam are you using? There was a problem in X4 (I think prior to MU3) that was creating permanent views instead of temporary ones while rotating and eventually it would hit the max number of views allowed. I am not sure if that would even explain the amount of memory increase that you are seeing. The other question I have is if this is only happening with a specific file or files? This sounds like a memory leak but I have not seen any memory leaks associated with just rotating a part like this. If it is file specific could you please send ne a copy of a file that is causing the problem.

Mastercam does not do any swapping to disk. Starting with X6 (released about 4 months ago), Mastercam does now have a 64 bit version that will allow you to access as much virtual memory as is available on the system. The 32 bit versions of Mastercam (pre-X6) are LARGEADDRESSAWARE and according to Microsoft documentation you should automatically have access to the full 4GB that a 32 bit applcation can address on Vista and Windows 7. If you are only getting 3GB there may be a Windows setting on your system that is limiting it to 3GB. It is a bit tricky to set this. My recommendation would be to upgrade to X6. I would also recommend upgrading to Windows 7. In my humble opinion, Windows 7 is what Vista should have been.

It's a bit hard to say if RamSaver would help in every case. RamSaver will free the memory used by the database, display list, undo, and a few other things. There is the posibility of having memory fragmentation or even some memory leaks in some areas. Exiting Mastercam and restarting it would clean that up. I would have to look at some specific examples in the debugger to see exactly what is happening.

Don't confuse virtual memory and physical memory. Adding physical memory will give you better performance but it will not give a 32 bit application (such as Mastercam prior to X6) access to more memory space. There is a setting in Windows for virtual memory but by default it is managed by Windows and grows as needed. 32 bit applications are limited to 2GB of address space or 3GB if it is Large Address Aware, which Mastercam is. On 32 bit Windows you have to set a boot switch to get the extra 1GB but on 64 bit Windows you get it automatically. The PK error you are seeing is actually coming from Parasolids but as someone alluded to, the amount of memory being consumed could have something to do with the undo data. There is a setting in System Configuration - Start/Exit to limit the undo by number of transactins or amount of memory. By default this is not enabled. Use this with some caution because it could keep you from being able to undo. The RamSaver function really does nothing more than save the file and then reopen it. It does clean up the database memory being used and frees the undo memory. You should be able to use RamSaver (or save and reopen the file) in lieu of limiting the undo.

The only thing you have to do to allow Mastercam to use 3GB on 32 bit OS or 4GB on 64 bit OS is set the option in the boot.ini file. Mastercam is already LARGEADDRESSAWARE, since X4. We had to make some internal changes before we could allow this and that was done in X4.

Could you send me a copy of the file you are trying to save as V9? I don't know of any problems saving X3 to V9. Maybe there is something specific to this file, especially if you can't save to IGES and Parasolid either. Thanks,

All, Thanks to some help from Greg and a couple files that he sent to me to look at, we were able to figure out the problem. It appears that there was a bug prior to X4 that was causing a "default" bookmark to be saved in the file for the Main Sheet. In X4 there was a new viewsheets options page added to Config (which everyone on this thread seems to know about now). On this page "Automatically restore bookmark settings" defaults to enabled which is causing the bogus Main Sheet bookmark to be used. The workaround is to disable viewsheets, disable "Automatically restore bookmark settings", or after opening the file set the levels you want on the Main Sheet, save a bookmark, and save the file. Note that this is going to be a problem with pre-X4 files even after X4 because there is no way to know if the bookmark is valid or the one created by the bug that was fixed in X4. Files that are saved in X4 will not have this problem in future releases. Sorry for the inconveience.

Greg, Thanks for the files, but what you sent to me had already been saved in X4. I did not have any problems with changing visibility of levels, saving the files, and having them come back in with the saved visibility in either X4 or X4 MU1. If you have the pre-X4 version of these files I would be more than happy to look at them. >> Which other settings are affected? I am getting nervous about this one << Here is a little explanation fo the problem. I hope it is not too techie. The problem is related to view sheets. There is always a base view sheet saved in the file even if you are not using view sheets. In X4 we added additional values that are saved with the view sheets and made some additional changes for how they get initialaized, which ended up causing these problems with files that were saved without the additional settings. View sheets in X4 save / restore all of the settings on the Status Bar. Depending on what pre-X4 version the file was saved in, any of these settings could be affected. Regards,

Greg, Sorry for the inconvenience. This problem was found too late to get the fix into X4 but it has been fixed in the maintenance release we are working on now (X4 MU1). Unfortunately the only work around is to open the file, set the levels you want (you should check other settings too because this affected more than just levels), and then save the file in X4. Of course if you still need to use the file in the previous version and make changes there this is not an optimal work around. Would it be possible to get a copy of one or more of the files that you are having problems with to make sure our fix covers the cases you are seeing? Thanks, Joe

Just as a follow up on this problem. I was able to reproduce the crash in X3 using the file that gcode uploaded. However it was crashing in a module supplied to us by a third party so I could not tell the exact cause. It does not crash in the X4 release that we are currently working on.

We have been seeing a lot of crashes in the nVidia OpenGL drivers. We did a little data mining on our crash reports and see specific versions of the drivers that crash a lot more frequently than others. Whenever I see a crash report like this and there is an email address supplied I ask them to do the following: 1. First you should try getting a driver update either directly from nVidia or from the manufacturer of your system. 2. If that does not help, in the nVidia Control Panel, try setting the 3D Settings profile to Dassault Systemes SolidWorks. This seems to work in 99% of the cases. The other thing to check is how much memory you have on your graphics card. We document a minimum requirement of 128MB. You can get by with less if you run at very low resolution.

There is no concept of the undo buffer filling up. There are limits on how big the undo buffer will get that you can set in configuration. When it hits the limit it will bump items off the bottom of the list to make room for new undo items. If you are actually running out of memory trying to run some process, exiting Mastercam and restarting will defintely clean up memory usage, including the space used for undo. As an alternative to exiting you could go into config and either turn undo off or lower the limit for how much space undo will use. Joe McCollough Systems Group Manager CNC Software, Inc.