Issues with adding a brim

[zwoop]

I’m printing ABS, using the left nozzle only. Without a brim, this works fine. But when I add a brim, after the first layer is done, it starts heating up the right nozzle as well, which of course is undesirable. It continues to print with the left nozzle though.

I’m using PrusaSlicer, latest version, curious if this is an issue with the slicer or the G-Code configs?

Thanks!

— Leif

[DrLex0]

Can you provide both a project file (3MF) and the .gcode output of both the print with and without the brim? What version of GPX are you using?

[zwoop]

Let me try again to make sure I'm not messing things up (but I tried twice last night). I'll collect the requested information as soon as possible. I'm running this version of GPX:

gpx/oldstable,now 2.5.2-1 armhf [installed]

Which seems a little odd, but it's on the OctoPrint distro I installed recently (and keep updated).

[zwoop]

Btw, what I did notice is that the right extruder starts heating up to the temperature of the "other layers" temp. I have first layer set to 235, which is what the left nozzle gets too.

These are the printer settings (from your package, which generally works great!)

[DrLex0]

It is pretty obvious what is happening, it's the same old problem caused by this issue in Slic3r/PrusaSlicer. Which I filed after nothing seemed to be happening with the same issue I originally filed on mainline Slic3r.

Normally this is worked around by the make_fcp_x3g script, which wipes any tool number argument in the temperature command for the second layer. This works by the grace of GPX continuing to use the same tool if no tool number argument is provided.

There are two possible causes why you are having this problem (next to the obvious problem of the lacking functionality in Slic3r/PrusaSlicer):

1. The make_fcp_x3g script is not invoked. Either because you didn't properly configure it, or because post-processing scripts are ignored when sending prints to OctoPrint. I don't know about the latter because I have never used OctoPrint.
2. The version of GPX used by OctoPrint behaves differently and does not stick to the last used tool. This is unlikely because your version only differs from mine in its third version component.

[zwoop]

Yeh I use the GPX plugin in octoprint. So maybe the bug is there ? I can switch to the script, but it was easier and quicker to just use the plugin (and it works most of the time).

Update: Yeh, so your explanation makes sense. Do you still need to see the .gcode etc.? Or I imagine we are at the mercy of Slic3r / Prusa to get this fixed ? Wonder if there's something to be done on the OctoPrint GPX plugin ?

Thanks again for your help, much appreciated!

[DrLex0]

Until the issue is fixed in Slic3r, the only way to avoid this bug is to run some kind of script on the G-code that comes out of PrusaSlicer, to apply the fix of removing the T argument when printing with a single-extruder profile. Simplest is of course to use the make_fcp_x3g script itself, or the BAT equivalent if you're using Windows. I have just updated make_fcp_x3g to make the GPX invocation optional, so you can use this script together with the GPX plugin in OctoPrint. I reckon it must also be possible to run this script from within OctoPrint, should you be using Windows and find it too much hassle to set up one of the scripts in Windows itself.

[zwoop]

Thanks for the help, it was incredibly useful! Good news, either I missed it (don't think so), or, an update to the OctoPrint GPX plugin added a new profile. I change print profile to one better suited for FFCP, and then this issue went away. So essentially the same fix as you suggest, it was just already done in the OctoPrint plugin!

(documenting this here in case someone else encounters this).