Take the latest Profile from @McGybeer and go for it. This is working fine so far, even with the Ps2.6.
Hello all,
what kind of message is this?
What should I do with it now?
@McGybeer something is not working for me…
Your start code seems to be wrong.
You need the G92 E0.0 in the “before layer change g-code”
With PS2.6 you have to change the custom g codes (left extruder) like that for the correct temperatures:
@ne0xys : Do you know what the highlighted line means. In the documents there is no argument for S200
Your path should look like that:
E:\08_Software\SnapmakerJ1\SnapmakerSIMFIX\smfix-win64.exe;
Hello again,
since I unfortunately still do not get along, I have another question.
In the installation instructions, I do not understand, point 5
- download PrusaSlicer 2.6+ (it’s alpha, but quite stable) Release PrusaSlicer 2.6.0-alpha5 · prusa3d/PrusaSlicer · GitHub
- download Snapmaker2Slic3rPostProcessor Releases · macdylan/SMFix · GitHub
- import config.ini profile
- add j1 (googliola).svg to the bed configuration (PrusaSlicer: Printer settings > General > Bed shape
- add path to postprocessor (Print Settings > Postprocessing Scripts. (Put path in quotes if there is a space).
oh, shit, now i get it…
That was my mistake all along…
@3DPrintMunich Thanks… 
Hello guys, recently I upgraded my sm2uploader and now it can simulate OctoPrint, which means you can directly send sliced files to Snapmaker printers(A Series/J1/Artisan) from slicing software such as PrusaSlicer/SuperSlicer/ideaMaker.
Get sm2uploader@v1.5 from Release v1.5 · macdylan/sm2uploader · GitHub
Big thanks to @kanocz for implemented the SACP protocol in golang which I’ve used in this project.
super idea to implement OctoPrint emulation!
P.S.: updated readme in my repo to forward users to your implementation 
Out of curiosity: did anyone of you try that Prusaslicer 2.6 profile @ne0xys has posted here? Great Sharing: Prusaslicer Profiles by Dylan and McGybeer - #94 by ne0xys
That one looks really interesting to me.
(By the way @i3sven: it feels your english has improved quite a bit since we started the “get the J1 running” journey )
Based on the details provided, it appears that the “J1Upload” script, created by @kanocz, has been enhanced and integrated into the latest version of sm2uploader. As a result, the enhanced sm2uploader is now capable of performing the same tasks as the original “@kanocz” script, effectively replacing the need for the latter.
Can you please confirm if my understanding is accurate?
Any M command with a value exceeding 999 is likely a custom command that has been implemented by manufacture in the firmware. Only Snapmaker would be able to provide an accurate answer to this question. We can only assume it could potentially be referencing proprietary code, nothing major. You do not find that on my gcode.
in general - yes… the only side effect that you need to start sm2uploader manually as separate process, but you get better integration with PrusaSlicer (my solution was to use it as a filter and it’s not ideal - for example if communication with printer fails you need to re-slice and so on)
So, just to clarify, the sm2uploader cannot be added to the post-processing script in Prusa Slicer in the same way as your J1upload script? Instead, it must to be manually initiated separately, followed by opening Prusa Slicer, and then the feature will be visible?
The extruder switch is handled by the M2000 gcode in the tool change gcode that Snapmaker coded into the marlin firmware and that @macdylan explained here. That one looks quite fine to me.
Why G4 S0* commands are being commented out is unsure - the comment suggests that a dwell command of less than 1s causes problems with the Snapmaker M2000 command. @ne0xys is my assumption right about that?
This is a reported bug, “G4 S0” does not cause any wait action, but cause collisions with M2000
PrusaSlicer add zero delay and Im not sure why:
Ah nice to know, thanks. I also saw them in the code and didn’t understand it.