Two failures. One evening. Both lied.

First, a validation error with values that were clearly fine. Then, a send-to-printer command that disappeared into silence. No confirmation. No error. Nothing.

The mission: determine what actually broke. Not what the dialog box claimed broke. Not what the forum said probably broke. What actually broke, isolated layer by layer, with evidence.

I print miniatures. I run a Bambu A1 with a 0.2mm nozzle and community profiles for tabletop minis. Orca Slicer is my tool of choice because it gives me more control than Bambu Studio. That control comes with a cost: when things fail, you’re on your own.

Last week I hit two separate failures in the same evening. Both were solved not by googling the error or rolling back versions, but by applying the same method I use at work: read the logs, isolate the layer, eliminate suspects one by one.

This article is about that method. The 3D printing is just the scenario.

Act 1: The Error That Lied

I loaded a community miniature profile (Dungeons and Derps 2.0, optimized for 0.2mm detail work) and hit slice. Orca threw this:

Organic support tree tip diameter must not be smaller than support material extrusion width

Fine. I read the values. Tip diameter: 1.2mm. Extrusion width: 0.2mm. A tip six times wider than the extrusion. The error was claiming 1.2 < 0.2. That is not how numbers work.

Step 1: distrust the UI, read the source.

The profile lives as a JSON file. I opened it with grep instead of clicking through dialogs:

grep -r "line_width" ~/Library/Application\ Support/OrcaSlicer/user/

There it was. All eight line width fields were set as percentages: "150%", "120%", and so on. The dialog displayed them as computed mm values, which looked fine. But the validation logic was doing something else with the raw percentage strings.

Step 2: confirm by moving the error.

I converted one field to absolute mm. The error moved to the next percentage field. Classic whack-a-mole: you push on one spot and the shape reappears next door. That is a confirmation, not a new problem. It means the diagnosis is correct.

Fix: convert all eight line width values from percentage to absolute mm (percentage x nozzle diameter). Reslice. Clean.

Lesson: the error message named the wrong culprit. It pointed at the tip diameter. The actual offender was how the validation reads percentage-based line widths, a known bug (OrcaSlicer issue #5431 ). The JSON was ground truth. The dialog was an interpretation.

Act 2: Send to Printer, Nothing Happens

Sliced. Hit send. Nothing. No progress bar. No error. No confirmation. Tried LAN mode: same silence. Tried cloud mode: same silence. Just the button, and then the quiet.

This is the worst-case UX pattern: a failure that produces no signal. No signal means you cannot start reasoning. Your first move has to be to create signal.

Step 1: read the logs.

tail -f ~/Library/Application\ Support/OrcaSlicer/log/orcaslicer.log

Signal acquired:

print_job: failed, result = -26
LAN connection verification failed: ftp_ok=false

ftp_ok=false. The slicer is trying to connect to the printer over FTPS (port 990) and failing. Now I have a direction.

Step 2: isolate the layer.

I opened Bambu Studio. Same machine. Same network. Same printer. Same firmware. Send to printer: worked immediately.

This eliminates four suspects at once: the printer, the network, the firmware, and the credentials. If Bambu Studio can reach the printer, none of those are the problem. The suspect list now contains exactly one item: something specific to Orca Slicer.

Step 3: eliminate the plugin.

Orca uses a network plugin (a .dylib bundle on macOS) to handle printer communication. I moved it out of the application bundle and relaunched. Orca re-downloaded the plugin, same version. Same failure.

Plugin state: innocent. The issue is not a corrupt or stale dylib.

Step 4: prove it with raw protocol.

If the FTPS layer is fine and the printer is fine, the bug is in how Orca drives the connection. I verified with two commands:

# Is the port open?
nc -z PRINTER_IP 990

# Can I authenticate and list files?
curl --ftp-ssl --user bblp:ACCESS_CODE ftps://PRINTER_IP:990/

The nc confirmed port 990 is open. The curl listed the printer’s internal storage. The same access code stored in Orca’s config file. The same IP. Working.

Verdict: the FTPS protocol works. The printer accepts connections. Orca 2.4.1’s network plugin on macOS has a bug in how it initiates that connection (OrcaSlicer issue #12563 ).

Workaround: since curl can reach the printer directly, I do not need Orca to send the file. I slice in Orca, export as plate .3mf, then upload with a shell script:

#!/usr/bin/env bash
# send-to-a1.sh: upload a plate 3mf to the Bambu A1 over FTPS
FILE="${1:?usage: send-to-a1.sh <file.3mf>}"
PRINTER_IP="192.168.68.XXX"  # replace with your printer's IP
ACCESS_CODE="XXXXXXXX"       # replace with the access code shown on the printer screen

curl --ftp-ssl \
  --user "bblp:${ACCESS_CODE}" \
  -T "${FILE}" \
  "ftps://${PRINTER_IP}:990/cache/$(basename ${FILE})"

echo "Uploaded. Start the print from the printer screen."

Slice in Orca. Export. Run send-to-a1.sh plate_1.3mf. Start from the screen. Takes ten seconds.

The Method, Extracted

These were two unrelated failures. The debugging approach was identical both times.

  • Error messages are claims, not facts. They reflect what the code author thought was wrong at the time of writing. Logs and raw protocols are facts.
  • Binary search over the stack. App / plugin / network / credentials / device. Each test should eliminate exactly one layer. When something works, that layer is innocent.
  • A second client is a free control group. Bambu Studio existing on the same machine turned a 30-minute network investigation into a 30-second elimination.
  • When the GUI path is broken, the protocol underneath is often fine. curl is the universal last resort. If you know what protocol the app speaks, you can speak it yourself.
  • File the evidence upstream. A log line plus a working curl repro is the highest-value bug report you can write. Maintainers can reproduce it in minutes.

Mission complete. The printer was innocent the whole time. The slicer confessed under interrogation. Next objective: the same method applies everywhere. Read the logs. Isolate the layer. Trust the protocol, not the dialog.