I keep getting this errors while trying to cut the sled: Command G40 unsupported and ignored
I followed step by step instructions on how to generate gCode for sled in makercam.com, but when I opened gcode file in ground control and launched maslow to cut the sled only outside profiles were cut and all other commands (holes, inside profile and pocket) were skipped.
I opened that gcode (.nc) file on viewer and I saw that there is no any commands for holes, inside profiles and pocket at all, only outer profiles. I guess that something was wrong in makercam already, so it failed to generate proper gcode.
Could someone please help me to solve this situation?
Since the Maslow doesn’t support cutter radius compensation in the first place,
turning it off does nothing and so nobody has written the code in the firmware
to make this a noop, so it complains that it doesn’t know what this is and so is
If you can change your CAM step to use a different profile to create your
g-code, you should be able to tell it that you have a simpler machine and it
won’t generate these codes (or others, which could cause problems from being
If there isn’t a maslow option, try for grbl.
g-code (at least for a machine like the maslow) doesn’t know a inside profile
from an outside profile, it just knows toolpaths, not why they are there.
@dlang is right, that error just means that MakerCAM is trying to turn off something which doesn’t exist so it’s pretty safe to ignore that warning
This sounds like it could be an issue with generating the paths. Is the depth set correctly for those cuts? Do you see the green cut lines showing up next to the paths in MakerCAM when you press “Calculate all”
On the contrary, it (G40) is often part of a larger misunderstanding of configuring MakerCam, and a benign one as it doesn’t damage plywood or the machine. If it gets someone alerted to questioning their .nc file and asking the Community for help or advice, it is serving useful purpose.
I agree it’s part of a larger misunderstanding, but should we alert on this? or
should we alert on gcodes that actually cause problems?
I am thinking that if it’s asking us to switch to a mode that is the only mode
we support, it’s worth not making noise about it. Only make noise if there are
g-codes in there that we don’t understand and are asking us to do things that we
We may want to implement some of the worst offenders, like switching to the XZ
plane, making them fatal errors rather than just noise in the logs
I am a HUGE proponent of logging, and spend a large part of my life going
through logs, and I am VERY tolorant of odd things happening and making noise in
But when it’s a common thing, and something that does no harm, (like telling us
to switch to the only mode we support), I don’t think we should make noise.
Just getting started and have not looked much at the code, BUT dear god please don’t remove a log entry like “Command G40 unsupported and ignored”. As somebody who spends a lot of time debugging of bad code (all code is bad, most is worse) and bad processes I can tell you for sure that you’ll only be causing grief for someone later (and remember that poor soul might be you) by getting into that mindset. That kind of message makes so much of a difference when troubleshooting. It’s a beautiful report, the only thing I’d possibly add is a ‘WARNING:’. I haven’t run Ground Control yet so If I’m talking out the wrong orifice I apologize, and if this is a GUI issue that stops the job, sure. If there’s an overwhelming efficiency issue then maybe; BUT fix the input, not the ‘noise’ please!
G40 is telling the system to turn off a feature that the maslow firmware doesn’t
support in the first place.
So modifying the firmware to make it a noop is actually the correct
implementation of that code on the maslow (silencing the code that turned on
that feature would be bad)
I’m not suggesting removing the “GXX not implemented” log message. I was the one
who suggested that it be implemented in the first place.
I am just suggesting that a g-code that disables a feature we don’t support can
be implemented as a noop, so that something that exports g-code and turns off
these features to be on the safe side doesn’t generate any log/warning messages.
Currently G40 is not understood by the firmware, and that’s why this is
If we instead define G40, and define it to do nothing, this log message will not
be generated for this code that does nothing, wihtout eliminating similar
messages for other codes that could cause problems.
G40 is being inserted by your CAM software based on the type of machine it
thinks it’s talking to. So to avoid including the G40 code, you need to pick a
different machine type. Maslow or GRBL are your best choices.
note that other than the noise in the logs, the G40 code doesn’t hurt anything
Technically G40 is implemented, cutter compensation is permanently off and it’s OK to turn off if it’s not on. OTOH G41 or G42 would be an issue.
Cutter compensation frees the CAM software from determining where the edge of the bit is going to move. You program the cut edge and the machine controller moves the spindle center so the sharp spinny bits cut along the line and make the part what you really thought you wanted. The math is tricky and involves travel direction (cutting along a curve is a different offset than in a straight line). When the cheap seat PCs have more CPU cycles per second than the ones we graybeards started with had in a week (well, perhaps a slight exaggeration) there’s little need for this feature in modern times.
As always, more than you wanted to know…
Arrived in Upper Fells Point. While collapsing buildings haven’t been a threat yet they’re installing new gas lines (and showing a subterranean history) so negative space dangers abound. So far we continue avoiding pushing the squeakie transport device into one even while gawking at the excavated trolley rails. Mrs Moose isn’t as easily distracted so I get the dog’s leash and she gets the baby carriage