OrcaSlicer Nightly Builds for Snapmaker Community - Dev Version

[Jade]

Hello Makers,

We’ve brought you a Summer Surprise: a special edition of OrcaSlicer Nightly Build, specifically tailored for our dedicated community.

What’s New?

Orca Slicer is a popular and powerful open-source slicer in 3D printing community. Special thanks to community contributors, especially macdylan (Dylan) and hliebscher (Heiko Liebscher) for adding initial profiles for Snapmaker machines. We can select Snapmaker machines directly from Orca Slicer’s default Printer list. As more Snapmaker users adopt Orca Slicer, we’ve listened to community feedback and identified some pain points. So we are developing a special edition that incorporates the latest improvements for our users.

In the past, some of our machine’s cool features - like independent dual extrusion - weren’t fully compatible with the Orca Slicer. But that’s changing! The recent dev branch of Orca Slicer has added support for multiple extruders/toolheads. For example, the Prusa XL 5T support has been added!

We’ve adapted this feature and rolled out a special edition tailored for Snapmaker machines. These new settings deliver higher efficiency in extruders switching, minimizing downtime and maximizing print quality.

Development Version

New Features

• Seamless Extruder Switching: Say goodbye to long waits! With our special edition, the inactive extruder now preheats while on standby and begins printing as soon as the active one finishes. This feature is optimized for Snapmaker Artisan, J1/J1s, and Snapmaker 2.0 with Dual Extrusion 3D Printing Module.

You can view and fine-tune the Temperature variation and Preheat time settings for this feature in Process - Multimaterial - Ooze prevention.

Improvements

• Optimized Material Profiles: Default profiles for PLA, PETG, TPU, ABS, and PVA have been fine-tuned for all Snapmaker models.

• Streamlined G-code: The default Machine Start G-code routines for Snapmaker 2.0 and Artisan have been streamlined for better performance.

• Enhanced Speed and Support Settings: These adjustments reduce missed steps, minimize layer shifts, and make print removal easier for Artisan and J1/J1s.

Known Issues

• You would get a large Prime Tower for multimaterial printing. In the Multimaterial setting, the default Multiplier value for Flushing volumes is excessively large, leading to material waste and increased time consumption.

What is a Nightly Build?

Introduction

Nightly builds are the latest versions of Orca Slicer, automatically compiled after every new commit to the main branch. This means that each build incorporates the most recent changes and improvements. While these builds offer a glimpse into the ongoing development of OrcaSlicer, keep in mind that they are still works in progress and may contain bugs or unstable features.

Warning

• OrcaSlicer Nightly builds are developmental and may contain bugs.

• Developmental Build: Remember, this is a work in progress. Not recommended for all users. If you’re an experienced user looking to explore the newest features for your Snapmaker machine, this build is for you!

• Installation Warning: This special edition currently shares the same name, version number, and profiles as the official Orca Slicer. If you have the stable version Orca Slicer installed and want to prevent overwriting it, do not install this special edition.

Download & Installation

1. Make sure you have read the Warning above and understand that this is a development version.
2. Select the version that corresponds to your operating system, then download and install it.

OrcaSlicer_Linux_Ubuntu2404_V2.1.1.AppImage
OrcaSlicer_Linux_V2.1.1.AppImage
OrcaSlicer_Mac_arm64_V2.1.1.dmg
OrcaSlicer_Mac_x86_64_V2.1.1.dmg
OrcaSlicer_Windows_Installer_V2.1.1.exe
OrcaSlicer_Windows_V2.1.1_portable.zip

Welcome Feedback

We greatly value feedback and testing contributions from our users. Your feedback will help us to further develop this special edition of Orca Slicer for our community.

Please report any issues and test findings in this thread or email us at support@snapmaker.com.

Note

Currently, G-code files cannot be transferred wirelessly from Orca Slicer to Snapmaker machines. We will update this discussion thread with instructions if this feature becomes available.

Resources

• Snapmaker Wiki: Using Orca Slicer Official Release with Snapmaker machines
• Orca Slicer Official Github project page

[macdylan]

For this release please update sm2uploader to prerelease-v2.9

[Hauke]

Hi Jade,

that’s very good news, thanks!

Is Snapmaker actively discussing to contribute to the open source project, i.e. work with the Orca Slicer community to benefit from Snapmaker’s development by giving back code? That would be just the icing on the cake!

