Make clear that offsets in the printer profile are only to be set for proper visualization if not set in firmware

[mriveralee]

What were you doing?

While attempting a multi-extrusion (a single object with another material at certain layers from a second extruder) print from a gcode file sliced directly in Slic3r and imported into OctoPrint, I noticed that the Gcode Visualizer offsets the second extruder layer positions based on the values in {Settings >> Printer Profiles >> Edit >> Hotend & Extruder >> OffsetT# (x,y)}.

This appears to be unexpected behavior as the coordinates in the sliced gcode file position the extruder movements with respect the global coordinate frame of reference and assume any tool change movements/offsets are handled in firmware specifications.

That is to say, extrusion at location (50, 50) in the global frame of reference on the print bed (should be the same for any extruder on the printer. The firmware repositions the selected extruder accordingly via an offset so this happens.

In my case, my gcode visualizer positions the second extruder layers +62 mm in the X-direction; however, the print reflects the originally sliced model which has these layers inside the object as seen in the attached images.

Repro Steps:

1. Slice a dual extrusion part in Slic3r where both parts are ontop of one another.
2. In OctoPrint set up Hotend & Extruder to have 2 Extruders. For T1, offset X = 62, Y = 0. Save.
3. Load Gcode file into OctoPrint
4. View sliced layers in GCode Visualizer
5. Witness the layers from the second extruder being drawn offset from the object.

This is the unexpected behavior as the slicer file specifies the correct global locations for extrusion; the tool change offsets are handled in the firmware.

What did you expect to happen?

The drawn gcode layers in the visualizer should be aligned inside of the object they were sliced from had them colocated on the bed.

This probably means the extruder offset should not be used to position where the layers are drawn for different tools, since the X,Y coords in the Gcode are in the global frame of reference.

What happened instead?

The gcode layers for extruder 2 were drawn in the gcode visualizer way off to the side away from the print (+62 mm away).

Note that the printed piece is correct, only the Gcode Visualizer is incorrect in displaying the gcode.

Did the same happen when running OctoPrint in safe mode?

Yes.

Branch & Commit or Version of OctoPrint

Octoprint 1.3.5 master branch

Operating System running OctoPrint

Running OctoPi on Raspberry Pi 3.

OctoPi's version can be found in /etc/octopi_version]

Printer model & used firmware incl. version

Folger Tech Prusa i3 2020 (with an additional extruder) running Marlin v1.1.5

Browser and Version of Browser, Operating System running Browser

Google Chrome on MacOSX

Link to octoprint.log

https://pastebin.com/VRxc7CfH

Link to contents of terminal tab or serial.log

Serial.log file was empty.

Link to contents of Javascript console in the browser

https://pastebin.com/1cahVyGd

Screenshot(s)/video(s) showing the problem:

The bug in the gcode viewer that draws the second extruders layers off to the right

The originally Sliced Model for dual extrusion - notice the two types of material are colocated in the X,Y coordinates.

I have read the FAQ.

[foosel]

the tool change offsets are handled in the firmware

In that case don't specify them in OctoPrint. There are two approaches to doing multi extruder setups - one is defining the offsets in the slicer, one is to define it in the firmware. The offset in OctoPrint's printer profile is to be able to compensate for the former, since then all coordinates in the sliced file will be offset. If you have it defined in the firmware, set the offsets in OctoPrint to 0 and stuff should work just fine. There's no way to auto detect what kind of setup you have based on your GCODE files (should your slicer produce comments that might help here, those will be slicer specific and unreliable since not part of a formal specification).

I'll add a "if those aren't handled by your firmware but by your slicer" to the corresponding fields in the printer profile however to make this clearer.

[foosel]

Note has been added. Pushed to maintenance, soon devel, will be part of 1.3.6.