I noticed that the model size reported in Octoprint (x and y axis) is much larger than the actual model shown in Cura. The model in Cura is 56mm x 56mm x 33.6 however in Octoprint it shows 161.51mm x 136.20mm x 33.63
The model prints normally and the correct size just the size shown in the window when looking at the details in Octoprint seems way off.
What did you already try to solve it?
I re-sliced the model and re-uploaded it. No difference.
I looked at the supplied gcode, determined that @pldugan has a LulzBot TAZ 6, same as me.
Using what @Ewald_Ikemann said, I theorized that the nozzle wipe sequence and the moves to probe points in the start gcode were being counted when determining the min and max X and Y. With the current TAZ 6 firmware, all of these moves in the start gcode can be eliminated.
After that failed to fix the issue, I found more moves in the end gcode and removed those.
That didn't fix the issue either but after a few other experiments and I discovered that the model size in the file list doesn't match the model size in the GCode Viewer.
My conclusion is that there may be a bug in OctoPrint. More investigation is warranted.
I've not looked t the code, but I'm not convinced that OctoPrint looks at things like the G28. After all, even with a prime line, it might not start at 0,0. Code sliced for a delta might have negative values for the minima. Most slicers put the prime line some way in from the edges, so measuring from the home position makes no sense.
I thought OctoPrint read the dimensions from the MAXX, MAXY etc values in the comments (if present), and those comments have values for MINX and MINY as well. Surely it would make sense to use those...
It does, I have looked at the code. When there is a G28, current position is reset, which is sensible because that is exactly what a G28 is doing for the printer as well.
However, I since looked closer at the gcode interpreter code & this gcode in question, and the negative extrusion is not the cause of recording the min/max position. It is slightly further on in the file, as extrusion must be positive & on a move of another axis to be recorded as part of the min/max. Explanation with the << comments.
G1 E-30 F100 ; retract filament << Current E position is -30
... then some wipe sequence, no E movement
G1 X0 Y0 Z15 F5000 ; move up off last probe point << Current X/Y position is definitely 0,0
... some heating commands, no movement
G1 Z2 E0 F75 ; prime tiny bit of filament into the nozzle << Current E position is now 0, which means +30mm of extrusion at 0,0.
So my theory was correct, the commands listed were not quite.
If you were to write a gcode like this:
G1 X100 Y100 E5
Then it would draw a line from the home position to X100 Y100, the line has a minimum 0,0 maximum 100,100
If you wrote gcode like this:
G1 X50 Y50
G1 X100 Y100 E5
The line is drawn 50 -> 100, so minimum 50,50 maximum 100,100. This is how prime lines are usually done - move to the position first, then draw the line.
It doesn't, because there is no standard to how the comments in the gcode file are laid out. Different slicers, different versions of slicers, there is no way to reliably parse the information.