There is an improved version of widget-3dviewer at https://github.com/chilipeppr/widget-3dviewer .

There is an improved version of widget-3dviewer at https://github.com/chilipeppr/widget-3dviewer .

It has the following fixes and improvements:

a) It handles numerous modal codes on the same line, such as “initialization/safety blocks” like “G17 G40 G20 G54 G90 G94” and relative moves like “G91 G1 X0”. This was implemented by pre-scanning the line looking for non-motion modal codes. Such codes are executed immediately, deferring other codes for execution in the second phase.

b) There was a bug in the arc radius calculation that sometimes resulted in the wrong center being computed. It had to do with taking the sqrt of a very small negative number, which in turn resulted from the finite precision of floating point math.

c) Mach3’s “absolute IJK” arc mode is supported . g2core supports that mode but 3dviewer did not display the toolpaths correctly.

I have tested it against my corpus of milling and laser engraving codes, including hand-generated gcode, Fusion-360 CAM output from its Mach 3 post, and Inkscape-generated laser gcode.

I have two questions and one request.

Q1: Would a pull request be welcome, and if so,
Q2: Is it okay to retain the lengthy commit history from the sequence of Cloud 9 / runme.js refreshes, or should I squash the commits into a single one.

Request: For those of you with gcode corpuses, I would appreciate more testing on this patch. I tried to be careful and get it right, but there is no substitute for testing.

Pull request totally welcome. These enhancements sound awesome. I think you could keep as many commits as you want.

Hi Mitch. Good on you for contributing to the 3d-viewer widget! I’ve got some gcode files with relative movements (G91) that I can send you for testing. These files previously rendered correctly in the 3d viewer, but stopped being rendered correctly around the time your changes were merged into the widget. My experience is that files with absolute movements (G90) render correctly.

Below is a link to a Google Drive folder with some test files (*.nc) and screenshots of how they rendered before the changes. https://drive.google.com/drive/folders/1rCXaafRETMDiulML7S326eergvizZ5nA?usp=sharing

Feel free to be in touch if there is anything I can to do help, or if you have any insights into the files. Cheers!

Please do send or upload those files and note which line is the first to misrender

I am totally confused. When I run the 3d viewer widget standalone, with the URL https://preview.c9users.io/chilipeppr/widget-3dviewer/widget.html , it renders your files perfectly, displaying tiled hexagons and squares. But when I run it inside the GRBL workspace, it completely screws up.

I tried to debug the workspace version using the Chrome developer tools, but I could not figure out how to look at the source and set breakpoints across the auto-generated-widget boundary.

At this point I am stuck. I don’t understand the ins and outs of the chilipeppr framework well enough to work out what is different between running standalone and running in the full workspace environment.

That doesn’t really make sense to me either. The grbl workspace does use the main 3d viewer you are referring to.

I found something interesting.

In https://preview.c9users.io/chilipeppr/workspace-grbl-real/workspace.html , I ran the Chrome developer tools, chose the Sources tab, and looked at the file top > http://preview.c9users.io > chilipeppr/workspace-grbl-real > workspace.js . The function threed.GCodeParser has old code. For example, line 975 is

     var tokens = text.split(/\s+/);

but it should be, according to GitHub chilipeppr/widget-3dviewer

     var tokens = [];

Looking at the files in https://github.com/chilipeppr-grbl/workspace-grbl, I see the same problem - workspace.js has the old code, not the new code from widget-3dviewer .

How do changes to the widgets get propagated into the workspaces?

Ahh. Look at line 919 of workspace.js for workspace-grbl-real. The entire GcodeParser method is overridden. This was perhaps done by Jarrett Luft or Ray Kholodovsky. You could try a version without that override because the 3D viewer is overall really good now and perhaps all of those fixes are good to go now. I know i use the base 3D viewer in TinyG and it works great.

Thanks for merging the pull request. Note that I personally don’t use the GRBL workspace; I was just trying to help Timothy Godfrey.

Oh. Ok. Well, it would be good if somebody can do the ?forcerefresh=true and then test that it’s good to go. I imagine it will be as removing that override uses what’s already tested well in other workspaces.

Timothy - it might work now. In your message, you didn’t mention the context in which you were running 3dviewer. I just assumed that it might be the GRBL workspace. That workspace now correctly renders your test files. The standalone widget was already working correctly.

I assume that you mean to add “?forcerefresh=true” to the URL. I tried that - http://chilipeppr.com/grbl?forcerefresh=true - but the 3dviewer background remained black after dragging in the GCode file.

Prior to the change, the 3dviewer worked, albeit with misrendered toolpaths.

Everything worked fine in Cloud9.

Aha, it is working. The problem was that 3D Viewer was disabled. I finally noticed the “Manually Disabled. Go to cog wheel…” popup and did what it said. Now the GRBL workspace is working, rendering toolpaths correctly.

Hello! Sorry for my absence from the conversation, and good on you for sorting it out without further input from me. You inferred correctly that I was using the GRBL workspace, and the problem appears now to be fixed. Well done!