About a week ago I got a new bug report on OctoPrint’s issue tracker:

GCode Viewer Visualisation Problem

The problem

The visualisation in GCode viewer ist not correct. The print is OK. See gcode file (zip) on Layer 43 to 47 and 49

And screenshot

You already saw the included screenshot, and it shows that there was a spike being visualized in the GCode Viewer that wasn’t actually there. My first attempt at reproduction failed spectacularly – the file looked exactly like it was supposed to. Then I noticed that the OP was using Google Chrome however (adding the detected user agent to the system information contained in OctoPrint’s new System Info Bundles already paid off!) and tried with that instead of my usual Firefox, and lo and behold, I saw the issue.

Scrolling a bit through the file revealed further defects, as also mentioned by the OP, e.g. this one:

At this point it was clear that this was a Chrome-only issue. But was it a bug in OctoPrint or possibly a browser bug? More information for that was needed but not readily available, and the file was also too big to quickly gleam anything from the GCode itself that could possibly help to narrow down on the problem.

So the first step was to create a minimal GCode file that showed the same error. For this I took a look at the reported layer height in the viewer on the layer a defect was visible and then narrowed down on the affected lines by using the horizontal command sliders to further limit the view. That way I quickly found that these were the problematic lines:

G1 X173.595 Y103.9 E247.16716
G3 X173.600 Y126.097 I-105613.507 J39.645 E248.20080
G1 X169.552 Y126.098 E248.38933

More specifically, the error was caused by the contained G3 command, which instructs the printer to move in a counter clockwise arc from its current position to the given X and Y coordinates, with the center of said arc offset by the given I and J parameters. In the case of these lines, that meant to move in an arc from (173.595, 103.0) to (173.600, 126.097) with the arc’s center at x = 173.595 + (-105613.507) = -105439.912 and y = 103.9 + 39.645 = 143.54500000000002. Or in other words, a rather short arc with an enormous radius of over 105m that was more a straight line than an arc really. And that line was being drawn too long, causing the weird spike in the rendition.

In order to understand how that could happen however we need to take a look at how the GCode viewer is implemented and how arcs work in that implementation. At its core, the GCode viewer is an HTML5 2D canvas on which the path described in a GCode file gets drawn. Commands like G0 and G1 that describe straight lines are drawn using lineTo, arcs as described by G2 and G3 are drawn using arc.

arc takes six parameters: the x and y coordinate of the center of the arc, the radius r, the startAngle determining from which angle to start drawing the arc and the endAngle until which to draw the arc, and a flag that’s true for counter clockwise and false or empty for clockwise. It is obvious this doesn’t directly translate to the data contained in the GCode itself, where we rather have three points defining the arc – a start point, and end point, and the arc’s center. So we need to translate this into the data required by the arc method. Using some trigonometry, that is fairly straightforward:

// given: G2/G3 X<endX> Y<endY> I<i> J<j>, <startX>, <startY>
arcX = startX + i;
arcY = startY + j;
r = Math.sqrt(i * i + j * j);
startAngle = Math.atan2(startY - arcY, startX - arcX);
endAngle = Math.atan2(endY - arcY, endX - arcX);
ccw = (command === "G3")

My first guess was that the result of this conversion was somehow different between Firefox and Chrome, and so I modified the GCode viewer to log the calculated values and then compared the two outcomes. The values were completely identical between both browsers, so what was being fed into the canvas arc command was identical and yet produces different results. Why?

My next approach was to add some more visual debug output to the viewer itself. I modified it such that the arc parameters as calculated would actually be drawn on the canvas as well, in form of a geometrical pizza slice showing the arc’s center, its “legs” and its rim. And this is where I saw a difference in the rendered output. Where in Firefox the arc’s rim and its legs met perfectly:

in Chrome the rim overshot:

So while the calculated parameters were correct and in both cases provided to the arc method just the same, Chrome was rendering the wrong segment length!

I suspected a rounding error and thus started searching for matching reports from other people. I couldn’t find a specific bug report, but I came across a post on Stack Overflow that sounded mightily familiar: HTML5 canvas arcs not rendering correctly in Google Chrome, from 2011. A ten year old post… could it be?

Honestly, I still do not know if this indeed described the same issue or not, or if there’s a Chrome ticket describing this behaviour – I’ll continue to look, but first and foremost I was focused on fixing this problem in OctoPrint’s GCode viewer. The Stack Overflow post provided a code snippet that reimplements arc utilizing bezier curves, and so I gave this a try. Long story short, OctoPrint’s GCode Viewer as part of version 1.7.0+ will ship with a Chrome-only arc replacement that will be enabled by default, but can also be disabled in real time, with great effect:

And the moral of the story: It rarely is a browser bug. But sometimes, all signs say it indeed is and a workaround is the easiest solution.

The original version of this post was published as a Twitter thread on March 23rd 2020. I figured I should give it a more permanent home here since IMHO it was a quite fun story.

Since everyone can use some entertainment right now, how about a battle story on how a year ago I spent almost two weeks trying to wrap my head around a really weird issue of a lagging GCODE viewer and overall print progress reporting in OctoPrint and finally figuring it out?

