Indie game storeFree gamesFun gamesHorror games
Game developmentAssetsComics

Some questions /suggestions.

A topic by eric berg created Jul 14, 2020 Views: 121 Replies: 7
Viewing posts 1 to 4

Please bear in mind I'm coming from a professional side and not hobby cnc.

A.  I know many hobby cnc set tools z0 on top of the stock.bad, bad.  

   1   you need new scrap or un cut top to set another tool.  

   2.  imo stock z0 should always be bed.   easy to not cut into bed with no neg z in g code.

B.  your ''canvas" sets the tool limits to the R of the tool instead of tool center.

IMO    I don't need to define a canvas with +  0.5" per side and Z min depth of pic area 1/2ball  . so I can cut a whole picture without fudging canvas vs pic if the tool paths just generated to Center of tool.

Still learning your software,   just observations and maybe some help.


(Tried to reply yesterday but this site was broken, hopefully it works now)

Hi Eric! Thanks for sharing feedback. I too come from a precision machining background so I understand where you're coming from. Glad to know I'm not alone ;)

Well I've got good news: you can set the machine-origin, or "zero" for the XYZ  axes, to anywhere within the canvas' volume. PixelCNC defaults to using the top of the canvas. If you want to set it to the bottom of the canvas you can just change the origin Z percentage from 100% to 0%, or type "0" in the "Z Origin" editbox in a project's Canvas Properties.

Here's after changing the origin Z knob from 100% to 0%, in lieu of having to type a front-left-bottom relative coordinate in the XYZ origin editboxes, which you can do instead if you prefer) and hitting Apply.

The machine origin is retained and re-used whenever you create a new project, between PixelCNC sessions or otherwise. If you set it to X:50%, Y:50% and Z:0% on a 3"x3"x1" ?project it will be set to the bottom-center of any project, no matter the size of the canvas.

...and yeah, your point about the canvas and tool center is totally valid. The "canvas" is not meant to represent your stock material, it's just the volume within which cutpaths are generated. If you don't want your cuts to ever go deeper than 0.5" then make your canvas 0.5", etc.. If you have a 2" wide piece of stock that you want to cut the entire top of then set your canvas to 3" and add some margin in there. I could definitely add some functionality for it to automagically border the canvas with the tool radius for each operation when generating cut paths, as a toggle option for either the canvas or each operation individually. I'll make a note of that and look over the code to see what has to be done to make that a thing, because it's a good idea that I'd like to have in there myself now that you mention it.


 - Charlie

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



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?

Developer (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.

I stitched together many png's to get the native resolution of 4000 x 3000.    imported into a canvas 72 dpi is best i can get to before it crashes.  I logged it but don't know where the log file saves to.


Hey that's pretty cool!

For the log files check the File menu, there's an option in there: "View Log Files" to get to the log files folder. Just keep in mind that after PixelCNC crashes and you launch it again the newest log file will be of the instance of PixelCNC that you're running at that moment while the one before that will be from the instance that the crash occurred during. So, the second-to-last, if you get to the PixelCNC log files by running it again after a crash and going to the File menu.

Also, when you intentionally invoke a crash be sure to enable logging of debug information from the config menu beforehand. It will have the log file be outputted with the most information possible. Just check to ensure that it's disabled afterward when you continue using PixelCNC or it can severely bog down performance due to all kinds of extraneous bits of information about program state being output to disk during computationally-intensive functions like updating  the canvas state and generating operations' toolpaths.