5 Pro GRBL comments lock up machine (CNC.JS)

CNC Machines
1

I’m using Fusion 360 and the Carbide 3d Post Processor plugin. This results in .NC files with parentheses comments. For example:

%
(reverse)
(T1 D=6.35 CR=0 - ZMIN=-0.254 - flat end mill)
G90
G17
G21

If I send that file directly to the Shapeoko, it locks up after the first comment. I’ve also verified this by directly opening a serial port to the Shapeoko controller and just typing in commands as follows:

$ picocom --baud 115200 --flow h /dev/ttyACM0 
Terminal ready

Grbl 1.1h ['$' for help]
[MSG:'$H'|'$X' to unlock]
<Alarm|MPos:0.000,0.000,0.000|FS:0,0|Pn:P|WCO:-913.256,-1003.081,-114.050>
$$
[G54:-913.256,-1003.081,-114.050]
[G55:0.000,0.000,0.000]
[G56:0.000,0.000,0.000]
[G57:0.000,0.000,0.000]
[G58:0.000,0.000,0.000]
[G59:0.000,0.000,0.000]
[G28:0.000,0.000,0.000]
[G30:0.000,0.000,0.000]
[G92:0.000,0.000,0.000]
[TLO:0.000]
[PRB:0.000,0.000,0.000:0]
$I
[VER:1.1h.20190830:]
[OPT:VN2,14,128]
(test)

At the point after I type (test), the machine stops accepting any new input. It’s completely dead until I disconnect and reconnect the serial port.

It’s also worth noting that ‘%’ on the first line of the GRBL results in ‘error: 9’

Interestingly, loading the same file to Carbide Motion works great. It appears that Carbide Motion is interpreting the comments and ‘%’ and stripping them out before sending them to the machine. That’s fine, but the machine shouldn’t lock up if comments are sent to it. Many non-Carbide pieces of software (like CNCJS and GCodeSender) don’t interpret the GCode as it’s sent. They certainly don’t modify it in flight. This means they pass the comments directly to the GRBL interpreter on the Shapeoko. This locks up the machine and basically doesn’t work.

I looked at the code for the GRBL 1.1h firmware and it looks like it should handle comments successfully. There also aren’t any issues noted, so I suspect that the firmware loaded on the Shapeoko 5 Pro is a proprietary fork off the main GRBL code that breaks this (big assumption).

The other thing that could be happening is somehow I messed up my machine, but I haven’t done anything weird to it and EVERYTHING else works except parentheses comments.

Would love to get this resolved - let me know how I can help!

2

This was brought up previously:

1 Like
3

Definitely the same issue. Thanks for linking the other topic.

Since the carbide firmware is clearly based on grbl, which is GPL licensed, that means that the Shapeoko 5 Pro grbl firmware needs to be available somewhere. Is there a github link somewhere that we an look at the source, fix this, recompile, and flash on our machines? That would allow this to get fixed much sooner than when the Carbide team has time to get to it. As a bonus, you wouldn’t be out of compliance with the grbl license :wink:

1 Like
4

My understanding is that the Grbl source at:

has the headers for compiling Grbl w/ the Carbide 3D defaults — in the past we’ve had folks do that to reflash their machines.

As noted, that applies to the machines which use an Arduino/Atmega 328p.

5

That’s awesome but I’m hesitant to flash that because I don’t know what other code carbide has on the S5pro firmware beyond the standard grbl code.
I assume it’s been modified because of this bug that doesn’t appear to be an issue in the standard grbl code.

Basically, I want the carbide firmware with this bug fix rather than going all the way back to standard grbl and giving up whatever (unknown) modifications carbide 3d had made to make it work better with these machines.

Hope that makes sense!

1 Like
7

@Gibs Appreciate your work on the post processor.

For those who want a hackier but simpler solution, here’s a small shell script that turns the parentheses comments into semi-colon comments (which work without issue)

