Where do these numbers come from that appear to be multiplied to every line of gcode?

Development
1

Why do the lines of gcode showing in the octoprint terminal have a number that seems to be multiplied at the end?

I'm curious about what the extra numbers do and how they are derived because I think it could be a hint at an issue that I've been trying to diagnose for quite some time. The printer was misbehaving when I exported these lines, then ran the same gcode again and got a good print. Those numbers at the end of each line are different.

Sad-GCode
Sad-GCode1000×500 76.6 KB

Compare those to the corresponding lines in the raw gcode file.
Compare again, those numbers are different here where I the printer was behaving properly.

I'm running klipper on a Ras pi 4B Rev 1.4 (8GB) on a Prusa MK3S+.
Octoprint V 1.8.6

Details on the more complex issue that I'm attempting to track down if you're curious:

My printer will randomly glitch out and print skewed shapes.
This seems to happen after either a long amount of up-time for the ras-pi, but not necessarily related to print time.
Diagonal lines for top surface infill become oval loops. Circles become ovals.
Curiously, lines that are parallel to the printer's x or y axis come out just fine.
I have ruled out all mechanical issues that could possibly cause this.
It must be in the electronic hardware, firmware, or software. One needle in 3 haystacks.

Anyway, it's just a ghost in the machine and after dozens of hours trying to diagnose, I don't expect anyone here to solve it.
So far it's impossible to reproduce intentionally and occurs rarely, so that's why I'm not providing every detail relevant to this problem.
If you have ideas despite the lack of context, I'd love to see it.

2

It is a "checksum". The simplified explanation is that OctoPrint adds up all the characters of the the original gcode line and adds the "sum" after the *. When receiving the gcode line, the printer firmware does the same calculation for everyting before the * character, and "checks" the result against the it received after the *. If the two do not match, something went wrong sending the line (a bit was flipped, a byte is missing), so the firmware ca kindly ask OctoPrint to send it again.

In reality the actual calculation is just a bit more involved that simply adding up the characters (or else the number would be bigger), but that is not important. What is important is that that number is used to see if the gcode has transfered to the printer ok, line by line. Even though the * character is being used, it has nothing to do with multiplication of the gcode.

1 Like
3

Thanks for helping me understand!

I ran the print again, no glitch, and the checksums came out the same as the other good print!

image
image384×516 10 KB

So whatever problem I'm having, those checksums are an indication.

Edit: Maybe it's not an indication, because the line numbers are different as well...
I'll check for a new line around when the glitch began.

4

You may should notice, that the line number (N.....) caluculates into the checksum.