[clewis]

Is Snapmaker actively discussing to contribute to the open source project, i.e. work with the Orca Slicer community to benefit from Snapmaker’s development by giving back code?

Looking over the commit history, I doubt it. A bunch of the commits are deleting things or renaming things. Pushing PRs back to the main repo gets really messy when you do that. Snapmaker has a history of doing hard forks. The Original’s firmware was a hard fork of Marlin, with the git history stripped out.

[Hauke]

…which means decoupling from the general development of Orca Slicer. Any further improvements in Orca Slicer will most likely miss in future Snapmaker-Orka-Slicer-branch.

On the one hand I understand that companies want to A) have control over ther IP, and B) stay on a code base they 100% control. I still would rate this short-sighted - A) is mute since the licensing terms oblige you to make your mod’s open source (IP public), and B) decouples you from the community development. Building the knowledge to work together with the community ensures that you stay always on the best version of a software and that people embrace your product because it is fully supported by the project.

With SM2’s firmware it is the same: It is based on a by now considerably outdated Marlin version, and some important features are not there.

From the open source project’s standpoint it must look even unfair: Companies digest what the community has built for free, shoot out products to earn money, but do not give back to the community. The only exception I am aware of is Prusa, who reliably interact with the community with mutual benefit!

EDIT: Reading a bit closer through Jade’s post it seems they at least stay connected to the main branch - this is a step forward, and perhaps exactly the learning curve to become community member Go, Snapmaker, go

[clewis]

@Hauke

From the open source project’s standpoint it must look even unfair: Companies digest what the community has built for free, shoot out products to earn money, but do not give back to the community. The only exception I am aware of is Prusa, who reliably interact with the community with mutual benefit!

There’s been a ton of open source uproar about this lately, particularly with Cloud Providers. AWS has the richest set of cloud services, and they skate right up to the line. For my own open source work, it’s always been in my best interest to get my changes accepted by the larger community so I don’t have have to maintain my forks.

@Hauke

EDIT: Reading a bit closer through Jade’s post it seems they at least stay connected to the main branch - this is a step forward, and perhaps exactly the learning curve to become community member Go, Snapmaker, go

That’s easier to do, in the short term. change macOS project name to snapmaker · Snapmaker/OrcaSlicer@83293cb · GitHub tells me this is not a short term fork. The longer this goes on, the harder it is to merge upstream changes. I can see why SnapMaker doesn’t want to test their specific changes with a wider variety of printers. Still, IMO, it would be more work today, but less work long term to contribute those changes back and let the Orca team maintain them long term. I have had some long lived Chef recipes that I was trying to get my ports merged (FreeBSD support). The extra time I spent testing after merging upstream was a big waste.

[Jade]

@Hauke

that’s very good news, thanks!

Is Snapmaker actively discussing to contribute to the open source project, i.e. work with the Orca Slicer community to benefit from Snapmaker’s development by giving back code? That would be just the icing on the cake!

Yes, we’ve been in active discussions with Dylan while working on this project. You’ll likely see PRs to the Orca main repo soon.

I’m not an engineer, but I’ve been part of internal discussions. As a forum moderator, I’m doing my best to bridge the community with our team. I hope my posts and sharing make this space more helpful and transparent.

This project is still in its early stages, so we can’t commit to a release timeline for this branch yet. However, we wanted to share our progress so that some of our more experienced users can test out the new features and improvements in the development version. The software team also needs user feedback to help move the project forward.

Looking ahead, it’s crucial for us to stay up-to-date with the latest from Orca Slicer’s upstream, as it enhances the user experience and boosts our products’ competitiveness. At the same time, contributing back to Orca’s main repo is key—it benefits a broader user base and increases our brand’s influence.

As for the development of SM2’s firmware, the modular hardware design of our product is quite different from the hardware frameworks supported by Marlin. We had to make a lot of custom modifications tailored to our hardware, and these changes are hard to merge into Marlin’s main branch. If we tried to merge all these custom changes into Marlin, it would require a significant amount of development resources (which isn’t realistic for a team our size) and wouldn’t offer much improvement to the SM machine’s functionality or user experience. It would also add a lot of code to the Marlin mainline that wouldn’t be useful for non-SM2 machines. So, it’s been challenging to integrate those changes into the Marlin mainline.
SM2 Firmware GitHub Project
SM2 G-code Commands Reference Wiki

