This is a major change so we’d like all of the testing you can provide, just keep your hand near the power button and don’t use any super-valuable material on the first job.
3D Rendering
The renderer is all software, no OpenGL so it will run on any PC, no matter how old the graphics card is and no matter how large the G-code is. It’ll render a top, front, and ISO view so that you can be sure that you loaded the correct file.
The preview is not there to replace the preview in your CAM software, it’s there so that you can be sure that you loaded the correct file to run.
G-Code Parser
This is a major change with a number of benefits:
It simplifies internal code a lot
Better tolerates huge G-code files
Uses memory more efficiently
Runs in a background thread so the UI doesn’t lock up with big files.
Please give it a careful try and let us know what you think.
Thanks to everyone that posted G-code files for me to test a few weeks ago. The files were very helpful in testing this new system with customer code.
Immediate first feedback: in the 3D views I find myself wanting to zoom in and out (and possibly pan/rotate) with the mouse. Typically in the front view I usually like to zoom way in to double-check how many depths passes I have in that file. I do realize the fixed views are much simpler, just a thought that for complex designs it may be useful to zoom in.
I find myself doing the same thing. I think it’s a habit because I like G-code a little too much.
We’d prefer to add the support for metadata in the G-code (like # of passes) itself rather than build a full 3D system because there’s really no good way to provide that, and support for 100MB files, and have it run on any leftover PC.
Looks great and behaves correctly during job setup on a Microsoft Surface Pro 3 and xxl pro. Too late in the day to start but I will cut a multi-tool 2.5d file in the morning, gcode from Vectric Aspire using Neil’s PP. The previews are awesome but I haven’t hit the start button… Will they slowly disappear as the file progresses? I hope so! Nice job…
I have to be a downer now- nope, they’re static images to help you verify that you’ve loaded the file and show the zero position relative to the toolpath.
@robgrz I am a Pi 3 user. I have not seen 557 yet. However I have used other senders with 3D rendering and it may be heavy on the Pi, I normally shut it off. I am suggesting /hoping that it is an option if it could be seen as heavy on resources.
Thanks
It’s not something that can be disabled but keeping the resource load light is why we wrote a simple software renderer. There will never be an OpenGL or driver problem with this approach.
Further, this version should not thrash memory like prior versions so big files will be a lot more reliable on resource-contrained computers.
Also, since this is a big change to the program, we really need feedback before we can move it to stable and move on to bigger and better things. If you try this build, please let us know here that you were able to run a g-code file without trouble.
I upgraded my Pi, and had a hiccup. attached is the gcode I generated for another thread for QR codes.
When I clicked on the file to open, CM just shut down. The file was generated with Vectric Vcarve pro.
I regenerated the file, and got the same result. I tried a known, good file that I had just recently run, also generated by Vcarve pro, and it worked.
I reloaded 550, and the QR file ran without a hitch. RR QRcode.nc (31.2 KB)
