Repository navigation
Nozzle scraping print returning to prior location after tool change #48
Description
After setting up the INDX and going through the calibrations (including z offset) per the documentation, during print, when the tool changes, the z is lifted to allow the tool to be returned to the dock without colliding with the print. After the tool changes, the z is dropped back to the print height as the nozzle heats up, prior to the nozzle being moved back to position. This has had the unfortunate impact in my case of causing the nozzle to scrape the top of the print as it travels to the prime tower, depending on its location, causing print defects, and in one case, dislodging the object from the print bed.
Ideally, at least for me, the desired behavior would be to not lower the z height back to print level until after the nozzle has travelled back to the previous XY coordinates.
Activity
[-]Nozzle scraping print returning to print after tool change[/-][+]Nozzle scraping print returning to prior location after tool change[/+]3DPrintDemon commentedon Aug 22, 2026
@hatchna here try my macros! They negate exactly what you're concerned about in the above issue. They raise as per normal, travel to the tool to make the change, then return to the prime tower (set slicer to change on wipe tower) & then lower back down - completely missing the top of your print as it travels.
Note: you will need at minimum my indx.cfg & indx-tc-macros.cfg files. They have been designed to be used with my dock sensors & other files in my fork, but they can also be used without them if you just have those two files.
If you & Bondtech like them I can put in a PR for this arrangement, &/or I am happy to work with the team if any improvements can be made to them. Let me know how it goes!
https://github.com/3DPrintDemon/DEMON_INDX/tree/main/macros
Surion79 commentedon Aug 24, 2026
It would be nicer to create a pr to fix it for everyone instead if propagating macros in other repositories.
3DPrintDemon commentedon Aug 24, 2026
They’re “propagated” in my repo so I can write & test function, then create PR’s, & also offer them as is to users who want to use my connected systems like the dock sensors. This is what forks are how they work. The link was provided for the OP for them to evaluate & test them out & to see if it was a solution to their problem or not. Then to let me know.
Don’t worry. I am also, as I clearly mentioned above more than happy to create a PR for this if folks want it & it works for them, the PR will be opened alongside my other currently open PR’s from my same “propagated” macros.☺️ 👍
hatchna commentedon Aug 24, 2026
@3DPrintDemon, the change in tool change process with your macros solved my problem perfectly. I don’t have any scraping of the print on tool change anymore.
3DPrintDemon commentedon Aug 24, 2026
Thats fantastic news! I'll collect all the relevant parts of the files together to create a PR for Bondtech to look over & consider. Thanks for letting me know, I really appreciate it!
I'm so glad it helped you & hopefully soon you can jump back to the main Bondtech macros with the same functionality as you found on my fork.
hatchna commentedon Aug 27, 2026
So I feel a bit like an idiot, but I found that the reason that I was having issues with nozzle scraping is because the sparse prime tower setting got enabled in my slicer by mistake. I didn't notice it because there weren't many sparse layers in the print, but there were enough that it was causing scraping against the print. So the original Bondtech macros for tool change positioning do work, but I think I still prefer 3dPrintDemon's approach with the extra Z clearance.
ogland commentedon Sep 9, 2026
Closing this on your own follow-up, and thanks for coming back to correct the record rather than leaving it hanging. That is genuinely useful and nothing to feel like an idiot about; sparse prime tower layers causing this is not obvious at all, and the next person to search for nozzle scraping will find your answer.
For anyone landing here later: the symptom was the nozzle dragging over the print on the way back from a toolchange, and the cause was sparse prime tower being enabled in the slicer, not the toolchange macros. The stock macros drop Z only after the Y clearance move.
@3DPrintDemon's #51 came out of this thread and is still open on its own merits, so the toolchange exit options are still being looked at.