Can you connect to the Snapmaker J1/J1s to Orca so to send prints wirelessly like in Cura?
If yes, is there a tutorial somewhere. If no, then when?
Cura doesn’t have pressure advance, volumetric flow rate, print inside/outside/inside wall, or seam painting.
Unfortunately it’s not available out of the box yet but you could use sm2uploader:
Let them in the posted topic know you would like to see the feature in the future.
I use octoprint, but that requires a raspberry pi
I have tried using Octoprint for may Snapmaker J1 but it keeps making the Extruders run into one another when commencing prints that use both extruders. Have you found a fix for that? AIts also gtelling me that Some Printer events are not being propagated to octoprint like filament runout for example. This makes octoprint practically useless in my opinion.
Hi Bastian, first - welcome!
You can try to use the last FW for J1 - v2.8.0. It is the first implementation of Octoprint compatible server into J1 and has several issues, but it works. Here is the link for download: Snapmaker J1/J1s Firmware Updates and Downloads .
The discussion about this version is here: Firmware beta for J1/J1S! 2025-12-31 . Please note: evene the dates of FW v2.8.0 are different, the binaries are identical.
Anyway, I am almost sure that the head colisions are caused by prepared gcode. What slicer and profiles do you use?
Hey Viktor,
thank you for your fast feedback.
Let me wrap up your response for my Understanding. The version that you are suggesting is already live and available through the official Update Service on my J1 or are you suggesting that i flash a nightly version onto my machine?
You also said there is several issues with that version, are theese issues documented?
What do you mean they are caused by prepared gcode? I am almost certain that it is not the Gcode, as when i upload the gcode file from the Slicer to the Printer using Luban it will print normally, the toolhead collisions only occur when i try printing through octoprint.
This makes me come to the conclusion that:
A: Octoprint is modifying the GCode in a way that breaks it
B: Octoprint is not modifying the GCode in a way that the printer would if the print was started through its interface(like some sort of hardware override)
In either case it seems like the Gcode the J1 is receiving from octoprint is different from the Gcode if i upload from the Slicer directly.
Regards
Does this Octoprint compatablie server now also Support Host Action Commands?
I am using Orca Slicer with the Official Printer Profile provided by Snapmaker.
I am almost sure that your plate name at Orca Slicer is “Untitled” even you want to print two copies (or mirrored copies).
The issue is that J1/J1s changes the mode of printer according to plate name. The initial gcode for J1 starts with these commands:
{if plate_name =~/.IDEXDupl./ || plate_name =~/.IDEXCopy./ }
M605 S2 X162 R0 ;IDEX Duplication
{elsif plate_name =~/.IDEXMirr./}
M605 S3 ;IDEX Mirror
{elsif plate_name =~/.IDEXBack./}
M605 S4 ;IDEX Backup
{endif}
It means - if your plate name is “IDEXDupl” or “IDEXCopy”, both heads will print identical copies, in case of “IDEXMirr” the J1 prints two mirrored copies. “IDEXBack” is backup mode - any issue with initial filament (run-off, clogged nozzle,…) changes heads.
Any other name of plate results in standard prints.
Change name is easy: click on “pen icon” next the “Untitled”
Remember: all models shall be located on left side of plate, behind the blue/red lines (Copy/mirror prints)..
Just to be clear:
It is not gcode, it is the setting how the final gcode will be prepared. Based on plate name, the gcode will have correspondent parameters for M605 command.
First of all, I do really appreciate your fast responses and your willingness to help, yet to me, it does not seem to be an Orca problem, as the print will work fine when I use Luban to upload it to the machine and start it from the display. It must be originating from OctoPrint, as I am faced with the same problem when printing a file that is sliced with Luban through OctoPrint.
I also feel like there is a thread documenting my exact struggles here:
But sadly, that thread seems to have been dead for quite some time.
What I am really looking for is Host Action Commands and a solution for the custom G-code problem with the tool changes, described in the thread I linked like this:
“Issue 2. Snapmaker uses a custom gcode command for tool changes (M2000 S200). Originally, this gcode was incompatible with Octoprint. I have altered the code so that it works with Octoprint. This test resulted in successful tool change when switching from T0 to T1. T0 returned home and T1 continued the print in the correct location. However, when switching from T1 back to T0, T1 did not return all the way home. It stopped at x324 because it was restricted by software endstops.”
It seems that at this point, enabling Host Action is possible by compiling the Snapmaker firmware and uncommenting a line in the C++ code. But Snapmaker stopped uploading their code to the public repo, which would leave me stuck with a 5-year-old version of the J1 firmware, which is not really a great outcome.
Even though many internet tutorials give this as a “simple” solution, I am also not quite sure if just enabling them might cause other errors in the build.
I do feel like there is not much I can really do about the problems with the printer heads; the person posting the other thread seems to have built a workaround, but I really don’t feel comfortable working on the firmware code of my printer.
It does really feel like there should be an official solution by now, as using OctoPrint has really become a fairly normal requirement for consumer printers.
At this point, I feel like I should open another thread regarding OctoPrint support. Do you agree?
The problem you’re having is caused by snapmakers custom gcode for tool changes. It is not recognized by Marlin and Octoprint. It doesn’t exist in the Marlin firmware code base, so it is ignored and the current tool does not move to home before the next tool starts printing.
I haven’t been keeping up with snapmakers firmware changes, but my communications with their support team have led me to believe that you’ll never see real improvements to the firmware. Their firmware updates are always minor (and buggy) and are only done for appearances so that people will think they are actively developing and improving the firmware when they have actually moved on and are completely disinterested in it.
My custom firmware version for enabling Octoprint features was a ton of work (enabling host action commands is much more complicated than uncommenting a line of code) and was actually really good in a lot of ways. The only issue that remains is that my changes have somehow caused spurious runout detection errors during prints, and my ADHD brain just kinda moved on to other things before I was able to fix it lol. I think the ADC sensitivity just needs to be adjusted. I remember seeing code that enabled testing and tuning the ADC runout sensors. I think Snapmaker devs who wrote that code could solve the issue very quickly if they wanted to because they must know a lot more about those unique ADC based runout sensors than I do. They told me they didn’t have time for J1 firmware development cuz they were working on U1. I moved on. I hope to find motivation to solve that issue soon. I don’t think it will be very complicated. It will just require several test prints and trial & error to tune the ADC sensitivity.
Thank you for your reply. I was really hoping that YOU in particular would be the one to reply, as you seem to be very knowledgeable on this topic already.
Can you maybe help me understand a little bit more about the problem?
If the command that is being misinterpreted/ignored is in the G-code after slicing, how did the slicer know to put it there in the first place? Is it configured as some sort of event that will be executed on every toolhead change inside the official printer profiles?
What’s adding to this is what I think I know about OctoPrint:
On another note, in your opinion, using your Snapmaker fork from years ago would not dramatically reduce the feature set?
I was kinda expecting that there was not much development going into this machine anymore, but I have to say that I am also quite frustrated with the lack of basic functionality like Octo connectivity.
Are you still using your J1? I remember reading in some thread that you have to start prints remotely as you want to print toxic materials and have your workstation in another Room, so did you end up replacing your J1 entirely? I am also at the point where i am considering changing Hardware do you have any suggestions?
It also feels like Snapmaker is trying to restrict the users in every way they can. They want to direct you into using Luban (a shitty Cura fork), but when using the terminal in it, they won’t even let you execute G-code that configures EEPROM, and they disable host actions (likely so they wouldn’t have to use resources to make that API actually work), even though they were a thing already back when the printer was conceived.
All just very frustrating corporate stuff.
The slicers allow you to enter custom gcode scripts that the slicer inserts into your gcode file at specific points. An example is the purge sequence that starts before each print. That’s a script in your slicer profiles “start” section. There’s also a “tool change” section which is where snapmakers profiles have their custom tool change gcode. The slicer inserts that script at each tool change.
The printers firmware is basically the brain of the printer. Octoprint sends the gcode line by line to be processed according to the code in the firmware. Octoprint will send anything you want it to, but if it sends something that isn’t in the gcode library of the firmware then the firmware just doesn’t do anything with it.
Snapmaker uses a modified version of Marlin firmware for the J1. Most printers rely entirely on the firmware for every action that the printer performs, but Snapmaker is unique in that it added a second brain to overcomplicate things lol. The android HMI screen on the printer runs an app that also processes commands separately from the Marlin firmware, and that is where their custom gcode commands are processed. If your gcode isn’t executed locally by, or sent wirelessly to, that android device, then the custom gcode commands will not do anything. It’s basically two different computers. The printer main board running Marlin firmware, and the android device running an app. When you use Octoprint via the usb connection to the main board, you are only talking to Marlin and not the android device.
I haven’t kept up with any of snapmakers firmware updates since I created my fork, but I doubt that they added anything that matters. I don’t think you would lose any features by switching to my firmware except for filament runout detection. You would have to turn that off until that spurious runout detection bug gets fixed. I still use my J1 running my own firmware. I love Octoprint too much to go without it just for filament runout detection. I use prusaslicer and send my gcode wirelessly to Octoprint, I have temperature and humidity sensors in my enclosure, I have automated enclosure temperature control with a heater and exhaust fan, I can remotely power the printer on/off, I have a camera installed. I can remotely monitor and control everything on my printer using Octoprint and its plugins. Octoprint alone enables you to do a lot more than snapmakers firmware updates ever will.
You can provide very simple test. Generate gcode and print it via Octoprint and directly from USB drive.
Viktor, are you even reading what i am writing. This is getting quite frustrating.
Frankly, please specify which Slicer, printer profiles and firmware do you use. Note, the Luban is “totally different world” - it use proprietary SACP protocol. This protocol is not used for new U1 printer and J1 has new FW v2.8.0 which addopted the Octoprint protocol directly. Have you installed this new FW? I have provided you two links, one with download link, one with discussion about issues. Have you checked both of them? The v2.8.0 has two main issues (no previews of prints in display and very simple - and in Chinese - webserver) but you don’t need separate Octoprint server anymore.
My J1 has RPi with Octoprint for more than 2 years and never found any Gcode modification in OctoPrint. Generally, it is just print server which sent gcode to printer without any change, so I don’t understand how Octoprint can modify the gcode in any case (standard/copy/mirror/backup/two material prints). Now (since January), I am using FW v 2.8.0 with Snap Orca and again - without any problem.
So, please, specify:
