Klipper on J1/J1s (success/progress)!

J1/J1s IDEX
1

In collaboration with Evil Azrael and Franck FG, we have made significant progress toward a fully functional Klipper J1/J1s! Resources are listed at the bottom of this post, and, when used complementary to one another, should have all the information you need to get this working on your machine. Review all of them, including the resources linked within them, before starting.

Note that this is still very much a work in progress, and I would caution less-experienced users from jumping in without doing proper research. There will almost certainly be numerous bugs to work out, but the bulk of the work is ready for wider-scale beta testing. Please see the associated githubs and linked discussions for all resources and periodic updates.

I am not a full-time programmer and only have a chance to work on this project intermittently. If/when you discover bugs, please feel free to let me know, and I will try to address them in order of criticality, but understand that it could take me some time to get around to working on it, or I may never get to it at all. That said, I intend to test and optimize functionality as my time allows, for my own use, if nothing else.

To date, I have not tested or attempted integration of filament runout detection. Due to Klipper limitations, the calibration routines treat the datum pads like filament sensors, so there are additional complexities to resolve as that effort progresses, and I simply have not had the time. Hopefully, I will have a chance to address this in the future, or I encourage others to take my github resources and attempt to get it working on their own.

DISCLAIMER: This is an invasive process. You will be modifying both hardware and software which will very likely void any manufacturer warranty. The possibility exists that you will damage or destroy your machine. As with any electronic modification, you could injure yourself, or worse, if you do not take proper precautions and utilize proper safety procedures. Any resource, including guides, g-codes, macros, internet posts, demos, examples, advice or anything else is provided completely without any warranty whatsoever. Proceed at your own peril and only if you feel fully comfortable with the possibility that your body or your printer will cease to function as a result of actions taken during this conversion.

Having said that, this is not a particularly complex project for anyone with basic Klipper/Linux knowledge and the ability to read and follow directions.

Good luck!

Resources:
KlipperOnJ1
Deskwared/Klipperized-Snapmaker-J1-Macros: Macros for the Klipperized version of the Snapmaker J1(s)
FranckFG62/J1s-Klipper-Macros: Cinfiguration Klipper et macros pour Snapmaker J1(s)

2

That’s awesome!!!

Seriously, thank you for working on this. I’m at my wit’s end with the stock firmware. The J1 has such good hardware on paper, but the original firmware is just… unreliable. Random failures, inconsistent behavior, features that should work but don’t. I’ve wasted so many hours troubleshooting issues that shouldn’t even exist.

I’m honestly desperate for a real solution. Maybe with Klipper, we can finally use the Snapmaker J1 as the hardware was actually intended to be reliable, predictable, and fully under our control instead of fighting against it.

Please keep us updated. This gives me hope.

3

I am hoping that it will reach a larger audience now, and we can get some additional eyes and hands on everything to coax out the bugs. If you give it a go, and run into issues, please let us know.

4

I will be able to install and test it by maybe end of next week. Looking forward for it already!

6

I will continue to follow your project; it really means a lot to long-time users. If there’s anything you need help with, feel free to let me know here directly, and I will help coordinate and consult. By the way, I have pinned this post for three months.:hand_with_index_finger_and_thumb_crossed:

7

Optimizations continue. Squashed a few little bugs in the start/pause/resume/cancel routines this evening. Started diving into filament runout with only limited success. It works on T0 and T1 in single print modes, but in mirror/copy modes it only works on T0 -or- T1 (depending on how I write the macro.) Still needs work. I did get TMC autotune working, quickly, just to give myself a little win after fighting the runout situation for a while!

8

Do yourself a patreon page and i will be happy to support. I used to have Aldoo Cocoon (wanhao duplicator) printer and there was an aftermarket advi3++ subscription model firmware, that breathed bew life into the printer that i enjoyed for years until replaced with J1. It was a similar landslide transition from buggy manufactorer’s firmware that stopped updating soon after to a proper and convenient UX, not dissimilar to what you are doing. Long story short i will be happy to support and i don’t mind if all instructions and files are behind the paywall, imho effort needs to be rewarded.

9

Also i think J1 is a great step towards engineering/quality printing where you basically need a main and the secondary, support filament. It had really great hardware and sturdy metal frame, where plastic U1 don’t cut. I belive the tragedy of J1 is not with hardware but with lack of strategy and bleak software capacity of Snapmaker, shich held me off bying anything from them, at least for now. Add chamber heating, proper ventilation and better filament guide system, which could have been done with addons, it will be so much better experience

10

Thanks for the support! I only do this for fun, so I’ll keep putting it out there for free. Maybe someone even smarter than me (which isn’t saying much!) can get some of the things optimized and squash some bugs.

11

Update as of 30 April:

I believe I have filament runout working in all print modes. It still needs performance enhancements, and the code should probably be cleaned up, but it appears to be detecting runouts in all modes. This was a complex solution that took many hours to develop! As always, newest updates are on my github page.

There were a few other little things I optimized over the last few days, as well. Still a lot of work to get things working optimally, but basic functionality is improving. Hopefully will get into the little improvements/tweaks once the major functions are all solidly established.

12

I recently uploaded the most up-to-date versions of config files. Everything is progressing well, and seems to be working. If anyone is beta testing, I’d recommend downloading the newest stuff and giving it a try. Let me know if you discover any issues.

13

@DeSkwared

Thanks to everyone involved in this project! I’ve successfully installed Klipper on my J1(s) and am now calibrating.

Quick question regarding Z-offset with a 5mm glass build plate: After running the calibration macros/bed tramming, I’m seeing manual_z_offset = 1.97, within the variables.cfg.

