<p><em>TLDR - I’ve just driven myself insane trying to fix what I thought was a physical problem with my Z-axis, but it seems to have been solved by switching from the TH3D firmware to the Creality firmware. I’m hoping someone can help me see where I went wrong here, so I can learn from it. Have I missed something obvious?</em></p>
<p>My printer is a Creality Ender 3 Pro. I have a BLTouch. I recently upgraded to the silent 4.2.7 board and compiled my own firmware using TH3D Unified 2 using their instructions. <a href="https://pastebin.com/MYs8sYGj" rel="nofollow noreferrer">This is my <code>configuration.h</code></a>.</p>
<p>This “worked”, but after that upgrade, I had severe print problems. (See the photos below) These are supposed to be 20x20x20 calibration cubes (the big one is 200%). They are significantly taller than they should be. It may be hard to see in the photo, but this is because the Z spacing on the bottom layers seems to be too high. But, at the same point on each print (even the bigger one), the problem seems to just stop - and layer spacing is correct again for the end of the print.</p>
<p><a href="https://i.stack.imgur.com/BGayd.jpg" rel="nofollow noreferrer" title="Comparison of multiple calibration cubes"><img src="https://i.stack.imgur.com/BGayd.jpg" alt="Comparison of multiple calibration cubes" title="Comparison of multiple calibration cubes" /></a></p>
<p>I tried everything to figure out what this was and I was convinced it was a physical problem with my Z-axis. I read lots of questions on here but nothing quite on topic. I printed on different parts of the bed and got the same result. I re-calibrated my Z steps, but these turned out to be pretty much at the firmware default anyway. I tightened every bolt and eccentric nut I could find that related to the X-axis gantry, but nothing made any difference. Same problem, every time.</p>
<p>Out of desperation, I eventually switched to the official Creality firmware for the Ender 3 Pro 4.2.7 board with BLTouch - and the problem was fixed:</p>
<p><a href="https://i.stack.imgur.com/7tXcf.jpg" rel="nofollow noreferrer" title="Printed calibration cube after firmware change"><img src="https://i.stack.imgur.com/7tXcf.jpg" alt="Printed calibration cube after firmware change" title="Printed calibration cube after firmware change" /></a></p>
<p>Does anyone have any ideas about what caused this? Have I overlooked something obvious? I’d ideally like to go back to the TH3D firmware but it’s seemingly not an option.</p>
<p><a href="https://pastebin.com/MYs8sYGj" rel="nofollow noreferrer">https://pastebin.com/MYs8sYGj</a></p>

[{'answer_id': 16785, 'author': 'IceCreamToast', 'author_id': 29332, 'author_profile': 'https://3dprinting.stackexchange.com/users/29332', 'pm_score': 2, 'selected': False, 'text': '<p><strong>Long story short:</strong> I only know the setting &quot;Combing Mode OFF&quot; that improves the travel paths. In my case it did not help. In your case I suggest you should give PrusaSlicer a try. I assume that the overall print duration will be improved because of a better calculation of the travel paths. But this is only my personal opinion between these two Slicers.</p>\n<p><strong>Further explanation:</strong> I downloaded the Cura 4.9 and made an install from scratch. I tried to reproduce your issue by placing lots of copies of the same part. As printer I selected the Ultimaker S5 and used the standard configuration for slicing. I let Cura arrange the parts on the print plate.\nI checked the travel paths between the parts and in most cases Cura has chosen the nearest distance to move the printhead to the next part. In my opinion, there could be a more efficient choice for the next part to print.\nAfter this first test I experimented with the settings (e.g. &quot;Combing Mode&quot; OFF) but without an improvement in travel movements.</p>\n<p>In the past I used Cura in combination with an Ultimaker S5 at work to print parts for production usecases. Over the past two years I recognized lots of parts where the travel movements have been chosen very unefficiently at the cost of high print duration.</p>\n<p>For comparison I used my standard slicer &quot;PrusaSlicer&quot; and did the test under the same conditions: standard settings, auto-arrangement of the parts.\nOverall the travel paths are calculated more efficiently, but there is also some room for improvement.</p>\n'}, {'answer_id': 16786, 'author': 'Zeiss Ikon', 'author_id': 28508, 'author_profile': 'https://3dprinting.stackexchange.com/users/28508', 'pm_score': 3, 'selected': False, 'text': "<p>It's well known in mathematical circles that the &quot;salesman problem&quot; is what mathematicians call &quot;hard&quot; -- in their usage, that means a lot of extremely smart people have worked on the problem for many years (more than a century?) and still not found a robust, works-every-time solution.</p>\n<p>What's probably happening with Cura and other slicers is that, for their version of this issue (the most efficient way to visit multiple locations) the decision was made that reducing computing time in slicing was more practical than optimizing travel time of the machine.  This is a reasonable decision, from a programming standpoint, because you're likely to be sitting in front of a screen, getting more and more impatient (and thinking less and less of the software you're using) every second the slicing takes, but when the actual printing is going on, you can be doing something else (sleeping, working at your day job, etc.)</p>\n<p>Therefor, it's likely that what you see in Cura <em>is</em> optimized -- to minimize <em>your</em> time on the way to a solution, rather than to minimize the time for a machine that simply doesn't care if a print takes five hours or nine.</p>\n"}]
['https://3dprinting.stackexchange.com/questions/16793', 'https://3dprinting.stackexchange.com', 'https://3dprinting.stackexchange.com/users/29463/']