Repetier-Host on Windows and the G-Code parser

[rkonklex]

Repetier-Host on Windows seems to be sending CR+LF line endings, which cause Teacup to reply with a double 'ok' acknowledgement. Which causes host to think the firmware is processing G-code much faster than it actually is. Which wreaks havoc with actual prints. Also, occasionally there are errors in checksum.

Before I dive in and go around fixing things, I wanted to ask - is that a known issue? Is there any work on the parser planned?

Here is the comms log:

01:08:54.293 : Printer reset detected - initalizing
01:08:54.313 : start
01:08:54.520 : N1 M110*34
01:08:54.520 : N2 M115*36
01:08:54.520 : N4 M114*35
01:08:54.520 : N5 M111 S6*98
01:08:54.522 : N6 T0*60
01:08:54.522 : N7 M20*22
01:08:54.526 : N8 M80*19
01:08:54.528 : ok
01:08:54.529 : ok
01:08:54.567 : FIRMWARE_NAME:Teacup FIRMWARE_URL:http://github.com/traumflug/Teacup_Firmware/ PROTOCOL_VERSION:1.0 MACHINE_TYPE:Mendel EXTRUDER_COUNT:1 TEMP_SENSOR_COUNT:2 HEATER_COUNT:3
01:08:54.567 : ok
01:08:54.567 : ok
01:08:54.567 : N10 M111 S6*86
01:08:54.567 : N11 T0*10
01:08:54.578 : ok
01:08:54.578 : ok
01:08:54.578 : X:0.000,Y:0.000,Z:0.000,E:0.000,F:0
01:08:54.578 : ok
01:08:54.578 : ok
01:08:54.578 : ok
01:08:54.578 : ok
01:08:54.578 : ok
01:08:54.578 : ok
01:08:54.578 : E: failed to open dir. (5)
01:08:54.579 : ok
01:08:54.579 : ok
01:08:54.581 : rs N8 Expected checksum 32
01:08:54.581 : ok
01:08:54.581 : ok
01:08:54.581 : ok
01:08:54.581 : ok
01:08:57.566 : ok
01:08:57.566 : ok
01:09:00.627 : ok
01:09:00.627 : ok

[Traumflug]

Clearly a Repetier bug :-)

[Traumflug]

While this is Repetier just wasting bandwidth, it might be safe to simply ignore carriage returns nowadays. MacOS and partially Mac OS X used to use carriage returns only, so there is/was a reason to take them into account. But Apple hardware old enough to still run such applications has become rare, modern OS X applications are newline-only, too.

Any opinions?

[rkonklex]

The best solution would be to end parsing on either CR or LF, and not to send acknowledgement for empty lines. That way handling lines ending with CR or LF would be as it is now, and CR+LF could be treated as a line ending with CR plus an empty line.

Plus, Repetier is not just wasting bandwidth - the double 'ok' actually breaks the prints. In the log:

N1 M110*34
N2 M115*36
N4 M114*35
N5 M111 S6*98
N6 T0*60
N7 M20*22
N8 M80*19
ok
ok
FIRMWARE_NAME:Teacup FIRMWARE_URL:http://github.com/traumflug/Teacup_Firmware/ PROTOCOL_VERSION:1.0 MACHINE_TYPE:Mendel EXTRUDER_COUNT:1 TEMP_SENSOR_COUNT:2 HEATER_COUNT:3
ok
ok

You can see that the host sends commands in batches. The problem is, when it gets the double 'ok' from N1, it thinks it got two separate ack's from N1 and N2. The next double 'ok' is from N2, while the host thinks its from N3 and N4. And it goes on and on... it was funny to see it try print the 0,4mm thin wall calibration tower. Basically, it executed every other command, so instead of squares in every layer, it produced figure eights (more or less).

[Traumflug]

If Repetier breaks prints due to stray "ok"s, it's a Repetier bug. Please report it there or use a non-broken host like Pronterface. It's not the duty of a firmware to work around host bugs.

Answering empty lines with an "ok" is crucial in other situations.

[rkonklex]

Sure it's a Repetier bug. It has a couple more, so right now I'm using Pronterface.

On the other hand, firmware should reply with a single 'ok' for each line. It's reasonable to expect that. At the very least, Teacup should be able to treat CR+LF as one line ending.

Something in the spirit of the following algorithm:

0) Get next character
1) Got CR?
    1a) LF_SEEN is set => ignore the CR, clear CR_SEEN & LF_SEEN flags
    1b) else => do EOL and set CR_SEEN flag
2) Got LF?
    2a) CR_SEEN is set => ignore the LF, clear CR_SEEN & LF_SEEN flags
    2b) else => do EOL and set LF_SEEN flag
3) Go to 0)