#!/bin/bash
sed 's/[()]/;/g' $1 > $1.new
mv $1 $1.old
mv $1.new $1

To use it on a mac or linux machine, just put that in a file called strip.sh, then do chmod +x strip.sh to make the script executable. Then after you post-process a file and get an NC program, you can do:

strip.sh myprogram.nc

It will back up the original and replace the file with a fixed version.

2 Likes
8

Can you make the original post processor output the semi-colon comments directly?

9

Yes, you can find information on how to do so here.

1 Like
10

Hey @WillAdams ,
Just checking on progress for posting the source code for the SO5Pro firmware. Safe to assume that the developers are using source control so it shouldn’t take more than a few minutes to put it up on GitHub.

Looking forward to getting this bug fixed so we can eliminate the workarounds!

11

That’s not my bailiwick — it would be for someone in charge.

Anyone who has any such concerns, or needs access to the source should write in to support@carbide3d.com

As regards fixing the bug, that will be looked into the next time the firmware is worked on as was noted:

12

Awesome thanks. I’ll email support. Thanks for the help here in the community section!

13

Just sent the following to support@carbide3d.com:

Hi!

First of all, thanks for making the Shapeoken (is that the right plural?). I got the 4x4 and it’s my first CNC machine. It’s been an awesome journey adding CNC to my repertoire. I’ve been a software engineer and hardware engineer professionally for a few decades and also spent a bit of time woodworking and 3d printing. CNC was the next frontier I wanted to explore and the Shapeoko has made it very approachable and easy to learn.

As I expanded beyond Carbide Create and Motion, I ran into an issue. There’s a community thread here, but the short version is that many modeling tools, including the Carbide 3d Post Processor for Fusion 360, put comments in the GCode file. When those comments are passed to the CNC machine it causes the CNC machine to lock up completely because of a bug in the Shapeoko firmware. The reason you may not have seen this is because Carbide Motion strips those comments out of the GCode and doesn’t send them to the CNC machine, but that’s a very non-standard way to handle GCode. Every other tool like CNCJS, GCodeSender, and Mach3 pass those comments to the Shapeoko directly and lock up the machine.

I’m sure the Carbide 3d developers will fix the bug and provide an updated firmware when they get time to do so. Unfortunately, it’s been 6 weeks since the team was made aware of the problem in this post on May 29.

There’s one additional layer of complexity to address. The Shapeoko firmware is based on an open source project called GRBL. The Carbide 3d developers modified the GRBL source code to make it work better on the Shapeoko, which apparently introduced this bug. The beauty of the GRBL project being open source is that it allows software engineers from all over the world to fix bugs and contribute those fixes back to the community. That’s not possible in this case because Carbide 3d hasn’t provided the modified source code as required by the GRBL license. That means nobody except Carbide 3d can fix this so we’re stuck waiting for the Carbide 3d developers to find the time.

I’ll spare you any philosophical speeches on open source, but will briefly point out that Carbide 3d has benefitted massively from the work of the GRBL project. The Shapeoko firmware is based entirely on the code written by Sonny Jeon, a PHD astrophysicist and Aerospace Engineer at MIT, plus 26 other contributors. It’s unlikely Carbide 3d could exist without that team of engineers providing all of their work for free. Carbide 3d received all of that value without paying anything and is free to use GRBL to create a business. The agreement only has one major stipulation: Those who modify the GRBL software are required to publish their source code under the same agreement.

Now that you’re aware, I’ll ask you to please publish the Shapeoko 5 Pro firmware source code. It will benefit you as a company because people like me will be able to fix bugs like this much faster than your own developers. You’ll get those contributions and improvements for free. In addition, you’ll be in compliance with the GPLv3 license that GRBL is provided under. I’m assuming your engineers use some form of source control and there’s a good chance it’s a private GitHub repository already. It shouldn’t take more than a few minutes to publish that repository publicly.

