What do you mean by a crc? I think that it uses the ‘\r\n’ characters to detect the end of a line. The firmware will read characters into the buffer until it is full. When the firmware is ready to run the next line they are read off until a ‘\r\n’ is seen. Right now the buffer fills up with one line, then it is read off and run, then the “ok” command signals that the firmware is ready for another line and a new one is sent. Or at least that’s what I remember
how will this break grbl compatibility? why can they drive machines so much
faster than we can?
Sorry, I jumped from 'buffer overrun checking ’ to line-based crc checking based on the comment about a missing number in a gcode parameter.
RingBuffer::write() captures the characters sent by CNC_Functions.h readSerialCommands(), and checks for over-write as part of its _incrementEnd() function. Currently it prints "Buffer overflow!"if it sees that situation. GC could send a kill character if it sees that message. Firmware could take proactive steps as well?
1 Like
Looking further, if RingBuffer.::write() returned a value to indicate the buffer overrun, the logic in readSerialCommands() could trigger the immediate stop in the same way other portions of CNC_Functions.h do:
stopFlag = true;
checkForStopCommand();
This would have the same effect as using the ‘Stop’ button in GC, but wouldn’t need to go through the serial channel to take effect.
This seems like a minimal change that uses the existing methods and routines…
I’ve tried several different cuts and have one that is probably going to be OK for me. It’s a 4mm increment, calculating the arc rather than using G03.
On the subject of CRCs and gcode, there’s nothing stopping GC sending ‘wrapped’ gcode rather than raw gcode and having CRCs for each line or block of lines. The link between GC and the firmware is private. The only problem would be if some other host code wanted to talk to the Maslow, in which case you would have to use whatever that code used. The wrapping could be turned on with a flag so if GC was running then it was used, otherwise normal gcode.
1 Like
Easier kinematics, easier to drive hardware, better buffering, and years of refinement?
1 Like
Does this mean that your code is using G1 commands in tiny increments to make up the arc? I ask because I had a similar issue when i last tried using the arc commands G02/G03. This was back in GC v0.87. I have since just done all my CAM through Fusion360 which doesn’t output arc commands. Was a problem when I was originally programming through MakerCAM.
The way Fusion does it (G1) my arcs come out smooth. Just suggesting in case it helps you get up and running faster.
1 Like
Yes, my code does use G1 in small increments. can you share some of your code so I can see the increments used?
Do you see any hesitation when cutting?
I’m probably OK now with a 4mm increment and a new cutter, but it would be nice to see some other code.,
CalibrationTest.nc (14.3 KB)
(Circle Test) is where you should look. This is a very basic 90mm circle within a 100mm square. I believe I set the tolerance for the program to .01mm. The sled moves very smoothly throughout the entire operation.
The feedrates in that file are the original speeds I thought I could send to the machine, which is why they are so high. I now run around the maximum feedrate allowed (900mm/sec)
Jetrock,
Thanks for your post. It prompted me to look through the code as to what is supported and the valid syntax that is required. To this end when I saw your post I started to create a document that lists what is supported and the expected syntax. Not finished yet but think it could be useful for newcomers like myself if a code is generated that is not supported. I am not sure how to attach the PDF so any guidance would be welcome.
Along a similar line I think that a stub should be put in for G17 (given we are only cutting in XY plane anyway) rather than generating a message “G17 unsupported and ignored”. Only a minor point
Maslow-SupportedCNCCodes.pdf (45.8 KB)
2 Likes
What action should this stub take?
Blurfl
Given for the router is cutting in XY plane anyway (implied) the stub could be empty it just avoids the Not supported message as in this context G17 is very valid. The stub could be as simple as a break; from the case statement.
To be more specific in the function void executeGcodeLine(const String& gcodeLine)
I would add the following for the time being
case 17:
break;
Hope this makes Sense.
1 Like
Would it be better to not respond to unimplemented codes?
1 Like
I can see value in both options.
not responding is great, no bloat code and less room for error
on the other hand from a users perspective it can sometimes be good to get a message that certain commands are not available…
A cheatsheet with supported and unsupported codes may be a intermediate solution?
or a little gcode ‘scrutiniser’ that previews the gcode and highlites the little politicians…
Maybe a switch in GroundControl to choose whether the “unsupported and ignored” message appears at all? That’s a low-hanging fruit… Coloring the unimplemented codes in the ‘View gcodes’ pane for extra credit? 
1 Like
The gcode list is a good start, and could be viewed as a ‘to do’ list 
. Not sure if we’ll ever get a Maslow to do the tapping, boring or feed-per-revolution kinds of things, though. “…reach…grasp…” would apply, I guess
1 Like
Perhaps a more friendly “Currently not implemented” rather than a “Not Supported”? In this Family I’ve seen almost nothing that was not supported. As least is was discussed why it is not implemented, or why not now.
4 Likes
actually, it may be better to halt if you get an unimplemented code, because you
don’t know what is supposed to happen
the current warning at least gives you a clue that the machine is not doing what
it was told to do, and if the cut happens to still work you lucked out, but if
not, you have info as to what the problem is likely to be.
2 Likes
So maybe a setting for halt/alert/ignore?
1 Like
Good point to raise.
Blunt question. Grbl is some sort of in roadmap, but is it a guide for the Maslow until we have our own Post-Processor?
If so, we have a clear picture of commands that could end badly. Can we have the software decide when to ignore it and when to ask?
3 Likes