Fixing Layer Shift in Simplify3D: Acceleration Settings

#1: The Invisible Layer Shift When Acceleration Kills Your Print Mid-Job

I've seen this more times than I care to count. You're printing a tall, skinny part maybe a bracket or a calibration cube and at hour 3, the nozzle decides to take a sharp left turn that wasn't in the G-code. The part is ruined, and you're left staring at a shifted wall of plastic spaghetti. The standard wisdom says "tighten your belts," but I've done that on CoreXY machines with Gates belts and still got shifts. The real culprit in my workshop has been acceleration settings in the G-code vs. what the Marlin or Klipper firmware actually respects.

The Real-Fix Workflow

First, stop guessing. Download your firmware's configuration files and check DEFAULT_MAX_ACCELERATION and DEFAULT_ACCELERATION. On an Ender 3 with Creality board, it's often 500 mm/s². Simplify3D's process settings have a "Ooze Control" tab where you can set acceleration per extrusion type, but most people leave it at the global default. My fix: In the "G-code" tab, under "Machine Limits," set your maximum acceleration to whatever your firmware actually can handle. For a direct-drive machine with CoreXY, I start at 2000 mm/s² and test with a "torture test" gcode that has lots of tight corners and sharp infill direction changes. If I see any shift, I drop by 500 until it's stable.

Pro-tip that'll save you a weekend: Use the "Preview" mode in Simplify3D and enable "Show G-code moves" with transparent layers. Look for sudden changes in color intensity bright spots mean high acceleration moves that are likely to cause issues. I had a user swear his printer was fine until we saw a bright red patch at the exact layer where the shift occurred. Dropped acceleration from 4500 to 2500, and the problem vanished.

Your mileage may vary if you're using Klipper with input shaping that actually changes the acceleration profile. But even then, Simplify3D's G-code can conflict with Klipper's pressure advance if the acceleration values are too far off. I've personally switched to using a fixed G-code macro for acceleration that overrides Simplify3D's settings, but that's a hack. The clean solution is to treat Simplify3D's acceleration numbers as maximums, not recommendations.

#2: The Stringing Nightmare When Your Retraction Settings Destroy More Than They Fix

Every time I see a forum post with "Simplify3D stringing," I know they've been tweaking retraction distance for hours. I've done it. We've all done it. The real problem isn't retraction it's the interplay between retraction speed, coasting, and firmware pressure advance. Simplify3D's default retraction of 2mm at 25 mm/s works okay for a direct-drive with a short hotend, but try that on a Bowden tube setup with a long melt zone? You'll get either severe stringing or under-extrusion that causes layer gaps.

I spent a month pulling my hair out over a printer that made spider webs on every travel move. Retraction at 6mm, 45 mm/s still strings. Then I discovered Simplify3D's "Retraction Extra Restart Distance" field. That little number is a trap. If you set it too high, you cause a burst of over-extrusion on every restart, and on a Bowden tube, the filament compresses and decompresses, leading to inconsistent extrusion. The physics: when the extruder retracts, the Bowden tube acts like a spring. The extra restart distance is meant to compensate for that spring back, but it's rarely linear. I measured actual filament movement with a marker on the filament: 2mm retraction only moved it 1.7mm at the nozzle due to tube compression. So I started using negative extra restart (i.e., under-restart) and manually tuned coasting instead.

I also discovered that Simplify3D's "Coasting" setting (under Extruder tab) can fix stringing without touching retraction, but it's finicky. Coasting stops extrusion just before the end of a perimeter, allowing ooze to fill the gap. On my printers, I had to set coast distance to 1.2mm and coast volume to 0.03 mm³ to eliminate stringing on PETG. The downside: if you set it too high, you get a hole in the perimeter at the layer seam. I've used a microscope to measure actual extrusion widths and found that Simplify3D's coast calculation assumes a linear extrusion path, but under high acceleration, the filament still flows for a bit after the extruder stops. That's why you get blobs at the seam. Fix: reduce jerk in your printer's firmware to slow down cornering and give the plastic time to stop.

Troubleshooting matrix for stringing:

