I have a J1s. I slice my STL files with Cura 5.8, with the Snapmaker_J1 plugin, then upload the gcode to Octoprint, attached to my J1s thru the (back) USB port. I have discovered that the gcodes so loaded print differently, compared to gcodes loaded off a thumb drive thru the front USB, or uploaded over WiFi. In particular, I had to play around with the M605 S[01] command to get the two print heads to stay out of each other’s way during tool changes.
In the Cura plugin, there is a file, "snapmaker_j1_extruder_[01].def.json, with the line, “default value”: “M2000 S200 V250 A6000”. Another user on this forum, Wombley, posted in another thread that M2000 is used to change toolheads in the J1s, but I cannot find any documentation of it, aside from a few references to it in these threads. In fact, depending on the printer model, M2000 seems to do a number of things, including control of the laser in the Artisan models, and return status information in the SM2.
Wombley also indicated that M2000 is actually a macro that only works when a job is loaded thru the front panel on the printer. Looking at the source code, which is a year old, and apparently no longer supported by Snapmaker, it does appear to be a command to save a little time when changing toolheads, by moving both tools at the same time.
SO…does anyone have any detailed information on the M2000 S200… command, and whether it does anything when included in gcode fed into the J1 over the rear USB port?
M2000 is a Snapmaker-specific, overloaded command. S200 tells it it’s a fast tool change. V250 is the speed. A6000 is the acceleration.
The lore goes that this command is only executed when in print mode via the screen firmware, not the MCU/rear USB. As of today, any gcode fed directly via the rear USB won’t execute it. (I’ve tried, too.)
I’ve always been as curious as you though. It attempts to execute via an OctoPrint terminal and correctly reports, Not printing, can not move T0 T1 now. The expected error when the system reports not printing.
Snapmaker would have to say how system_service.get_status() is set, and how it’s checked. If we take at face value it only works via the screen, it may be streaming print jobs don’t trigger printing status, or that the printing status is kept by the Android firmware (and not set by remotely streamed gcode).
I would venture a guess this is the problem. Rear-fed print jobs (gcode streams) don’t trigger the “printing” flag, so the MCU skips it.
All that said, this was already bug reported in January:
The problem may only be this check of the printing status. The right thing to do would to have host commands enabled, or some legit way for OctoPrint-hosted jobs to set the printing status.
The exciting thing to do in the meantime would be removing lines 246-250 from M2000.cpp, recompile and flash. That is, completely skip the print status check.
Let me make sure that I understand the situation so far:
When a gcode file is loaded thru the rear USB, it goes directly into the IDEX firmware, an up-to-date version of which is on github. It would be possible, if one is sufficiently adventurous, to recompile that firmware, and flash it to the control board in the J1.
Meanwhile, there is a front panel, that has its own software and GUI, running on an Android platform. Gcode loaded thru the front USB or Wifi gets some processing done to it before it is passed to the controller (MCU). I imagine the source code for this interface is available somewhere, but I don’t use it, so haven’t really looked for it. So, the gcode sent to the printer behaves differently depending on which route it takes.
Some of the notable services available ONLY thru the Front Panel are the “fast tool change” (M2000) and filament runout detection. Without the ability to process the M2000 command, gcode loaded thru the rear USB is prone to conflicts between the two toolheads, requiring the addition of M605 S0 and M605 S1 commands in the start-up code. Luban does not have provisions for user-customized start-up gcode, as Cura does, so is not really suitable for use with Octoprint. The IDEX firmware may be able to process the M2000 command, but Snapmaker does not support that kind of shenanigans, so, for now, it is the proverbial “exercise left to the reader”.
Yes. I have done or could do. The instructions on Github are actually quite good. In the end you recompile and get a small binary, put on a usb, and do a local firmware update. It patches only the Marlin part of the firmware.
Yes, sort of. More below.
Not in the user interface that I know of? I don’t really use Luban.
Just checked though, and on Windows, the start gcode is in a json file C:\Program Files\Snapmaker Luban\resources\app\resources\print-settings\printing\snapmaker_j1\machine.def.json using \n line breaks.
I’m not 100% sure this alone solves it. More below.
I dunno if/when they’ll get around to fully getting OctoPrint compatible. But we can!
I looked at this more last night. For background, I never really dug into getting more out of OctoPrint as 1) I personally only needed it to provide a print cam and let me execute remote commands from time to time and, 2) wasn’t really familiar with OctoPrint or Marlin firmware having come from Klipper.
Since then I’ve gotten a little more familiar with Marlin. Looking closely now, I think most of the problems stem from a lack of host action commands. That is, the ability of a remote host being able to communicate starts/stops/pauses with the builtin Android host (and vice versa).
If either Snapmaker or the community took a deeper dive with the Marlin firmware to enable HACs, then POOF. All of the things might work normally. For example, I can see the fast tool change appears to actually be programmed in the Marlin part of the firmware, not really executed by the Android host. (Filament changes/M600 might be though.)
If HAC’s were enabled, I suspect the competing hosts would broadcast stops/starts/pauses to each other and much more functionality would work via OctoPrint.
That’s about as much as my sloppy gadget hacking eyes can see. Would be great if someone more knowledgeable chimed in, especially @Jade or @Zoe .
I see the starting and ending gcodes. In Linux, they are in /opt/Snapmaker Luban/resources/app/resources/print-settings/print/snapmaker_j1/machine.def.json.
I also don’t use Luban because my laptop runs an older version of Linux, and the current Luban binary won’t link to the older system libraries. The most recent version I could get to run is 4.6.3. Cura, OTOH, is a fully self-contained AppImage.
I was able to solve all my issues with the toolheads not parking, or homing to the wrong side, by careful use of the M605 commands. See my previous posts for the details.
Marlin documentation does not have anything to say about M2000. It is clearly a non-standard command implemented by Snapmaker. The IDEX source tree has M2000.cpp outside the “Marlin” directory tree, under the “snapmaker” branch.
I will likely take a stab at re-compiling the IDEX firmware with HAC enabled, to see if that allows the filament runout detection to work, my OTHER work-in-progress.
Bypassing the print status check for M2000 S600 is pretty easy. I could compile that for anyone who’s interested to try an update, but it’s a kind of “loaded gun” without thinking carefully.
Imagine asking it to swap tool heads while the printer is idle and parked.
As for enabling HACs, that’s what I looked at more last night. It’s not just a switch you can set.
First, there’s other Marlin commands that may need adjustment. Second, there’s not knowing fully how the Android host reports things or controls jobs. For example, all host screen and SD card Marlin functions appear disabled.
It might be something we can figure out without needing the Android host software, or it may be Snapmaker has to change the host side to play nice.
(The Android host software is closed source. Likely an app running within Android, so they’re not obligated to share it. )
I’m also curious to play around with it and try some things, but I’m not as experienced using Octoprint to issue print jobs and test it.
I just took my first swing at compiling the github IDEX code. It failed with the error ‘snapmaker/debug/debug.cpp:32:10: fatal error: …/j1/switch_detect.h: No such file or directory’. Any advice while I track that down?
Too late. It is named “J1”, while the code looks for “j1”. My first source code tweak is on its way!
Same issue with “marlin” in another file, needs to be changed to “Marlin”.
Just finished compiling…SUCCESS!
For completeness:
SnapmakerController-IDEX/snapmaker/debug/debug.cpp, line 32: #include "../j1/switch_detect.h" ← must be changed to “J1/switch_detect.h”
SnapmakerController-IDEX/snapmaker/module/update.cpp, line 23: #include "../../marlin/src/core/serial.h" ← must be changed to “Marlin/src…”
worked fine. I had to manually 'chown -R ’ the tree to my own user name.
My first two attempts to compile failed as described above, because of conflicts between directory names in the “#include” directives, and the actual names (j1, marlin vs J1, Marlin). I have confirmed that these conflicts exist in the github online version, as well.
After getting a successful compile, the instructions say to run:
pio run -t pack
This is supposed to generate the image to be copied to a USB stick. However, the
.pioenvs/GD32F105/firmware.bin
file is deleted (along with everything else in the GD32F105 directory) before the command completes, giving a FileNotFoundError later on. There is a warning at the beginning of this step about Obsolete PIO Core, and another warning about uknown configuration option monitor_flags in section [env]. I’ll have to look into those to see if they can shed any light.
Hmm. Yeah, strange. I get the firmware.bin after building (doesn’t disappear, still there now) and the final binary in Snapmaker\SnapmakerController-IDEX\release after packing.
Oh! Success! Deleting the old platformio did the trick! My printer is a few hours into a 12 hour print job right now, so I’ll try flashing the firmware sometime in the next few days to see if it still works as it should.
THEN, I’ll look into tweaking the M2000 S200 command, and see if I can enable HAC
Safe to assume you didn’t look at enabling HACs? I might try it just out of curiosity unless you did already and it didn’t work.
I’m still not optimistic that all functionality will work by simply enabling them. Simple enough to try. (I just never used OctoPrint to send prints, so I haven’t tried this yet because “learning required.”)
Actually, I did some of the preliminary work: installed Visual Studio Code on my laptop, then downloaded and compiled the firmware, but have not tried to install it on my J1. I’m printing some Xmas gifts for my kids, so now is not a good time to brick the printer if I screw something up. Unless, maybe, I’m pushing for a new printer for myself for Xmas. Which, I’m not.
So, yes, poking at HAC is still on my ToDo list, but not today.
Was thinking about enabling host mode. May have some time in a few weeks to play with trying.
I suspect the most suspect thing to test for is how the Android screen works when it’s enabled. Octoprint will surely check status, but what if octoprint initiates a print and you try to issue any commands or controls from the screen…?
“Far better it is to dare mighty things, to win glorious triumphs, even though checkered by failure, than to take rank with those poor spirits who neither enjoy much nor suffer much, because they live in the gray twilight that knows not victory nor defeat.” – Theodore “Teddy” Roosevelt
)
