Forked for Creality K1

[ballaswag]

Just want to shared that I forked (stole) your good work and adapted this for the Creality K1 (https://github.com/ballaswag/creality_k1_klipper_mod). I have made a few changes and let me know if you guys like some of these back ported:

1. Bump buildroot to 2024.02.2 (newest LTS).
2. Added python-matplotlib for Guppy Screen to draw those shaper graphs
3. Reconfigured and added some Guppy Screen klippy extras/macros/python scripts to support shaper/belt tension graphs.
4. Added a mdev script to create permanent ttyACM device names in /dev/serial/by-id (Not sure if my hacked scripts is passable, but names based on discovered manufactor, product, serial and interface).

[consp]

2. Added python-matplotlib for Guppy Screen to draw those shaper graphs

How's the memory usage going? That's the main concern. Definitely going to steal that one back to get guppyscreen fully working if it's not too much.

[xblax]

Great that it turns out to be adaptable for other printers. We will definitely keep an eye on that!

Bump buildroot to 2024.02.2 (newest LTS).

We could probably do that as well, but there wasn't much need for it yet. I also think it ships newer python version, that wasn't tested that much with Klipper.

[ballaswag]

2. Added python-matplotlib for Guppy Screen to draw those shaper graphs

How's the memory usage going? That's the main concern. Definitely going to steal that one back to get guppyscreen fully working if it's not too much.

Matplotlib shouldn't impact printing, since it's only imported and used when plotting shaper/belt tension graphs. I have ran these once per axis, and it works (graph and all). Will report if I see any failed shaper runs due to memory constraint.

Great that it turns out to be adaptable for other printers. We will definitely keep an eye on that!

Bump buildroot to 2024.02.2 (newest LTS).

We could probably do that as well, but there wasn't much need for it yet. I also think it ships newer python version, that wasn't tested that much with Klipper.

Buildroot 2024.02.2 installs python 3.11.8 which was what I saw on the 2023.02.x build as well.

On a tangent, how many load cells do the flashforge has and where are they installed? I was looking through issues/discussion and discovered its auto bed leveling is implemented with load cell. The probe I assume is also trigger by the load cell? I saw that the load cell values are exposed as a temperature. Are these temp values used in anyway on implementing the probe? Want to pick your brains before I dig into their klipper.

The reason I asked is that the K1 has 4 load cells under the bed which it uses to probe/z-endstop. However, its implementation is either old and closed sources. Want to see if the flashforge can be used as a reference.

There have been a lot of attempts at mainlining these hx71x sensors with load cell into klipper, but a lot of these PRs are either abandoned or pending long reviews. If flashforge implementation can be used as a reference, I might just hack something together for the K1.

[xblax]

Buildroot 2024.02.2 installs python 3.11.8 which was what I saw on the 2023.02.x build as well.

Ah yes, I see they reverted it in buildroot buildroot/buildroot@fb6274f

On a tangent, how many load cells do the flashforge has and where are they installed? I was looking through issues/discussion and discovered its auto bed leveling is implemented with load cell. The probe I assume is also trigger by the load cell? I saw that the load cell values are exposed as a temperature. Are these temp values used in anyway on implementing the probe? Want to pick your brains before I dig into their klipper.

The load cell(s) are be in the bed, I did not check the hardware in detail, probably similar to a kitchen scale. I think the exposed value as temperature is only for debugging and to check calibration level. The probe itself is just triggerd via GPIO - I assume they have some external circuit to trigger that MCU input on a certain threshold.

[probe]
pin: !PB4
speed: 2
lift_speed: 5
samples: 1

[ballaswag]

The load cell(s) are be in the bed, I did not check the hardware in detail, probably similar to a kitchen scale. I think the exposed value as temperature is only for debugging and to check calibration level. The probe itself is just triggerd via GPIO - I assume they have some external circuit to trigger that MCU input on a certain threshold.

[probe]

pin: !PB4

speed: 2

lift_speed: 5

samples: 1

Is their firmware binary rebuild able and flashable given their released klipper source code? I'm wondering if they are hiding or forgot part of that leveling trigger code.

It's also interesting that they have a separate PIN for the z-endstop instead of using the probe's virtual endstop pin that's defined when a probe section is configured.

This external circuit is not running on the mcu? If so they definitely are lacking those source code. Especially the code that determines when to pull high or low based on the samples.

Each of these PIN, probe and z-endstop as is should create a MCU_endstop pin object from my reading of the klipper code. So their custom circuit must pull high or low for both of these pin based some samples from the load cells.

Are they claiming that even they are already piping these samples back to the klipper host. They still decide to build and code up another custom circuit that does sampling and triggering in parallel (not using any of the existing klipper low level communications and triggers)? I'm not versed in circuits at all. Is this separate independent circuit simpler to build and operate than doing the endstop logic in klipper?

[consp]

Is their firmware binary rebuild able and flashable given their released klipper source code?

No, they "forgot" to include the Makefile which obviously contains some specific configuration for the clone chip as it won't budge when compiled with the standard sdk+klipper source.