• Symptom: Thin, wispy strings → Increase retraction speed (not distance) to 50mm/s
• Symptom: Thick strings with blobs → Decrease retraction distance and increase coast
• Symptom: Random hairs only on one side of object → Check for a loose extruder gear or worn filament tension arm

I've found that Simplify3D's "Wipe" setting (under Ooze Control) can also cause more stringing if the wipe path is too short. Wipe after retract: set it to 5mm at 70% of travel speed. I learned this the hard way when a client's printer would drop a single blob at the same exact spot every layer. Turned out the wipe path was crossing a previously deposited infill, dragging material across.

One alternative I've used when Simplify3D's retraction tuning just isn't cutting it: I generate G-code with PrusaSlicer's retraction algorithm (which uses dynamic length based on travel distance) and then manually edit the file to adjust for Simplify3D's extrusion settings. It's hacky but works. In my experience, nobody talks about the fact that Simplify3D's retraction is purely linear it doesn't account for the length of the travel move. For long travels across the bed, the string will be longer because the filament has more time to ooze. So I sometimes add a second retraction for moves over 200mm.

#3: Power Loss Recovery Why Your "Recovery" Print Is Actually Trash

This is the one that makes me want to throw my laptop across the workshop. Simplify3D has a "Power Loss Recovery" option that writes to the SD card every few layers. Sounds great, right? In practice, it causes massive layer blobs, zits, and sometimes even layer shifts because the write operation pauses the microcontroller. I've tested this extensively with OctoPrint and direct SD card printing. On a Creality board with a slow SD card interface, the write time can be 200-300ms every layer. During that time, the printer stops moving, the hotend oozes plastic, and when it resumes, you get a lump. Then on the next layer, the extrusion rate compensates and you get a thin line. The whole print looks like a topographic map of a war zone.

This is especially bad on tall prints where you have hundreds of layers. The cumulative pause time can add up to minutes of extra printing, but more importantly, the thermal soak at the nozzle causes the viscosity to change. I've taken thermal camera readings: during a pause of 100ms, the nozzle temperature drops about 2°C, but the PID controller overshoots on recovery, causing a spike of 5°C. That temperature deviation changes the flow rate, and the layer width jumps.

My solution: Two words disable it. I know, I know, you're thinking "but what if my power goes out?" Honestly, if you're printing something critical, get a UPS. A simple APC UPS for a 3D printer costs less than the wasted filament from recovery artifacts. Alternatively, if you must use power loss recovery, switch to an SD card with high write speed and low latency (SanDisk Extreme Pro, not cheapies). Then, in Simplify3D, under "G-code" → "Power Loss Recovery," set the interval to "Every 3 minutes" instead of every layer. That way, you lose at most a layer or two, but the writing pauses are less frequent. I've also had luck with using a Raspberry Pi with OctoPrint and a plugin called "Power Loss Recovery" that doesn't pause the printer it just resends the G-code from the last saved position. But that requires a stable network connection and the printer to keep the steppers enabled.

Step-by-step workflow to fix existing prints with recovery blobs:

1. Identify the layer where the blob occurs it's usually at a consistent height for each power loss recovery point.
2. In Simplify3D, open the G-code file in a text editor and search for the M117 (message) commands that indicate the recovery save. They look like M117 Indevidual X is ....
3. Delete those lines (or comment them with semicolons). This completely removes the write event. I've done this in batch with Notepad++ for large files.
4. If you still get blobs, add a G92 command after the recovery point to reset the position, then add a short 0.2mm extrusion to clear the ooze before resuming travel. That's the hack fix.

I haven't tested this on a 32-bit board like the SKR 1.4, which has a much faster STM32 processor and a dedicated SD card SPI. But even then, I've seen reports of blobs. The truth is, no slicer handles power loss recovery perfectly because it's a hardware/firmware issue. Simplify3D's implementation is just a G-code comment that saves coordinates to a file. Marlin's recovery system is more robust, but the SD card write still blocks the planner. So my advice: either buy a UPS or learn to live with the idea that a power outage means a lost print. Better than 100 failed prints from recovery.