Hi Eric,

I have been doing experiments and have not been able to produce a crash increasing the DPI or loading a large image thus far. v1.43a has a hard limit of 400ppi on a project's canvas regardless of its size. I'm able to load an 8000x8000 PNG just fine over here on my desktop and laptop, I'll have to test on older system today. PixelCNC should automatically be limiting canvas pixel density depending on the physical dimensions of your canvas - mainly to keep PixelCNC from being completely bogged down by huge computation costs but if you're not seeing the message that limits the pixels/inch then something else is causing the crash. The intent on the PPI limit is to "guard-rail" users from making everything unnecessarily slow with computations that have no benefit on their final product. I've found that a project doesn't need higher than 100-150ppi unless its relatively small, like an engraving or tiny decorative art piece like an ornament, which is why the PPI parameter is there but users should strive to keep their canvas PPI as low as possible without sacrificing quality of the final product. Projects made on a tabletop router on the order of feet in size really aren't visibly different with a canvas beyond ~150 pixels/inch. Even high-end CNC routers barely hold +/- 0.005"  tolerances (equating to 200 pixels/inch) what-with all the flex and backlash present. I'm positive that any project you make on your machine will not be improved by going above 200ppi unless it's a coin with lots of small text engraved into it. At any rate, it shouldn't be crashing! I don't think you're even hitting the PPI limit for your project's size, in fact.

I believe that the issue is likely graphics-hardware related. I'm thinking it's simply not able to handle a large image for drawing to the 3D view with. I'm going to add some code to PixelCNC to query the graphics hardware for the maximum texture size and make sure it doesn't create any textures larger than that but I don't know for sure that is the issue at hand. One thing that might shed some light is if you create a project and then enable Log Debug Info from the config menu, and then increase the canvas pixel density to where it causes a crash. The log file it produces may have some useful information that helps to track down what exactly the crash results from. Just make sure you don't continue using PixelCNC with debugging info logging enabled or it will go extremely slow! I had a user forget that they left it enabled when we were chasing down a bug that they were experiencing and it was really worrying for them that it took 5 minutes to generate a cut path which used to only take 5 seconds!

In the meantime you could also try decreasing canvas quality in the View Settings. This only affects the rendering of the canvas and does not impact the quality of toolpaths generated - it only degrades the visuals, not the actual fidelity of the geometry that toolpaths are generated from. If that resolves the crash issue somewhat (allows you to use a higher canvas pixels/inch for given canvas dimensions than before) then it's likely a graphics hardware issue that I should be accommodating for by capping the size of image data offloaded to it for rendering.

As for the rest-machining functionality it simply clips an operation's generated cutpaths to whatever remains of the stock material after previous operations have been performed. Anywhere the previous operation didn't reach, because of a cutter too large for smaller areas, or a leave-stock that results in a layer of material for a finishing or re-roughing pass to get at, is a good candidate for a rest-machining op to follow. Rest-machining in PixelCNC is to prevent operations with a cut-depth that's a fraction of the max-depth from cutting-air wherever material has already been removed.

Also: dDid you figure out the G-code post processor situation?  I'd like to be able to include  compatibility with that controller's dialect in the Mach3 post on the next release. I get the feeling it has something to do with the order of commands being issued, and not so much that something's missing. It's an interesting problem :P

Thanks!

 Charlie