We’ve been relied on open-source projects to grow, and we’re committed to giving back to the community that has supported us. Snapmaker is dedicated to upholding the spirit of open-source by contributing in meaningful ways.

[Rwide]

Sorry for being a bit negative here but i’m a little bit frustrated by the starting procedure. It is TERRIBLE imo. Here’s what i (hate) don’t like about it:

Why is the toolhead unparking it’self while the bed heats? just too ooze out a little extra material for some reason? Just heat it on top of the ooze blocker??? it’s what it’s there for, no?
Why is the z-dist while purging so high? It’s faaaaar above the bed…
Why does it purge a mount everest of material litterly drowning the nozzle causing material to stick to the side of it while standing still. What is the point???
I also dont understand the temperatures. I have it set to 215 and the temperature variation set to -60. Why does the starting procedure heat the nozzle to 165???

Why can’t you just use a NORMAL starting procedure?? is that really too much too ask for?? Why do you feel you need to reinvent the wheel, making it square??? I have used many different 3dprinters and seen many different starting procedures. This is by far the worst starting procedure that I’ve ever seen. Just keep it simple. What were you thinking??

Home the toolheads
Heat the bed
Heat the nozzle(s) to printing temp/idle temp while they are in parked positions
Do the purge line(s)

If I remember correctly, you had a great starting procedure in Orca when I tried it a long time ago. What the hell happend??

[Slynold]

Alright, I think it’s great. I just want to know what’s better in this nightly?

Snapmaker machines are already integrated in the orcaslicer release and I did a lot successful multi extruder prints with this. Used the second extruder for support material. Also with the sm2 uploader. I started using this since the high speed beta firmware. So what are the breaking changes in this build?

I just needed to change stage start gcode for my specific build plate setup.

Regards

[Slynold]

It is just using the heat up times to check the axes, traversing the bed and it gives you time to clean your nozzles.
I think it’s good.

[Rwide]

Bro It doesnt “check the axes”? It just moves slightly off the parking position. The homing procedure already does that in reverse.

Cleaning your nozzles? Great! The procedure then drowns the nozzles in material again, causing it to need another cleaning. Makes no sence. It’s terrible!

There is a reason most printers do a purgeline instead of a purgeblob. Its to keep the nozzles clean. Why have a starting procedure that starts with “cleaning your nozzles” and ends with getting them dirty again. What is the point???

[Slynold]

@Rwide

Bro It doesnt “check the axes”?

Not your bro

Maybe the traversing movement is gone. Than sorry. I need to check back!

[Rwide]

The point is not the “traversing movement”. The point is the unneccecary oozing in unparked position and the execive purging while standing still wich makes the nozzle dirty again.

[Rwide]

Here is what the starting procedure produces if not using a skirt or brim. The circle to the right is the first one. As you can see the walls are missing. Is there perhaps also a retraction somewhere where there shouldnt be??

[SnapSnap]

I agree with you.

The nozzle oozes a lot of material after leaving the parking position waiting for the bed heating up.

Yes you have plenty of time and space to clean the nozzle but it is drowned in the purgeblob afterwards and you have no time to clean it again.

It does an additional purgeline afterwards thow.

Even thow it still drags an oozle line while traveling to the starting point, during the first 10 mm after starting the print there is quite often no material extruded like the missing wall in your right ring shows.

As a consequence I always add at least 2 skirts on every print I do on my J1 with Orca.

Imo this behavior is in Orca for quite some time and not a result of the special Snapmaker beta, which I have not installed yet.

That said I too think the start code should be reworked.

[Rwide]

Yes it obviously should but nobody seems to care. Instead of making sure the starting procedure delivers a heated and primed nozzle to the starting point, we get a bunch of presumptuous extras…

[Jade]

@Jade

Streamlined G-code: The default Machine Start G-code routines for Snapmaker 2.0 and Artisan have been streamlined for better performance.

@Rwide @Slynold @SnapSnap Hey guys,
Let’s get more positive discussions going and help push this project to the next level! In this development version, we’ve optimized the Start G-code for the Snapmaker 2.0 and Artisan machines. However, the Start G-code for J1/J1s in Orca Slicer hasn’t been changed yet. You can check out the full changelog in the original post.

As we move forward, we’d love to hear your feedback on using Snapmaker machines with the official Orca Slicer. We aim to make more improvements to this slicer.