grblHAL / core

grblHAL core code and master Wiki
Other
305 stars 74 forks source link

Update the documentation for Sender Developers with regard to `\n\r` pairs. #394

Closed tatarize closed 6 months ago

tatarize commented 7 months ago

CRLF pairs, and all multiple line-ends with no commands are ignored.

The documentation doesn't mention it, https://github.com/grblHAL/core/wiki/For-sender-developers

            } else if ((c == '\n') || (c == '\r')) { // End of line reached

                // Check for possible secondary end of line character, do not process as empty line
                // if part of crlf (or lfcr pair) as this produces a possibly unwanted double response
                if(char_counter == 0 && eol && eol != c) {
                    eol = '\0';
                    continue;

But, this stripping behavior is different than GRBL which would give you 10 ok for $\n\n\n\n\n\n\n\n\n\n\n\n but GRBLHal would give you 1 ok. It matters a lot with regard to character counting protocol.

terjeio commented 7 months ago

Are you sure you are sending what you think? When I send line feeds (^J or \n) from a terminal I get one ok per line feed sent.

tatarize commented 7 months ago

GRBL protocol.c:

    while((c = serial_read()) != SERIAL_NO_DATA) {
      if ((c == '\n') || (c == '\r')) { // End of line reached

        protocol_execute_realtime(); // Runtime command check point.
        if (sys.abort) { return; } // Bail to calling function upon system abort

        line[char_counter] = 0; // Set string termination character.
        #ifdef REPORT_ECHO_LINE_RECEIVED
          report_echo_line_received(line);
        #endif

Replies 2 ok if sent $\n\r. It's a substantive difference.

tatarize commented 7 months ago
<--$

--> [HLP:$$ $# $G $I $N $x=val $Nx=line $J=line $SLP $C $X $H ~ ! ? ctrl-x]
$$ $# $G $I $N $x=val $Nx=line $J=line $SLP $C $X $H ~ ! ? ctrl-x
--> ok
--> ok / 1 -- $
--> ok
--> ok / 0 -- 

Regular grbl if sent CRLF as the line end will reply 2 different ok

I'm not saying yours is wrong, obviously command "" does not need a reply. I'm only saying document that difference.

tatarize commented 7 months ago

Sending: "?\n\n\n\n\n\n\n\n\r\r\r\r\r\r\r\r"

<--?

--> <Idle|MPos:76.663,-121.663,0.000|Bf:99,254|FS:0,0|WCO:0.000,0.000,0.000>
--> ok
--> ok / 15 -- ?

--> ok
--> ok / 14 -- 

--> ok
--> ok / 13 -- 

--> ok
--> ok / 12 -- 

--> ok
--> ok / 11 -- 

--> ok
--> ok / 10 -- 

--> ok
--> ok / 9 -- 

--> ok
--> ok / 8 -- 

--> ok
--> ok / 7 -- 
--> ok
--> ok / 6 -- 
--> ok
--> ok / 5 -- 
--> ok
--> ok / 4 -- 
--> ok
--> ok / 3 -- 
--> ok
--> ok / 2 -- 
--> ok
--> ok / 1 -- 
--> ok
--> ok / 0 -- 
terjeio commented 7 months ago

Replies 2 ok if sent $\n\r. It's a substantive difference.

Regular grbl if sent CRLF as the line end will reply 2 different ok

I consider this bad behaviour if not a bug. \r\n and \n\r is, IMO, to be interpreted as a single line terminator.

I'm not saying yours is wrong, obviously command "" does not need a reply

IIRC according to legacy Grbl specs it does - a 'ok' reply should be returned.

I'm only saying document that difference.

Will do.

Sending: "?\n\n\n\n\n\n\n\n\r\r\r\r\r\r\r\r"

This is, again IMO, silly. Keep line endings consistent and to reduce overhead, use only \r or \n.

terjeio commented 6 months ago

The Wiki page has been updated with a note about this.