OrcaCubic on FreeBSD: Local Printing Without the Vendor Slicer

When I wrote about the Anycubic Kobra X a few months ago, the conclusion was somewhat mixed. The hardware was very impressive for a low cost printer, assembly was straightforward and the integrated multi-material system opened up quite a few possibilities. Unfortunately, the software surrounding the printer made using that hardware outside the manufacturers intended environment considerably less convenient than it should have been. The problem was not that I wanted to use their cloud service from another operating system but the opposite. The cloud is something I would not have missed at all (though I get some beginners may prefer it). What was missing was a usable, transparent way to communicate with a printer sitting in my own network. LAN mode existed, but its protocol was undocumented and the practical route to using it led through the manufacturers application, a fork of the famous Orca slicer

💡 TL;DR: The availability of open software and protocol information changes my view about this printer. Now I can only totally recommend it. Solid hardware, open software interface; still good manufacturer supplied software for all users who like it. Solid product. Very good documentation. Amazing Wiki.

As described in my article about using FreeBSD on all of my machines, FreeBSD remains the most stable and consistent environment from my point of view. Replacing that environment or keeping another operating system around just to send a file to a printer was not a particularly attractive solution. Fortunately, the situation has changed. Source is now available for Anycubic Slicer Next, the community project OrcaCubic brings Kobra X integration into an OrcaSlicer based workflow, and I have put together a native FreeBSD port. Along the way, an unnecessarily troublesome OpenCV dependency was removed as well. The complete port and patches are available on GitHub (OrcaCubicFreeBSD).

• The Missing Part Was Not the Slicer
• From Anycubic Slicer Next Back to Orca
• Porting the Application Instead of Replacing the Operating System
• Why OpenCV Had to Go
  • A Short Rant About Dependency Contracts
• Packaging It as a Normal FreeBSD Port
• Installing and Running OrcaCubic
  • Connecting to the Kobra X
• Current Status and Limitations
• Conclusion
• References

The Missing Part Was Not the Slicer

The original problem was easy to underestimate because a printer profile and a working slicing engine can make the machine appear supported even when its integration is incomplete. The profile describes how a model should be translated into instructions suitable for the printer; sending those instructions requires another layer for device discovery, connection information, authentication, job upload and commands. Status reporting and material selection also have to be integrated. In the first article, I inspected network traffic and instrumented the manufacturers application, which revealed MQTT and HTTP communication.

This is why an undocumented LAN mode is only part of a solution. The connection may remain local, but the user is still dependent on a particular application to make use of it. I do not think a manufacturer needs to provide a polished application for every operating system in existence. What I do expect is that the interfaces required to operate purchased hardware are available. A convenient vendor application can then be offered on top of those interfaces, rather than becoming a prerequisite for using the device. Such software should never be mandatory.

From Anycubic Slicer Next Back to Orca

The relevant source repository is AnycubicSlicerNext. Anycubic Slicer Next is based on OrcaSlicer, and its most interesting additions for this purpose are the printer-specific profiles and integration: multicast discovery, token generation and MQTT communication. These are the pieces which had made local operation unnecessarily opaque before. With the source available, the implementation can be inspected and adapted instead of reconstructing its behavior from outside the application. This concerns the slicer and printer integration. The cloud is uninteresting.

OrcaCubic, maintained by marcodiniz, takes the useful route of adding Kobra X integration to an OrcaSlicer fork. It also credits the LAN protocol work from KX-Bridge. This is not the same thing as having the changes merged into stock OrcaSlicer, but it provides a community-maintained application rather than requiring Anycubics vendor-specific fork. For my setup, retaining a general-purpose slicer matters. There is no good reason why adding one manufacturer’s printer should require abandoning support for machines from other manufacturers. OrcaCubic adds local job upload and print control, material-to-slot matching, filament synchronization, and a local device dashboard. The application is therefore addressing the integration layer, not supplying another collection of slicing presets. Its Anycubic cloud connection is not currently implemented; the workflow discussed here is local. That is exactly the direction I wanted to go.

Porting the Application Instead of Replacing the Operating System

With the relevant code available, the next step was to make it build on FreeBSD. As usual, much of this work consisted of cleaning up platform assumptions and conditional compilation. Code which is already close to portable can still be made unnecessarily platform-specific by the way its #ifdef branches are built. There is an important distinction between code which requires a Linux-specific interface and code which happens to have been written and tested on Linux. The latter should not automatically be hidden behind a Linux-only platform check. Conversely, an #else branch should not silently assume that every system which is not Windows must behave exactly like Linux. The aim is not simply to add __FreeBSD__ to every condition until the compiler stops complaining. Each condition needs to describe the actual requirement. Shared code should remain shared, and genuinely operating-system-specific behavior should be isolated where it is needed.

This is the sort of portability work I would much rather do than maintain a separate operating system just for one desktop application. It fixes the application at the boundary where the assumption was made, instead of restructuring the rest of the workstation around it. The resulting changes are carried as patches in the port’s files/ directory. There is no need to copy a separately modified OrcaCubic source tree around together with the build instructions.

Why OpenCV Had to Go

The more annoying obstacle was the dependency tree. OpenCV has repeatedly been a source of dependency trouble in my setups (dont get me wrong, it is an amazing library), and in this case satisfying the requested combination of versions would have required removing a large part of my existing application set. That was not an acceptable trade-off just to install the slicer, so I looked at what OpenCV was actually doing before trying to reconcile the entire dependency graph. For the paths relevant to this port, it was mainly loading images and processing their colors to map them onto available filament colors. Those are useful features, but they do not automatically justify pulling in a large computer-vision framework.

