“So… no Orca Slicer, yet?”
Added 2025-06-04 17:42:03 +0000 UTC"Why haven’t you released Orca yet?! You said April..."
You’re absolutely right to ask. I originally aimed to have it out by the end of April - and here we are in June. So... what happened?
Simply put? SWMC became too powerful for its own good.
From the very beginning of this project, I’ve been battling file size limits. The full SWMC experience--packed with all it's features--just wouldn’t fit into a single file.
Over the past month, I’ve been deep in optimization, hovering between 39kb and 40kb files, rewriting, refining, and testing every line. And I wasn’t about to start cutting corners or compromising on the features that make SteinWipe Motion Control what it is.
The solution? MOAR VARIABLES - It's the reason why Orca has so much more SWMC ability over BBS.
The Gcode in Orca and Bambu does not have the ability to 'jump-to' or 'loop' which could save a ton of code, but we can call values up over and over if we set them once beforehand. An example of this in the code below - without using variables all of this code had to be repeated several times throughout, but new code will set the result to a single variable saving us hundreds of lines of repeating code WITHOUT any sacrifice allowing more room for new activities.

I’ve implemented yet another new user-friendly addition to SWMC - a system of centralized variables for everything users might want to tweak to make the system truly their own. This change makes the code cleaner, lighter, and far more customizable.
It’s always been part of the long-term plan, but let’s be honest… what better time than now?
Especially while we wait for Orca to catch up with BBL’s new Authorization Control.
If Orca users are like me and don’t want to have to be condemned to LAN mode and grainy laggy camera feeds without the Handy app as the only way forward. So lets hope🤞
A long list of user definable variables will now be listed right at the top of the file, so you can easily tweak positions, timings, and more without digging through the whole codebase. Here is what it will look like.
This update is a huge step forward—not just for getting SWMC to fit inside Orca, but for making the entire project more modular, sustainable, and customizable.
Thank you so much for your patience and continued support! Sales of the Dev pack have dropped but many of you have converted to monthly supporters and thank you so much for this 🙏 You’re the reason this project keeps leveling up. Orca support is coming soon—and I promise, it’ll be worth the wait.
– Leckiestein
Comments
This is reassuring! When it comes down to it- in most situations I think Id give up bambu printers before Orca or Simplify 3D if I had to make a choice. Only people who produce 1000s of print files every month understand. The entire farm at work runs on Orca and I cant imagine using BBS for that task. Just so much custom code that took months and months to dev for specific products that we print which cant run on BBS.
Christopher
2025-06-04 20:41:54 +0000 UTCA few things! I want to keep the process as simple as possible for general use. Right now, it's pretty straightforward: open the .3mf file and you can start printing right away—no need to change anything if you don’t want to. I’d say about half of users stop there, and that’s totally fine. For those who want more customization, it’s just as easy to add SteinSwitch definitions in the printer notes. No need to edit raw G-code-this was designed to be accessible, even for beginners. The current Apr.28.1 build for Bambu Studio is right at the 40kb threshold, which means it still saves to your BBL account without any issues. Now, about Orca: some of the newer features I’m rolling out require more space, and Orca is the only place I can push them for now. That’s because BBS is more limited in terms of feature support and gcode engines. I could take two routes here: Say “tough luck” and make users save their print profiles as .3mf files and open them every time they want to start a new project on a different computer (no account sync). Most people have a desktop and laptop so this will happen often especially if you tweak things as often as I do. Or... maintain compatibility with the Bambu Studio cloud so users can still sync and access their configs from anywhere. Since I personally work from three different locations, the ability to simply refresh the slicer and keep everything synced is too valuable to give up—and I think many users would agree if they had the feature taken away. As for expansion: yes, Python scripting is likely where the project will head long-term. It opens up much more flexibility and doesn’t have the same space constraints. That said, I don’t want to spend a full year building a single integration layer. There are tons of things we can already do with Python, and once V2 drops, I’ll be working toward a fully featured script that does everything in one place. The main downside with Python scripting is it tends to scramble the G-code feed in the viewer window in BBS and Orca. It’s not a printing issue, just a UX one—it makes it hard to scroll and understand the G-code visually. If its a BBS and Orca-specific issue then likely the same in PrusaSlicer as well.
Christopher
2025-06-04 20:29:54 +0000 UTClooking at https://github.com/SoftFever/OrcaSlicer/pull/9517 it at least seems promising to have Orca update "soon"
Jan Weißsieker
2025-06-04 20:07:39 +0000 UTCThank you for the update, I'm also waiting for Orca support. Out of interest as a software engineer, I didn't catch the reason why exactly why is Orca not supported? Or is 40k limit you mentioned only applicable to Orca and not the Bambu slicer (this would make sense then)? Have you ever thought about upstreaming some changes to Orca as new integrated options, which would perhaps make your life easier?
Bo
2025-06-04 19:49:49 +0000 UTC