I'm using X5 MU1 and it doesnt seem limited to just one file. I even ruled out the config file. Larger files just make the memory leak faster. And the memory leaks with whatever I do with the interface. Rotating the part was just the first step in my diagnostics and even that caused problems. Making actual changes to the file make the memory leak even faster.

 

I'm not sure what I can do with the interface to stop the problem, because now that it's here, it doesn't want to go away - as if Mastercam did something wrong and corrupted the installation.

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?

I have been having memory issues and crashes lately, and I recently made a discovery: without making any changes to the file that I was working on, the Memory Usage (as displayed in the Task Manager) for Mastercam doubled in a few minutes. There wasn't even any Undo data to save, and I have the limit set to 10 MB. I just orbited around the model for a few minutes and watched as the memory usage climbed. I opened Mastercam and it started out using about 170,000K...I opened my file and it went up to about 215,000K...I orbited the model and the usage climbed to over 400,000K in minutes.

 

When I first pulled up the task manager to begin investigating the cause of insufficient memory, Mastercam was using over 1.4 million KB - over 1 gigabyte with this same model that started at 215,000K. What the heck is Mastercam doing? I've never seen this before in any other program.

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.

I have one job, where i have to save many solids in different levels (positions of electrode). Today i have error message: "PK Error code 901 , modeler has run out of virtual memory". I press ctrl alt del to see how much of memory is used and mastercam has about 3 GB of RAM. ( of my 4GB max.). Does mastercam swaps on hard drive or use only RAM?

I have to split file in two or buy more RAM... I have Vista 64bit, 4 GB RAM, using X5 MU1

Thanks for reply.

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.

Joe, do you think that using ram saver may help my, having to restart MC for waterline rest paths

only regenerating after a restart and the .3k path size issue on imported or copied rest paths?

 

Or would my issue relate to how MC memory is allocated to calculate the (behind the scenes) info needed to produce

the Rest paths?

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.