Makerverse M2 Due G-Code Errors with GRBL Error Code 33 AND 24

I am running an M2 machine with Due controller and Makerverse 1.0.6.

I have created new G-Code in Fusion360 (a simple pocket) and I am getting G-Code Errors from the system in every program I post process. I have re-run an old program without any errors or issues, so the M2 controller and Software seem OK.

The cutting settings in Fusion are identical to previous programs, and I’m using the same post processor (the Maslow one).

This is happening since Fusion360 went to personal use, so I suspect that is the root cause, but I cannot see any issues with my code. Makerverse/M2Due is throwing back G-Code errors for all G2/G3 moves and with arcs disabled even simple linear moves are throwing errors.

The latest version of Fusion outputs a comment over 3-4lines about the restrictions for personal use that has to be deleted for the program to run at all, but I know how to disable that by editing the post-processor.

It feels like the individual moves might be too small for the controller to execute? but I don’t see why this is an issue now - unless fusion has changed something…

“” runs fine. “Pocket” doesn’t and get lots of error code 24 errors thrown up for invalid G-Code (first one is Line 22 G1X20.488). If I post the Pocket program with arcs every single arc line of code throws out error 33 (13.1 KB)
Pocket (4.7 KB)

Any ideas/support greatly appreciated
Those involved with updating Makerverse and the Due firmware may already know the answer to what these errors are @zaneclaes @Orob

Hmm, I’m not sure, but maybe these quick findings from looking at the firmware will help…

Error 33 specifically refers to STATUS_GCODE_INVALID_TARGET, and it will happen if:

  • The current location and target location are the same
  • [Arcs]: difference current location & target is larger than 0.5mm or larger than 0.1% of radius

Error 24 is STATUS_GCODE_AXIS_COMMAND_CONFLICT, and happens if a second command is received before the first is completed. The fact that the G1 does not have a space before the X is a bit suspicious to me in your last screenshot.

Thanks for that, it does suggest there is an issue around the size of the moves that are being created, or accuracy of the arcs programmed. It’s a relatively small pocket, although I haven’t had a problem with small moves before.

Someone on the facebook group has suggested using the grbl post processor to get around similar issues, I’ll try it and compare the 2 posts and look for difference in settings/tolerances.

The G1X… without a space was me fiddling with post settings and turning off spaces in the code - same error with or without the spaces.

In Fanuc G-Code every line has to have an “End Of Block” EOB command i.e. a ; G1 X5 Y6 Z2; I don’t think GRBL will like that, but in fanuc and other G-Code based systems is makes it very clear when a block ends…

Ok, so I’ve been through he GRBL vs Masolw Post processors, there are quite a few differences in both, GRBL has functions in it that Maslow does not (to support more machines I suspect) and Maslow has functions and features GRBL does not. But the main difference in how the 2 handle tolerances and arcs is below

GRBL Left, Maslow Right
Tolerances appear to be the same in both,
max circular sweep in grbl is 180, maslow is 90,
grbl allows helical moves, and circular in any plane
Maslow does not allow helical and only circular on XY plane

Running the same pocket cutting process from Fusion gives the following 2 programs, again GRBL is on the left, Maslow is on the right

G94 is specifying feed per min (default in makerverse I think, but might be causing the error 24 as it is missing from the maslow post.
G40 just cancels all tool compensation (not used in makerverse as far as I know), but is not in the grbl post.
the green line stops makerverse from running - I suspect this is to do with the maximum line length in the Due or Makerverse leading to it being read as multiple lines. But I know how to remove this from the Fusion Post processor anyway.
The interesting point is the G2 moves - GRBL has one line, the Maslow post has created 2 lines with a mixture of values that do and do not match the GRBL program - possibly because of the max 180 vs 90 circular arc.

I will try running the code from the GRBL post processor later and see if it runs.

for info this is the fusion tool path

I think the code fails on the green linking paths

It’s not terribly surprising that the Grbl post would work on the M2. The M2 firmware, after all, is actually the Grbl firmware. It bears very little resemblance to the original Maslow firmware. OTOH, the Maslow post-processor may be compensating for peculiarities of chains (I haven’t looked at it). FWIW, I’ve used the Maslow post-processor for dozens of (complicated) prints with my M2.

I don’t see anything in the M2 firmware that would make me think G94/G40 would do anything “bad.”

I’m not sure what you mean. Makerverse does not have “defaults” or “compensations.” For all Makerverse cares, the Gcode could actually be Klingon – it wouldn’t change how Makerverse operates. It just blindly sends the code, line after line, to the Maslow. All the errors, compensation, etc. happen within the Maslow firmware.

Interesting. I would actually expect this to work better with the M2 firmware, because each move is smaller (and the STATUS_GCODE_INVALID_TARGET error happens when the moves are too big).

I just meant tool compensation isn;t used so G40 should be irrelevant

Yes, but having just run both the GRBL post processed g-code works, the Maslow Code fails and errors out, which is just weird. Both basically make the same moves, but only the grbl post will create this program and run in Makerverse/M2.

Finally just to prove myself right or wrong I changed the stepover from 2mm to 1.9mm in fusion and post processed in the maslow and grbl posts. Both run fine! so who knows, I may have just hit a crunch point with a certain shape in fusion that the maslow post is messing up - or the G94 code is needed to be called at some point - but G94 is active by default in grbl.

1 Like

Sounds like a good theory to me. Correct me if I’m wrong, but I believe stepover is supposed to be <= 50% of the cutter diameter. So if your end-mill is 1/8" (3.175mm), 2mm stepover seems a bit high (?)

The stepover can be as much as you are comfortable with your cutters taking without overheating, wearing too quickly or breaking. When you first plunge a pocket and make the first move you are effectively running 100% stepover, the full width of the cutter. The same with tracing a 2D profile, like cutting out a shape, it’s running at 100% cutter width

With a 1/8 bit in softer materials I have been happy at slightly lower feed rates cutting a bigger stepover, like 2mm on a 3.175mm bit up to 3mm deep - which is quite aggressive for the maslow, but fine for softer, lower density materials (OSB or Stirling board for example). This program (amongst various) was written oo test cut small pockets at various feeds/speeds/depths and stepovers in a harder material - High Pressure Laminate or HPL - which has a density about 3x that of birch ply, and melamine hard faces on both sides. I’m making a new sled…

I haven’t found anything in Fusion360 restrictions that will stop a maslow user yet - maybe one could be not being able to change tools mid program anymore, but that just means creating 1 setup per tool type