Memory settings for Meshcam?

I've been demo'ing Meshcam for use in machining .STL meshes of large topography models. I'm running a pretty above average computer, currently with a 2.8ghz quad core processor (hyperthreaded to 8 virtual cores) and 64 bit Windows 7, along with 16gb of ram and a very capable video card with it's own dedicated ram (forget how much, but it's more than enough). Unfortunately, I'm running into a problem where Meshcam utilizes all 16 gb of ram in generating the tool path, then gets shut down by windows before completing. Is there a setting somewhere for how much memory is available so that it won't run out? Are there any alternate ways within windows to set up a page file for it to use?

I've been working on this all evening, and being somewhat new to Meshcam there is lots to learn. I changed the tool settings to make sure it only does one pass, which while longer than the actual mill cutting length is fine because it's 6lb foam and there has never been a need for mulitpasses in the past. This has reduced the memory usage to about 6gb of RAM, so it must have made a pretty significant difference. Also, I upped the tolerance a bit from the .025mm to .04mm, which probably also helped. Still waiting for the toolpath to finish (been a while, but it's going to be big), but I'm pretty sure it will finish up this time.

I do have to give kudos to Meshcam for the efficient use of processor cores. All eight cores were pegged at 100% for all but the last stage of linking the toolpaths, or for around 20minutes straight. Not sure how much my computer liked that, but I can only think of a handful of multicore hyperthreading applications that can even do short bursts on my computer at 100%, let alone 20 minutes straight. It's a lot more satisfying than watching most applications (even 64bit) chugging along on one core with 88% of the computer resources untapped and I'm sure quite a lot faster as well. Very impressive, IMHO.

I do think that eventually the memory issue will come up again for me as this was only a medium sized topo and the surface area could easily double for others. I would guess that if I double my current RAM, there probably won't be an issue, but it might be nice to be able use page files on computers that don't have quite as much resources, like my laptop. So while I've worked around it for this test cut, it would be nice to know if there is a solution for future reference.
Thanks!
-Mike

You could do your roughing and finishing passes separately, which might help. Also, increase the stepover if possible? Or increase the tolerance even higher if you can. On something that large you can probably use a much higher tolerance without seeing poorer results, which should greatly reduce memory use.

You can try right clicking on Computer in Windows, choosing properties, then Advanced System Settings, then the Advanced tab, then Performance, to increase the page file. But If you hit the page file, expect processing times to go up a LOT.

Thanks for the suggestions. I'll have to look at what the minimum tolerance can be, but I'm not sure it can be much more than .04mm. While the part is large, the scale and detail are pretty fine, so some experimenting may need to be done to see what the minimum tolerance needed to maintain the details is. I've spent months trying to find a way to convert the point clouds previously used (which limited pre-cut modifications) into useable meshes, since most point cloud to mesh conversions use at least a minimal amount of "noise reduction". The details of the model are eliminated in the noise reduction phases of conversion, so they are quite fine and easily lost. I just recently finally found a product that will allow for a truly zero noise reduction conversion with the highest number of triangles possible from the given number of points. The stepover is pretty much set at .8mm to 1mm. Current machining of point clouds for similar models is done at .025-.040 inches, so it will need to stay in the same range. These jobs can take days to cut even at 120ipm (limited by Z mostly, but I have some plans that may double that) due to the detail and size. The model here is only 1/4 of the full 4'x8' table and there will be times when it would be desirable to cut the full table.

There normally isn't a roughing pass at all, so there is no need for a step down in the tool path. That was a mistake on my part as I think I missed the setting in the tool table. This is what I think caused the bloated file size since it was doing around 3-4 passes over the part. That change would remain permanent, however I'm still concerned that if the full table were cut, the file size would be about 4 time larger, which would be about 24gb based on the current test part. I may scale the model up to that size in X and Y to see if it does change the memory usage in a way that is a multiple of the current model. It may be possible that it won't be a straight 4x factor, in which case it won't be a problem anyways unless it's more than 4x. Plus, if I have to buy $100 worth of memory, then that's not something I'd complain about given that the software seems to be performing quite admirable on a very difficult part.

I looked into my page file and it's currently at 24gb. That is the maximum I have available on the C: drive since I use an SSD, which is small to begin with. I don't actually have that much space on the drive even (closer to 10gb remaining), so I'll look into whether or not that's part of the problem. I suppose that if the specified space is not available, it may be the same as having no space at all, but who knows with Windows. I suspect that for some reason the page file did not get utilized when Meshcam hit the limit of the available RAM, but whether or not it was Windows or Meshcam that didn't shift to the page file I couldn't say (or really if the page file was suddenly filled up?). You could see the total memory used climb rapidly to 15.5gb, then it went more slowly from there up to the full 16gb. However, that's when Windows prompts you that the software will be closed and you really don't have any choice in the matter. It seems that if the page file were being used at all, it would have prompted me long after the 16gb level was reached.

I'll continue with experimenting, but I think that I should be able to do even the largest model at the current tolerances with an increase to 32gb of ram. I have a feeling it will be just fine. Perhaps I'll be able to confirm if the page file gets utilized or not.

I suspect that you have a fairly big item to use that much memory with a moderate tolerance value. One thing to keep in mind is that the tolerance value is really more of an estimate of "Maximum Tolerance". Internally, Meshcam will use a much smaller tolerance value for all of the calculations. I suspect that 6LB foam can never hold anything close to a .025mm tolerance so you're safe to make it bigger and you'd probably never see a difference in the output.

Also, if you do parallel finishing only then Meshcam tends to use less memory because it can skip some big calculations used for the roughing, waterline, and pencil options.

I'm glad you like the multicore behavior. This was something I put a lot of effort into a few years ago and I never get tired of seeing all eight cores on my laptop pegged at 100%.

-Rob

I'm doing just a parallel finishing pass across the gantry axis, so I think it's skipping those steps. I have roughing unchecked and have unchecked all but the parallel across the gantry. I think for the most part that I've got things sorted.

What kind of effect does the tolerance setting have on the arc-fit feature? Are they linked?

Can you say if Meshcam should be using the Page File? Or is that a Windows thing that is out of each program's control? I've cleared out enough drive space to exceed the Page File setting to see if that was part of the problem.

I would turn off arc fitting for what you're trying to do. I doubt it will make much difference.
.025mm is .0015".
If you only need accuracy to .025", then try a Tolerance of .25mm, and see if it makes a difference. I suspect that between arc fitting and the higher tolerance, it should be much better.

Tolerance aren't .025", that's the stepover for the point cloud tool path. I'd say that there are details that are less than .010" which do show up in the cut, and the foam seems to be able to hold detail down to that level as well, though obviously the texture of the foam also ungulates a bit at around that level as well. I'm doing pretty well with the tolerances set at .04mm, and may up it to .05mm to see how that looks as well. I'll just keep increasing it by .01mm until it seems like something is lost, then I'll know what is actually necessary. Even at .04mm, there is considerably less processing than the standard .025mm setting I started with and less memory consumption.

Arc fitting seems like it's a non-factor in these files since they are very noisy meshes by normal standards, which means everything is a triangular facet. Since there haven't been any arcs produced in the code anyways, I just turned that feature off. Hasn't really made a difference in processing times either way though, FWIW. It seems that if there are no arcs, that feature just gets ignored perhaps, or executes so quickly because of the lack of arcs that it's a non-factor. The noise, though, is actually details when it comes to these particular point clouds, which was one of the reasons I had a hard time getting a good enough mesh to match the detail produced by cutting the point cloud directly. Most software rounds out the peaks and valleys, and eliminates what it thinks are aberrations in the cloud that are often either an extreme peak or maybe a rock formation in an otherwise less dynamic field. The point cloud, however, was impossible to manipulate in any significant way, and the mesh is offering much more in the way of machining options. MeshCAM is looking like a perfect match for these files, since they are extremely large and very heavily mesh structured as opposed to the smoother surface like meshes you might usually see. So far, it's all looking quite good.

One thing that would be super handy, and maybe is already possible and I'm not seeing it, would be to be able to set the origin to the selection window instead of the stock. Or if the selection window could be used as the stock boundary, which would then allow you to set the zero to the stock (and consequently selection window). Is there a way to do that currently, perhaps using the X Y Position?

Right now the stock and zero selection are only done through the windows used by their commands. There is no way to use the 3d view as any kind of selector. (Sorry)

That being said, you should have complete flexibility to accurately place either one relative to the world or the part with the existing commands.

-Robert

So it seems that you'd have to know the coordinates of your boundary in order to set zero relative to the selection window? Not really a big deal, but I think the only way I'd know that is if I use a DXF drawn to a know position to determine the selection window since there isn't a readout of the position of a selection window when it's drawn.

You could add it to my wish list I guess, so please don't take it as a complaint of any sort as the software really is quite good already. You wouldn't need to make it selectable through the 3d view, though. I think what would be cool is if there was a button in the "Define Stock" window just below the "Fit to Geometry" button that said "Fit to Selection" which would set the stock to the size of the selection window in X and Y and leave the Z the same as the geometry (or the excess added in the bottom fields). At that point, I'd imagine that the zero could automatically be set to the stock to match up with the selection window using the Program Zero window, as I'm thinking that the Program Zero window uses the stock size rather than the geometry to determine the zero position? I can't speak for how useful the feature would be for others, but it would be something that would get used every time in my case. Definitely not a deal breaker though and I think the software is a tremendous value. :)

For what it's worth, I ran roughly the same tool path in both Bobcad V24 (which I already own) and Meshcam using the same topography, the same stepover, and the same tolerances to compare processing times. I expected that Meshcam would be a bit faster since it uses so much more of the computer resources and is 64 bit vs. 32bit. I am quite surprised, though, just how much faster it is for this particular purpose. I started the tool path last night and it appears that Meshcam took about an hour and a half of processing (using 87% of the computer resources since Bobcad was also running). Bobcad is still running the toolpath as I type this, some 10 hours later and appears to have another 10-15% left to go. Bobcad V25 is 64bit and would probably be faster than V24, but I have not found it to be even twice as fast as V24 which is why I never bothered to upgrade, so I expect that Meshcam would still be 6 times faster (at least). There are obviously other comparisons that could be made in Bobcad's favor in terms of features and it satisfies different needs admirably, but when it comes to running through a very, very large 3d tool path on an STL, there is obviously no comparison there. Again, excellent work with the processing speeds!

TL;DR: Your problem could also be with Hyper-threading. I would strongly suggest you turn it off, especially if all the cores are being run at 100%. In this scenario HT just gets in its own way.

Longer explanation:
HT is a leftover from when it was common for servers to only have single cores. It is a trick to push more than one thread through a single core by interleaving it with another process. The goal was to get higher usage out of a CPU by running two process through a core that was not being completely utilized. In fact, database servers were specifically documented that you were to disable HT as, with the higher CPU usage, HT would cause problems with running two high usage threads and would jam up the CPU eventually causing a software crash. With multicore systems being the standard these days it really is unneeded as there are multiple hardware cores to run processes through.

Something to think about and maybe test.