There is a considerable difference between an application built around a broad collection of computer-vision algorithms and an application which needs to decode an image and perform a bounded amount of color processing. A dependency which is reasonable for the former may be a poor fit for the latter. The solution was therefore to remove OpenCV from the patched build rather than trying to make the rest of the workstation accommodate it. The replacement uses libpng and libjpeg for PNG/JPEG textures and wxWidgets existing image handlers for other supported formats. OpenCV is no longer built or directly required. OpenCascade still pulls in FreeImage indirectly on FreeBSD, so this does not remove every imaging library from the dependency tree - I may tackle this later. These details are documented in the port README.

The point is not to eliminate every library or pretend that a modern slicer is a tiny application. It is to make the dependencies proportionate to the functionality being used. Image decoding is still delegated to established libraries; an unnecessary additional framework does not have to sit between those libraries and the application.

A Short Rant About Dependency Contracts

In my opinion, this is something application and library developers should take much more seriously. Applications should specify the minimum dependency versions which provide the interfaces they actually require. Libraries should maintain stable API and ABI contracts within their promised compatibility range. A particular developers build environment should not become the only environment in which an application is allowed to exist. Of course, changing an exact-version requirement into >= does not magically make incompatible releases compatible. That is why interface stability and sensible dependency declarations belong together. Arbitrary pinning should not be used as a substitute for maintaining a usable interface contract. A dependency is not free merely because adding its name to a build file is easy. Every dependency also becomes somebody elses installation problem, update problem, and potential conflict with software which is already installed. In this case, reducing the dependency was more useful than adding another workaround around it.

Packaging It as a Normal FreeBSD Port

The result is a FreeBSD Ports-compatible directory rather than a collection of commands which only work inside my development checkout. Its layout contains the usual Makefile, distinfo, pkg-descr, and files/ directory. The port fetches the selected upstream source, applies the local patches, and builds the application. At the time of writing, the Makefile selects OrcaCubic commit:

822ae314016642d0ed2a362d38ebf15f03852300

Pinning the application source is intentional. The patch set needs a defined input; it should not silently be applied to whatever happens to be at the tip of an upstream branch tomorrow. That is a different issue from unnecessarily demanding one exact version of every external library. The port also gives OrcaCubic its own installation location and launcher, rather than replacing an existing OrcaSlicer installation.

Installing and Running OrcaCubic

An existing FreeBSD Ports tree is assumed. With Git installed, the repository can be placed directly into the local print category. As root, and provided the destination does not already contain another checkout:

git clone https://github.com/tspspi/OrcaCubicFreeBSD.git \
    /usr/ports/print/orcacubic

cd /usr/ports/print/orcacubic
make install

Alternatively, copy the complete repository directory to /usr/ports/print/orcacubic and run the same make install command. The normal Ports framework handles the build and missing dependencies. This is still a substantial application even without OpenCV. If necessary, build parallelism can be limited:

make MAKE_JOBS_NUMBER=4 install

After installation, the application should be launched as the normal desktop user. I recommend giving it a separate configuration directory from the beginning:

orcacubic --datadir "$HOME/.OrcaCubic"

The installed command is orcacubic, not a replacement for orca-slicer. With the default installation prefix, the application and resources reside below /usr/local/libexec/OrcaCubic. There is also a deliberate safeguard in the launcher: without an explicit --datadir, it uses ~/.OrcaSlicer, but refuses to start when that directory already contains OrcaSlicer.conf. This prevents silently opening an existing OrcaSlicer configuration with the fork. Supplying a dedicated directory makes the separation explicit.

Connecting to the Kobra X

Enable the printers LAN mode and make it reachable from the workstation on the local network. In OrcaCubic, select the Anycubic Kobra X profile, then open Printer settings → Physical printer. Select Anycubic as the host type, enter the printer’s local IP address, and use Test to check the connection. After slicing, select Print and review the material-to-slot assignments before starting the job. The upstream setup instructions describe this workflow. The aim remains communication between the workstation and the printer without requiring a vendor cloud service in the middle.

Current Status and Limitations

The snapshot has been built and run on FreeBSD 13.5/amd64, with package creation checked. Model import has been exercised and LAN upload and print start were tested with pre-engage disabled. The Kobra X camera stream is currently not working. This remains an unofficial local port, not an accepted FreeBSD Ports entry. A successful build is of course not a completed validation and features available in an upstream application are not automatically verified on every platform. Initial printer tests should therefore be supervised.

Conclusion

The most useful change since the first Kobra X article is that the integration can now be studied and adapted from source. Anycubic has published slicer source, OrcaCubic provides a community implementation of the local integration and the FreeBSD-specific work can be distributed as a normal port. The OpenCV removal also shows why access to source matters beyond the ability to inspect a protocol: a dependency that fits poorly on another workstation can actually be replaced.

This is how I would like hardware support to work. A manufacturer can provide a convenient default application while allowing other people to support additional operating systems, integrate the device into different workflows and fix problems which the manufacturer may never encounter in its own test environment. There is still work to do here, particularly validating the complete printing workflow and adding camera support, but that work can now happen in the environment where the printer is actually supposed to be used. The printer should fit into the workstations workflow, the workstation should not have to be rebuilt around the printer.

References

• The Anycubic Kobra X
• Anycubic Kobra X - First Impressions
• Why I Prefer FreeBSD on All of My Machines
• Anycubic Slicer Next on GitHub
• OrcaCubic
• OrcaCubicFreeBSD - port and patches
• FreeBSD Handbook - Packages and Ports

This article is tagged:

• FreeBSD
• System administration
• Administration
• 3D printing