Our story begins around the release of 1.4.0, when a new topic on the community forum showed up:

Curious issue with print progress

The print progress figures on my Octopi setup are lagging behind the actual print. […] Nothing is broken - anything I throw at it (an Ender 3) prints fine but as a print progresses, the percentage complete, current layer, and sync’d gcode viewer gradually lag behind what is actually being printed. For example, on a print with 400 layers, as the last layer is printed the reported progress and current layer is around 96% and 385 respectively. If I do a quick calculation of the displayed Printed/Total file size figures it works out at 96% but what it has actually printed is over 99%. When the print finishes the numbers jump to 100% and 400 and everything is fine.

[…]

This was indeed a very curious issue, since due to the nature of the communication with the printer and buffering in the firmware the progress is usually rather slightly ahead than behind. Some quick testing on my end showed no reproduction, however more and more people chimed in with the same observation.

I was stumped.

My first approach was to collect information from those affected by it. Printer model, firmware version, installed plugins, used slicer and so on. It soon turned out that all affected installations were using Ultimaker Cura as the slicer.

A quick test by the OP with a different slicer confirmed that it indeed just occurred with GCODE sliced by Cura for him, same file in another slicer had everything work as designed. However, comparing the GCODE revealed no immediate differences that would explain this, and what actually is in the file also doesn’t really play into progress tracking. My own experiments with Cura failed to reproduce.

Convinced that the issue must be some sort of delay between the backend and the frontend – maybe due to network issues? – I whipped up a plugin (since deleted) to log progress on both ends to a log which could then be shared and analysed. The first results came in an guess what? I had barked up the wrong tree, the reported progress was identical. So back to square one.

I still couldn’t reproduce it on my end and was starting to get really angry at this issue 😅 I finally threw a copy of some GCODE files now shared by the reporter of the issue on my own printer and finally I could reproduce. Which doesn’t mean I had any idea WTF was going on though.

After many test prints, head scratching and going through the files with a comb I finally noticed something. The files with the issue had CRLF (or \r\n) line endings. Those without (including my own sliced files) had just LF (or \n) line endings.

So that made me go 🤨 Some cursing and breakpoint setting later I had proof that the reported progress in backend and frontend was flawed to begin with. I could see that a line was being reported with a file position that it actually was not located at in the file, and which instead belonged to a couple lines earlier. Which meant my positions were reported wrong right at the source – with a lag. And then it suddenly hit me.

But before I can tell you what was happening I need to give you some background on how OctoPrint reads GCODE files it’s printing in order to understand what was going on. Printed files are read line by line because that is how they are sent to the printer. For that OctoPrint uses the readline method of the file stream. And that works by reading chunks of data from the file until a line separator is found, returning everything read up to this separator and saving the rest for the next line to be read. That means the file will have to be read further than what is returned. And that means that the position in the open file as reported by tell on the file stream will always be slightly ahead. For progress reporting in OctoPrint however I need to know the exact byte position of each line in the file. So what I do instead of relying on the internal and slightly ahead file position is that I increase my own position indicator by the length of the line read from the file. And this is where my problem was located.

It turns out that for some reason I wasn’t getting the lines back from readline with the original line endings attached. Instead I always got LF, even for files with CRLF. And that means I was counting one byte short for every single line in CRLF terminated files. One byte short per line doesn’t sound like much, but that adds up through a file with several hundred thousands of lines, to a point where progress reporting will be off by whole layers the further in the print and thus the file you are.

But what was the reason for this popping up in 1.4.0? I hadn’t modified the code in question at all. It had been the same since 2016 actually. Well, it turns out that a tiny change during the Python 3 compatibility migration done to a helper function I used in that code had interesting side effects: switching from codecs.open to io.open.

It turns out that io.open (and thus Python 3’s built-in open) by default will open text files in “universal newlines mode” (see PEP278), meaning it will happily parse every common line ending, but convert it to LF before returning. Which caused my off-by-one issue in files with CRLF.

And the fix? Setting newline="" on the open call:

diff --git a/src/octoprint/util/comm.py b/src/octoprint/util/comm.py
index 67191a7af..a6dfc1e24 100644
--- a/src/octoprint/util/comm.py
+++ b/src/octoprint/util/comm.py
@@ -4078,7 +4078,7 @@ def start(self):
 		"""
 		PrintingFileInformation.start(self)
 		with self._handle_mutex:
-			self._handle = bom_aware_open(self._filename, encoding="utf-8", errors="replace")
+			self._handle = bom_aware_open(self._filename, encoding="utf-8", errors="replace", newline="")
 			self._pos = self._handle.tell()
 			if self._handle.encoding.endswith("-sig"):
 				# Apparently we found an utf-8 bom in the file.

The moral of the story? Don’t trust your file position calculations. I could have saved myself a lot of time on debugging this if I had just looked there first instead of assuming this code to be fine 😅

In the end, even a year later, I still have no idea why Cura produced CRLF code for some and LF for me, but I also never really looked hard. A UNIX vs Windows issue can be ruled out here since the affected parties and me were all using Windows. It made me learn something about io.open and was a valuable lesson on wrong assumptions however!