Thanks!

Ryan Steckler
gotcode@gmail.com

2 Likes
14

I disagree. Whereas C3D does benefit from an opensource software, if they are financially supporting the gerbils, I don’t see where they should be obligated to open their files to the general public.
Thomas Sanladerer posted an interesting video on his opinion of the current state of opensource.

16

Reply from Support:

We’ll zip up our GRBL build in the near future and post it. We made minimal changes to it from the latest official release, mainly to shoe horn the dual Y homing into a 328.

You don’t need to tell us about Sonny, we were the ones that convinced him to charge companies a “support fee” based on machine sales. We paid him a small fortune to fund GRBL development (and contributed code) until he moved on from it.

Regarding the parenthetical comments, that’s not a thing in GRBL, it’s in the USB chip we use. We don’t test our machines with other senders, so it’s not a code path that got tested. The next time we’re in that code, we’ll take a look at it.

Looks like the bug isn’t in an open source component, so we’ll need to wait for Carbide 3d to fix it.

1 Like
17

I disagree. Whereas C3D does benefit from an opensource software, if they are financially supporting the gerbils, I don’t see where they should be obligated to open their files to the general public.

Watched the video. And to be clear, I’m not an open source zealot. I lead a business at a large software company that sells proprietary software. I was a software engineer at proprietary software companies for a very long time. I contribute to open source occasionally but typically only when I need to fix a problem that I’m personally experiencing (like this one).

With that said, I have three thoughts counter to the video above.

First, the video makes the point that open source somehow causes consumers to pay more for products that are forced to publish their source code because it’s derived from open source libraries. I think the argument is misleading. Those companies wouldn’t exist if they didn’t leverage said open source library in the first place. And nobody forced them to start by adopting open source in the first place. Let’s use Prusa for example. They were able to build a MASSIVE company by leveraging Marlin, Slic3r, and more. I don’t think they could have built the company without standing on the shoulders of those giants. So the idea that being forced to publish source code “kills companies” ignores the fact that the companies couldn’t have existed without said open source AND that nobody forced them to use said open source. The open source repos are SO necessary that, despite Josef’s tirade, he hasn’t decided to eject the open source libraries and re-write the slicer and firmware from scratch. He totally could, but chooses to continue using open source as the base for his software.

Second, the idea that publishing source code “costs companies money that they pass along to consumers” is ridiculous. The Carbide 3d team just sent me a zip with their GRBL changes. It cost them essentially nothing to comply with the license.

Third, the perspective of companies like Prusa who became successful because of open source and now rally against the requirements imposed by it are irrelevant. The license is the license. If Prusa contributed a bunch of money to Marlin to fund the work and Marlin wants to change the license or provide a carveout for Prusa, they can do that. Given the current license choice of GPL, one has to assume that the Marlin project owner intends for derivative work to be published regardless of any financial support. Companies who benefit from open source and even those who pay to fund it don’t get to unilaterally decide they don’t like the license anymore and stop abiding by it.

I’ll say that the Carbide team seems like a bunch of stand up folks. They responded to the thread here, responded immediately to my lengthy email, and sent me the GRBL source within an hour. They certainly don’t seem to take issue with the open source license of GRBL. Couldn’t ask for more, except a fix for the bug :slight_smile:

2 Likes
18

SO5 Pro also uses a ESP32 and not an Atmega 328p. If you try to flash the code from that provided github link it will not work

It looks like the SO5Pro uses both, like the HDM. I believe it’s using the ESP32 for usb to UART conversion and potentially future wifi connectivity or other extensibility.

The actual GRBL microcontroller is a 328.

Both ESP and 328 have separate RST and DFU buttons, as well as serial port pin headers.

19

Interesting, I am surprised they didn’t just port over to the ESP32 or use FluidNC’s code. Thanks for this information.

20

This topic was automatically closed after 30 days. New replies are no longer allowed.