OrcaSlicer, Creality K1 Max, Moonraker, and Mainsail: first steps for new owners finding their feet

The setup

This test was done against a Creality K1 Max on 192.168.2.136 while the printer was actively running a job. The slicer was OrcaSlicer 2.3.2.

This was not a fresh-from-box machine. It had just been bought second-hand from Facebook Marketplace, so part of the job was simply working out how the printer had already been set up, what services were running, and what needed cleaning up before it could be trusted as a daily machine.

This article is aimed at the kind of user who is not completely new to 3D printing, but is new enough to a machine like the K1 Max that they are still finding their feet. In other words: some experience, a few upgrades behind you, but still building confidence with a faster and more automated printer.

The path ended up being fairly straightforward:

buy a used K1 Max
hit early bed adhesion issues
get annoyed with Creality Print doing more than necessary
move to OrcaSlicer for more control
fix Moonraker, Mainsail, and webcam access so the workflow actually feels usable

What happened first

The first task was not slicer setup at all. It was simply trying to get reliable first layers.

The first material used here was white eSUN generic PLA. On this machine, the smooth plate seemed to give slightly better adhesion without glue than the textured option. Bed adhesion on the textured PEI plate was not great in these early tests, also without glue.

That does not mean the textured plate is bad, only that it was not the better starting point on this specific used machine with this specific PLA.

At the moment the bed still appears to be about 0.8 mm out of level overall. Smaller prints have been usable, but larger prints are still the real test. That issue may show up more clearly as the print area increases, so this should be treated as an honest in-progress baseline rather than a final tuning result.

Why move away from Creality Print

Another early frustration was Creality Print. It seemed to want to calibrate before every print, which added time and did not feel necessary for every job.

For a new owner trying to learn the machine, that kind of forced workflow gets old quickly. It is hard to know what actually matters when the software insists on repeating the same steps every time and gives limited flexibility about when to probe, when to trust the saved mesh, and when to simply print.

That was the point where moving to OrcaSlicer made more sense.

The first OrcaSlicer symptom

The stock OrcaSlicer printer connection would not behave correctly when pointed at the printer as if it were an OctoPrint target. Orca’s log showed repeated requests to:

http://192.168.2.136/api/version

Those requests returned 404 Not Found, which is expected on a Moonraker-based setup because that endpoint is not the right API.

What actually worked

Changing the printer host in OrcaSlicer to Moonraker fixed model upload:

http://192.168.2.136:7125

After switching to Moonraker, we verified the API directly. The printer reported:

Moonraker reachable on :7125
klippy_state: ready
active print state visible through Moonraker

That confirmed the upload path was correct.

Why the Device page still looked broken

After the upload fix, OrcaSlicer opened the Device page and showed the plain Moonraker landing page:

Welcome to Moonraker
You may have intended to navigate to one of Moonraker's front ends.

This is the key point: :7125 is the Moonraker API, not the web frontend.

We tested the likely frontend ports on the printer:

http://192.168.2.136:4408 returned 404
http://192.168.2.136:4409 returned 200 with the title Mainsail

So the correct split was:

Orca upload/control host: http://192.168.2.136:7125
Orca Device page web UI: http://192.168.2.136:4409

The fix inside OrcaSlicer

The Orca machine preset only had print_host set, so Orca fell back to opening the Moonraker API in the Device tab.

The saved preset looked like this before the fix:

{
  "print_host": "http://192.168.2.136:7125"
}

The working version needs a separate web UI host:

{
  "print_host": "http://192.168.2.136:7125",
  "print_host_webui": "http://192.168.2.136:4409"
}

On this system, that setting lived in:

%APPDATA%\OrcaSlicer\user\default\machine\Creality K1 Max (0.4 nozzle) - Copy.json

After adding print_host_webui, the expected next step is to fully restart OrcaSlicer so the Device page reopens against Mainsail instead of raw Moonraker.

Fixing webcam monitoring

At first, Moonraker was healthy, but the camera list was empty:

{"result":{"webcams":[]}}

That meant print status could work through Moonraker, but embedded camera monitoring would stay blank until a webcam was configured in Moonraker.

The printer was already running mjpg_streamer on port 8080, so the missing piece was the Moonraker webcam stanza. The working section added to moonraker.conf was:

[webcam Camera]
location: printer
enabled: True
service: mjpegstreamer
target_fps: 15
target_fps_idle: 5
stream_url: http://192.168.2.136:8080/?action=stream
snapshot_url: http://192.168.2.136:8080/?action=snapshot
flip_horizontal: False
flip_vertical: False
rotation: 0
aspect_ratio: 4:3

After restarting Moonraker, the camera was advertised correctly and the snapshot endpoint responded with 200 OK and image/jpeg.

In practice, this means:

Uploading jobs can work through Moonraker on :7125.
The Device page can load correctly through Mainsail on :4409.
The camera feed can appear once Moonraker advertises the webcam.

Practical takeaway

If you are using a rooted Creality K1 Max with Moonraker and Mainsail, do not point every OrcaSlicer field at the same URL.

Use the API and the frontend separately:

print_host -> Moonraker on :7125
print_host_webui -> Mainsail on :4409

If OrcaSlicer shows the Moonraker welcome page in Device, the problem is probably not Moonraker itself. It usually means Orca is opening the API port instead of the frontend port.

If the Device page loads but the camera is still missing, check Moonraker’s webcam list before blaming OrcaSlicer:

http://PRINTER_IP:7125/server/webcams/list

If that list is empty, the webcam has not been configured yet.

Why the Orca workflow feels better

The biggest improvement was not one single magic setting. It was that OrcaSlicer plus Moonraker plus Mainsail gave a more understandable workflow.

Instead of fighting a slicer that wanted to do everything for every print, the setup could be split up properly:

upload through Moonraker
monitor through Mainsail
use the camera once Moonraker advertises it
run full leveling only when it is actually needed

That makes the machine feel much more predictable, especially for someone who is still learning a recently purchased used printer.

That also makes the current baseline for future troubleshooting:

printer: used Creality K1 Max from Facebook Marketplace
filament: white eSUN generic PLA
plate: smooth plate
adhesive: no glue
textured PEI result: weaker early adhesion than the smooth plate
Creality Print behavior: seemed to level every print and waste time
current slicer direction: OrcaSlicer feels more flexible and more usable
current bed state: roughly 0.8 mm out of level

Verified findings from this session

Printer IP: 192.168.2.136
OrcaSlicer version: 2.3.2
Moonraker API reachable: yes
Moonraker version: v0.10.0-19-g1ed102e
Klipper state: ready
Mainsail frontend reachable: yes, on :4409
Alternate frontend port :4408: not present on this printer
Moonraker webcam list: now returns one configured camera
Camera snapshot endpoint on :8080: reachable