Do I need to manually account for the 5mm bed thickness somewhere (endstop, probe offset, or variable), or is the macro already designed to handle thicker build plates correctly? Just trying to avoid a nozzle crash into the glass.

Thanks a lot!

14

You will notice that the _Z_DATUM_VARS section in the z_calibration.cfg contains a bed thickness variable. It is already set to 5.0mm. If your bed is thicker (or thinner) than that, you can set it higher or lower.

To get your own, specific offset, I would recommend deleting the “manual_z_offset” line entirely, and establishing it yourself, so that you get a perfect match for your printer. (I should probably just delete it from the config and upload a new file to the github.) The 1.97mm is set for my printer, specifically, based on my own calibrations, since the config is a direct copy of my own.

Ideally, what should happen is:

  • remove the entire “manual_z_offset” parameter (just delete that line)
  • save and restart the firmware
  • you should see a notice pop up that says the default offset “3.0mm” is loaded
  • Run a calibrations print and babystep down to your desired z-offset for the first layer
  • Select the “save_z_offset” button from the settings, via the print screen.

This should now create and populate the manual_z_offset line in your variables (you can open the variables file to confirm it is there, and correct) and that should now be the new value, when you save and restart.

If you don’t want to go the full-delete route, you can also simply type the manual z value into the variables file and set it to a ridiculously safe height (3.0mm, for example) and then move it down/save it as described above.

15

Thanks for the response, I did delete the manual_z_offset line and started a calibration print, it does not behave like expected. After fine tuning the z-value I used save_z_offset and the offset was saved within the specific head (z_offset_t1) not the manual_z_offset. This is my new variables.cfg (The new z offset was 2.8000…)

manual_z_offset = 3.0
t1_x_offset = -0.07500000000001705
t1_y_offset = -0.4350000000000023
z_offset_t0 = 3.0
z_offset_t1 = 2.8000000000000007

Also I am having a issue with layer shifting, it looks like after the first layer is printed the second layer schifts (hearing a mechanical noise). I replaced all the Orga G-Code from the github.

What OrcaSlicer Version are you guys using?

16

I was unable to reproduce your z-offset issue. I have tested my configuration and the z-offset function works as intended. To test I:

  • Deleted the manual line from the variables file (saved and restarted)
  • Observed that the 3mm default was loaded upon restart
  • Observed the 3mm defaults were loaded upon print start
  • Manually adjusted the z offset down to my desired z-height
  • Selected the “save_z_offset” button located on the print settings menu
  • Confirmed that this populated the manual_z_offset field in the variables
  • Saved and restarted the printer to ensrure that the manual offset was the one that was loaded upon startup and upon print start.

Be extra sure that you are using the KlipperScreen “save_z_offset” button that is available during a print via the print screen “Settings” menu. (I.e. select “Settings” and click the button while a print is in progress.)

If you can provide a detailed workflow for me to reproduce your issue, I can troubleshoot further (or may be able to change something to negate the problem entirely.)
_____________________

For your mechanical noise and layer shifting, be sure to adjust acceleration down to 4000 (or less.) Though it is impossible for me tell, based on your description, this was a problem I identified during my initial testing. Natively, the acceleration is set to something like 6000, which is far too high for that heavy, y-gantry, particularly if you are using stealthchopper. That little, single motor just can’t compensate for the weight of the gantry when stealthchopper is throttling the power.

Ultimately, you may need to disable stealthchopper (that is, enable spreadcycle) for the y-axis. I implemented tmc autotune for my printer, setting everything to “performance,” as a compromise between the full spreadcycle and the full stealthchopper, and that has been working very well with the Orca parameters below. (To answer your last question, I am using the most current SnOrca release…2.3.1, I believe.)

image
image516Ă—527 19.7 KB

Thanks for helping test this stuff out! Let me know if you notice anything else. I have identified that, during dual-head printing, the part-cooling fan for the parked printhead remains at whatever the last print setting was, rather than shutting off. I think I have a solution devised, but I have not had a chance to fully test it and release it, yet.

Good luck!

17

Thanks also to @FranckFG and EvilAzrael you are doing an amazing job!

As an FYI for everyone who installed Klipper this part is also very important to consider (Optimisation of Klipper) created by @FranckFG : J1s-Klipper-Macros/Armbian_Optimisations_EN.md at main · FranckFG62/J1s-Klipper-Macros · GitHub

Helps to keep the internal emmc longer alive.

18

Updating the Acceleration helped with the issue of the layer shift and the mechanical noise. Within the default profile of OrcaSlicer the Acceleration is set to high. So it is mandatory to modify it. I checked the Settings of SnapmakerOrca and used those (But most likely those are also to high, so it needs more testing):

image
image375Ă—606 31.4 KB

19

Hello Snapidxuser. The acceleration and speed values ​​of the default profile for the J1 are far too high for the mechanics. You have a “test_speed” macro that allows you to see the limits of your machine. Personally, I’m at a maximum of 3500 for acceleration and 300 mm/s for travel speed, and well below that for printing speeds.

Be aware that I’ve noticed that the acceleration values ​​defined in “Printer settings” can be overridden by the default profile. I therefore advise you to force these parameters in the “Process” settings.

Thanks for your feedback; it made me realize that I don’t mention this acceleration problem in my readme. However, I had encountered the same problem, lol.

20

@DeSkwared as an FYI when you blindly copy paste your github content on to the printer you will be greeted with the error below (in case other new user gonna facing the same issue). The Solution is just to delete the file: hardware/autotune_tmc.cfg. The error message is a little misleading :wink:

image
image811Ă—377 15.2 KB