In Grbl the 'ok' response cannot be used for handshaking because it is returned by Grbl after each command is sent to signal that it has understood the command, and that the command was syntactically correct, this 'ok' is always returned before the command is actually executed. If I am going to send a lot of bytes, one needs to know when the buffer is full so that one does not overrun the buffer. This is an obvious fact in all serial communications. The answer to this question is nothing to do with knowing Grbl's buffer length, because this only tells you not to send more than buffer length bytes, INITIALLY but subsequently one still has no knowledge to do with when those bytes in the buffer are consumed, and therefore send the next buffer-full. The question then remains, how does one efficiently handshake with a Grbl controller.
Yes, but the section which mentions that when an 'ok' is received by the host computer : "this guarantees both to the host PC and Grbl, the programmed G-code has been sent and received properly". It is a bit vague because the statement "G-code has been sent and received properly" lacks a further statement, that says "AND the command has concluded or reached such a stage in the processing pipeline where it is safe for the host to send more data". To me this would sound like a more full proof handshake method, unless if I am assured that the last part that I said was missing is actually somehow implied .
The controller won't respond with 'OK' (or 'Error') until it has parsed the command and passed it to the queue in the 'look ahead' planning buffer within GRBL. You will never know that any specific command has been executed, just that the machine reports 'Idle' status when all commands have been executed.
The 'and passed it to the queue' statement is all I needed to know because it means there is at least one empty slot in the input buffer. However, for future I might request for stability that there is a command that the PC can send to tell how many slots are free in the input buffer or simply slots>n , because as it stands, in the unlikely event the PC misses an 'OK' it will hang! While on the subject of change requests, can you add a bit in the status which is tracking the state of the probe pin (closed/open), unless there is one already which I have missed. The idea is to have a way of checking if the probe wiring is intact. This can easily be done by asking the user to connect the clip on to the target body and warn the user if there is no connection, potentially preventing a dangerous probe operation should the bit go flying through the target!
Keep reading the wiki - it's already there (literally the next section to the one I linked to above). If probe or limit switches are triggered, it is reported in the status (pn but you'll have to dig a little deeper into the documentation for that. It sounds a bit like you're trying to 're-invent the wheel' - There are a multitude of tried and tested G-Code senders that have worked perfectly reliably with GRBL for years - what are you aiming to achieve?
Performed a $C command The command run until a few lines before the end of the Gcode file then stopped with error:2 The line that this error was triggered on is: "Z7.000" The line before it (in case of a space between telegraph poles issue) is: X8.969Y10.322 Can't for the life of me find any errors here!
Writing a Grbl Host from scratch is hard. Use an existing one if possible. Otherwise, really just a case of good development know-how + the Grbl wiki. Or the gcode really is invalid (XYZ moves but no G0/1 modal earlier?) CONTROL uses the character counting buffer. Exactly as described in the Grbl wiki. Easier to use a known good sender and do UI customization perhaps. Getting started with Javascript Macros in CONTROL / Library of Macros created by the community Then you don't need to redeveloped all of it down to queue manager, just build on top of it? Your response is still quite vague. Obviously you want to send gcode. But why not use a standard host? If its just because you want to develop your own, you can't get frustrated, you got to develop and debug as you go. Grbl's protocol is great and works great. Many great hosts have been developed for it. It works. 100%. Any issues is your code not working and that can usually be solved by rereading the Wiki. Firsthand knowledge, I built CONTROLs queue manager, with help from another developer, almost 2 years work part time. Grbl and its protocol is solid. Refining your own code takes time. Never had a question about how to interface with Grbl that the wiki and a little trial and error and logical thinking couldn't solve and for years now its been 100% solid. Unmerged (unlikely to be merged, should be a macro not a core change) example using CONTROL feat(probe/safety): require probe to be touched before probing by tippfehlr · Pull Request #339 · OpenBuilds/OpenBuilds-CONTROL we already parse Pn: feedback and have it available in laststatus object for use in your own macros Code: if (laststatus.machine.inputs.contains("P")) { // do what you got to do } You have to count bytes.. If the "free slot" as you think of it was say, M8 (2bytes) you can't go and send "G1 X1034.345 Y1106.678 Z250.665 F10000" (39 bytes) in it place. You got to count.
I have no problem with developing controller apps, years ago I specified and developed the Mission Electronics multi master Hi-Fi bus then named Mission-Bus, Grbl is no comparison in complexity. Besides I have 99% finished the project and it works great. The few questions I had seem to be small details of a completed framework which I must have missed in the Wiki, but I feel you are transferring a small question into a large inability issue. I develop in C# I do not know which language your version is, my guess it's in python or some other non ,Net language? I can write in Python, and sometimes use it for small scripts but do not want to on a major project.
And I have got the answer to my question I posted, $C check task considers comments inside "(...)" as errors, specifically error:2. In case someone wanted to know in the future.
comments cannot contain anything but plain text (as stated in the Wiki) , and no embedded comments so (this is a comment (with a sub comment)) will always fail, this is how GRBL acts and has always done so, mainly because the 8bit microcontroller it was developed for placed limits on how much parsing it can do in realtime, but probably also because the RS274 Gcode standard says so. Even an ESP32 or similar 32bit processor has limits on what it can handle in realtime. the postprocessor should be filtering the comments, as is done in the post for Fusion360, limit line length, and limit accepted characters, this can also be done in the sender, dont send comments, but not e that GRBL accept embedded comments like "G0 X67 ; his line is usefull" so you must still send the G0 X67 part Code: function writeComment(text) { // v20 - split the line so no comment is longer than 70 chars if (text.length > 70) { text = filterText(text.trim(), permittedCommentChars); var bits = text.split(" "); // get all the words var out = ''; for (i = 0; i < bits.length; i++) { out += bits[i] + " "; // additional space after first line if (out.length > 60) // a long word on the end can take us to 80 chars! { writeln(formatComment( out.trim() ) ); out = ""; } } if (out.length > 0) writeln(formatComment( out.trim() ) ); } else writeln(formatComment(text)); }
