Hi Charlie,

I'm testing out PixelCNC for large images (8000x8000), large canvas sizes (1000mmx1000mm) and high canvas resolutions (300dpi). When I hit apply on operations, the program crashes. My workaround is to reduce the canvas resolution until it does not crash anymore.

Here are the last 10 lines from a log after a crash:

196.7273 toolpath_addpath: realloc toolpath[0] buffer: sz_verts[2690416] num_verts[1792269] (2778 verts)

196.7380 toolpath_addpath: realloc toolpath[0] buffer: sz_verts[4035624] num_verts[2690212] (2352 verts)

196.7528 engagepaths toolpath[0] subpaths 0->2403

196.7530 ...engage cuts generated

196.7532 engage cutz = 21.016001

196.7559 contouring 2405 paths... @z 14.000000->9.000000

196.8461 [ STATUS ] calculating Parallel Carving... -

197.0265 ...3345 polylines, 574116 verts

Are there ways to increase some limits of these calculations? If they are hardcoded (or caused by technical constrains),  what would be a good approach for e.g. parallel carving with small stepover values? Maybe divide the image into sub-images and calculate the operations separately?

Also, do you have a planned sale in the near future? I missed the one in July ;-)

All in all, I tried several different programs for these kind of things and PixelCNC is the best so far! :-)

Thanks and all the best,

Iven

Hi Iven,

Thank you for the kind words! We have been keeping the price for PixelCNC a bit on the low side since July and I don't imagine we'll lower it further any time soon (maybe during the holidays toward the end of the year?)

Yes, there is a hard limit on the number of vertices that can be generated, I believe it's 8 million right now. We might just bump it up to a ridiculously large value but that will cause "out of memory" errors on some systems that don't have a lot of memory, and our goal is to keep PixelCNC running on hardware for as long as possible without someone needing to buy a whole new computer just to use and run our software. We had perfectly find CAD/CAM software that ran perfectly fine on hardware of 20 years ago, which was at least an order of magnitude less capable than hardware today, so there's no excuse for software today not being blazingly fast on today's computers. It just means developers don't know what they're doing!

The complexity of a project's canvas will also increase the potential for creating cutpath vertices. If there is a lot of variance it will create more vertices compared to a flat/smooth canvas. You can try increasing the Toolpath Simplify and Min/Max segment length settings in CNC/CAM Settings, under the Config menu. I tend to refrain from changing the Min Segment Length setting though, and instead decrease the canvas resolution for a uniform reduction in vertices across the board - but you might be able to get away with changing Min Length to something like 0.05mm->0.1mm while keeping the canvas resolution high. I would start with raising the Max Length setting to something like 10mm, and maybe even beyond that. That will reduce vertices in planar areas that the simplify pass results in, but the thing to watch out for with increasing the Max Length setting is that where the toolpath changes direction (i.e. traveling flat to traveling up, or vice-versa) the toolpaths can end up placing vertices that are a bit wonky at the direction change there, usually along the bottom edge of shapes in a relief. For smaller stepovers it's not as much of a problem during cutting though.

Hope that helps! Let me know if you have any other questions or need help with anything else :)

 - Charlie

Dear Charlie,

thanks for the explanation! I just bought a license, since it is a really great software (...and trying to find settings that avoid a crash without the ability to save projects is cumbersome ;-))

I understand your reasoning, since I'm a software developer myself. Still, I would challenge it a little bit. Some projects where just not possible with hardware and software from 20 years ago. PixelCNC is a great example, where the image-based approach allows new things.

Maybe a possible solution could be to increase some limits with a factor that can be set by the user in the UI. The default is just "1" and wouldn't change anything for existing users. I have enough RAM, hard drive space and patience to wait - I'm happy to buy more RAM (even these days...) instead of reducing the quality of the generated paths. 

If that is not possible, maybe another form of error handling could be realized. With a meaningful error message before the crash (or within the log), I would know which part caused the memory overflow. Also, checking the available memory before allocating it could abort the operation before crashing and would allow me to tweak settings. If it would help, I could provide you with my setup, I assume that you have more debug messages than I have.

Until then, I will try your suggested solutions. 

Some questions about these: does the "toolpath simplification" run after completing the calculation? If so, I think changing these values maybe does not help, since the application already crashed.

Would you suggest to play with your mentioned values instead of dividing an images into smaller overlapping images?

Thanks and all the best,

Iven