Will have to test this with GRBL
Closed this issue · 9 comments
I started to hack up the bundled gcode viewer to support GRBL and decided its code was a bit too heavy to mess with.
Will have to see how well you fared. Depending on results I may link back to this repo as a recommended addition to Better GRBL Support.
Have you checked out Pretty GCode? I was able to convert it quickly to supporting absolute coordinate gcode but haven't had the time to work out the nuances of relative positioning.
I would be interested to know how well this works with grbl. I take it the 'Better GRBL Support' plugin doesn't address a gcode preview?
Pretty GCode is pretty advanced and beyond what I was aiming for. The third dimension is definitely helpful but beyond the scope of what this is aiming for. This is more of a 'bugfix' for the standard viewer and not a full-featured viewer.
I think the homing cycle and G92 commands might be different, but the standard movement commands should work if the coordinates are set only once at the beginning. If you have a ganged up job that performs G92 multiple times for each workpiece and runs the same gcode for each workpiece, then that won't render correctly (and not sure if it even works for Marlin).
I am open to tweaking to support GRBL.
you'd be (pleasantly) surprised how simple the pretty gcode viewer implementation is. I'll take your plugin for a spin and let ya know about GRBL compatibility.
Correct, I did not bundle a gcode viewer although I let folks know about my pretty gcode fork.
did some initial testing and it didn't go too well. I didn't expect there to be much variation between GRBL and Marlin but something is definitely throwing it off.
I'm happy to look at samples to see if it is something simple or something deeper. I wouldn't commit to covering GRBL 100% but maybe 5% of effort can cover 95% of cases.
here's the gcode file for the visual shown above. It's basically a bunch of pocket cuts for M4/M5 bolts and a profile cut for the perimeter.
here's the actual result
It looks like there are two problems.
- The plugin repository and/or the plugin manager has an issue where it says it has installed the latest (1.0.2) but in fact it had not installed the latest. It's possible that it could be some caching issue on my end, but it's troubling that the version is reported as 1.0.2 but the javascript (viewed through F12) was the older version. Try installing via the url
https://github.com/vector76/cnc_gcodeviewer/archive/refs/tags/v1.0.2.zip or https://github.com/vector76/cnc_gcodeviewer/archive/main.zip and not through the plugin manager. - With the latest 1.0.2 it is at least trying to render something, but it does not correctly distinguish the travel moves from cutting moves, and it is out of order
It is generating a lot of false "layers" that are "traveling" between the boring operations.
I think this is something nontrivial to fix, which is that for a 3D-printer, height and time are closely related, whereas for milling, height is not monotonic. The rendering is very height-oriented, when it should probably be more time-oriented.
I think a fix for this is related to something already in the roadmap, which is the ability to use G0/G1 to distinguish between travel moves and cutting moves. Instead of partitioning into "layers" based on Z height, it could partition between "operations" based on contiguous stretches of G1, splitting on occurrences of G0. Some logic might aggregate multiple 'operations' into single 'layers' for rendering.
Another option, also in the roadmap, is to just flatten the whole thing and render everything in a single layer. Depending on the complexity of the job, this could be a simple workaround.
The good news (if any) is that this does not appear to be a GRBL issue, but more broadly a CNC issue where the fundamental assumptions of the 3D printer world are violated and the plugin hasn't been updated to match.
Edit: Looks like the plugin repository was not the issue, and I must have had some caching issue on my end.
The other problem stands.
I've updated the processing so now it uses G0/G1 to render the green and black lines, and it also uses G0/G1 to partition chronologically into "layers". By default, OctoPrint uses Z height to partition into layers, which produces out-of-order illustrations.
Since most jobs have multiple G0 travels that separate the job into many chunks, and it's usually useful to view everything, there is an option (enabled by default) to flatten the job into a single layer.
So now your example job looks much more reasonable in the new 1.0.4 release:
If you don't mind, can you give this new version a try and see if it satisfies your usage scenario or not?
By the way, in the current version you must disable the built-in GCode Viewer for the CNC GCode Viewer to work. The replaces-viewmodel approach was not working properly.
Assuming this is issue is resolved.