Join GitHub today
GitHub is home to over 36 million developers working together to host and review code, manage projects, and build software together.Sign up
Erronious model size when G92 misinterpreted by gcodeInterpreter #1906
What were you doing?
Uploading a file and letting OctoPrint analyze the file
What did you expect to happen and what happened instead?
When printing, I was warned that my model could not be printed because it exceeded the print area of my printer. The model was determined to be 238.44mm × 190.00mm × 3687.78mm when it actually is 238.44mm x 190.00mm x 18.72mm. This is size listed in the file list details. The metadata.yaml shows that my printingArea.minZ is -3500.
I tracked this down to a G92 I have in my start GCode:
The source code appears to be doing some sort of G92.1 or G92.2 which has to do with setting offsets (but only zeroing them?). I've never seen a G92.1 or .2 in practice (Slic3r, Cura, Simplify3D) so I can't say if this is used for anything. The code does the right thing for
Why does this cause a problem? On every absolute "move" the position is incremented by posOffset. There is no Z parameter in the X/Y G1 moves, so
The values could be way off in the X / Y direction as well, but this is mitigated by the fact that almost all moves include X and Y coordinates so the accumulated position does not grow over time as it does with the thousands of GCode G1 lines without a Z parameter. The only way a G92 with an X or Y would cause a notable increase in estimated print time is if the toolhead just moved back and forth along a single axis, in which case the other axis would show a ever-growing position. The "Model Size" would roughly report the model size plus (or minus) the G92 X or Y offset then.
Branch & Commit or Version of OctoPrint
Master 1.3.2 release
Operating System running OctoPrint
Raspbian Jessie on Pi 2 B
Printer model & used firmware incl. version
C-Bot Core XY with Smoothieware
Browser and Version of Browser, Operating System running Browser
Link to octoprint.log
Logs indicate model is queued for analysis and then completed in N seconds
Link to contents of terminal tab or serial.log
Screenshot(s) or video(s) showing the problem:
I have read the FAQ. And I still love cookies even if I am not required to.
You have perfect timing. I just had someone on IRC send me a demo file because they were experiencing the exact same problem. I was going to look into this today, but now your ticket + the analysis you already did
In a nutshell: Should already be fixed on
As a side note, I just took another look at the code because I was wondering why I did solve it the way I did and not your way, and then I remembered that the internal offset is used for two things, tracking offsets set through
Well, dammit, why didn't I find that issue when I searched? Oh man it was because I just started typing in the search bar which already had is:open in it and you'd already fixed it. I can confirm that the change in fe585e7 / jumping to the maintenance branch does work around the issue with the G92.
But see now you've done the same thing to me, I've spent the last 30 minutes trying to decide if I think that a G92 should be stored as an offset though. For one, there's no way to 'pop' the offset back off (via G92.1 or G92.2) in the interpreter. Looking at firmware sourcecode for Marlin it does not support G92 as an offset, but Smoothieware does store it as a world coordinate transform and supports resetting it. I do think that I agree with you that mixing the purpose between the toolhead offset and a G92 offset is ill-advised, especially when the E distance interprets it as an absolute position but the other axes interpret it as an offset with no way to remove the offset (apart from applying a negative G92 which would definitely break printers!).
We programmers love to reduce complexity though, right? So if we're not going to change it to use its own offset so that we can support G92.1/2 I would remove the code in the interpreter's G92 and just interpret it as setting the absolute position like the E code does.
Nope, still open actually because 1.3.3 isn't released yet, only marked as solved. But neither I nor the reporter mentioned
I just pushed a commit that does what you suggested. I thought it through a bit more throughout the day, also took a look at how the gcode viewer handles it, and yes, setting the position instead of mixing the values into the offset does make more sense considering the definition of
I also noticed that the latter part was still missing, so I also added that.
Now I just hope I didn't miss anything critical - if you could also throw another look at it, that would be great!
Oh! Then it must have been because I saw the word Modelgröße and said, this isn't my problem, it is a problem for people on the moon because this is crazy moon language!
I'll pull and re-test once this print is finished but I switched back to