Indie game storeFree gamesFun gamesHorror games
Game developmentAssetsComics
SalesBundles
Jobs
Tags

thanks for your feedback.     

I have found or worked around everything that might be an issue.  I also haven't explored all the different aspects of your software as of yet.

I'm not sure how your calculating your 'rest' if you are not specifying what tool your are resting off of.  again, i might be missing something there.

I know i have enough memory but i get a crash upping the dpi on canvas or loading in a large png.   2500 x 5000 ish.    I'm only on a 2'x3' table and currently I would need to ref off one 0,0,0 bottom left and setup multi  pixel projects to cover the bed with a lg file in Tiles.  all ref from one G.   it would be really bad if i had a 4'x8'  but the wife wouldn't let me spend  that much $  lol

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

Hi charlie.


I will log the crash.  loading in a canvas that is aprox 18 x 35" and a 2500 x 5000 ish png.   if i push the dpi on the canvas up over 120 ish is where i was getting the crashes.


REST:  ah.  you are looking back at the prev operation.  ok.  my software i'm either defining the prior tool used or a specific operation.


I haven't sorted out the issue with the g code.   as stated it runs off inf if i just try to run your post, but if i run an old program,   stop it, then load yours it runs fine..      something is getting 'set'  from the first program.   I have to reboot the software to reproduce the run off from Pixel cnc code.



Did you sort out if it would be easy to change tool path generation to center of tool or give us a button for it?

(1 edit)

There's a program you can use to check the capabilities of your graphics hardware, called 'GLview'. That will tell us right away if there's a limitation that's causing the issue, or if it's somehow something else - which is still a possibility. EDIT: I forgot to mention, the values you want to look at for your graphics hardware's OpenGL capabilities are "GL_MAX_TEXTURE_SIZE" and "GL_MAX_RECTANGLE_TEXTURE_SIZE". I'm thinking they might be capping out at 4096, which would make sense if going up to 120ppi for a 35" project because that will produce a depthmap that's over 4096px in the longest dimension, and get rejected by the graphics hardware. This is still just speculation but I'm 95% confident it's the cause. I already have a solution to that in place, so hopefully that's what's causing the issue.

The rest-machining will omit cutpaths that intersect areas removed by *all* previous operations, if they are "enabled" (the little paperclip button on an operation in the list when it's selected while in Project Operations mode).

I think I will add another toggleable option with the "link cuts"/"distance sort"/"rest-machining"  options for generating paths to tool-center or to the tool's radius. It shouldn't be too tricky ;)

I saw your other post just now about the G-code. I'll reply about that over there.