This branch only supports 1 sensor. The K1 series has 4 sensors. I’m actually shocked it worked and you didn’t crash the machine! I’d refrain from using this on the K1 series until we decide what to do about those 4 sensors.
But good to know it’s no longer crashing with a load of “timer too close” errors. Perhaps the mcu clock has been fixed?
I’m never seen messages about timer too close…
I’m solder all 4 sensors to one hx711.
And i’m did some tests - printer shutdown if i’m set 170 or more temp for extruder - if 160 - printer working 
- what this?)) And this only occur after bed mesh calibration and smart_park from KAMP. if heating nozzle without bed mesh and smart_park - all good - printer working… maybe problem in activate_gcode? or my config?
[load_cell_probe]
sensor_type: hx711
dout_pin: leveling_mcu:PA0
sclk_pin: leveling_mcu:PA2
z_offset: -0.1
counts_per_gram: 28.09438
reference_tare_counts: -32570
safety_limit: 5000
trigger_force: 160
trigger_count: 1
speed: 2
lift_speed: 5.0
pullback_dist: 0.5
pullback_speed: 0.2
pullback_extra_time: 0.3
settling_time: 0.5
activate_gcode:
{% set PROBE_TEMP = 150 %}
{% set MAX_TEMP = PROBE_TEMP + 5 %}
{% set ACTUAL_TEMP = printer.extruder.temperature %}
{% set TARGET_TEMP = printer.extruder.target %}
{% if TARGET_TEMP > PROBE_TEMP %}
{ action_respond_info('Extruder temperature target of %.1fC is too high, lowering to %.1fC' % (TARGET_TEMP, PROBE_TEMP)) }
M109 S{ PROBE_TEMP }
{% else %}
# Temperature target is already low enough, but nozzle may still be too hot.
{% if ACTUAL_TEMP > MAX_TEMP %}
{ action_respond_info('Extruder temperature %.1fC is still too high, waiting until below %.1fC' % (ACTUAL_TEMP, MAX_TEMP)) }
TEMPERATURE_WAIT SENSOR=extruder MAXIMUM={ MAX_TEMP }
{% endif %}
{% endif %}
Can you DM me the log file with the error? My guess is the crash about the JSON encoder is something to do with the Python version. I’m not sure about 170 degrees thing.
Looks like you override quite a bit of stuff in the config. The
pullback_speed has a direct impact on accuracy and is automatically set based on the sensor sample rate. You’ve made it faster which will hurt accuracy/repeatability.
You also made pullback_dist 5x the normal distance, I assume this is because the probe overshoots badly at 2mm/s and trigger_force of 160g.
To get equivalent speeds to Prusa’s machine you’d have to divide them by 4 because the sensor is 4x slower. E.g. probing at 2mm/s is the equivalent of probing at 8mm/s on the faster sensor. Pullback speed on the faster sensor is 0.32mm/s, but on this sensor it should be 0.08mm/s. If all that sounds really slow, blame Creality for the sensors.
Ideally you would also install SciPy and get the continuous tearing functionality to work. But I hear that on Creality’s “customized” linux distro this doesn’t install.
This is a Klipper bug. Needed on line 272 in the file klipper/klippy
/webhooks.py replace
jmsg = json.dumps(data, separators=(‘,’, ‘:’))
on
jmsg = json.dumps(data, separators=(‘,’, ‘:’), default=str)
very thanks man - im test this and reply.
That would mean that one of the data types being serialised isn’t a basic Python type. Sounds like a coding error on my part. I’ll have to investigate further.
I thought I saw this with Boolean values not being serialised by Python 2.7, but I can’t exactly remember.
yes - i’m think this is related to load cell code - beacuse with bl touch - no problems…
and - i’m not author for this config - i’m did copy past from k1 tenso_mod project from github.
But i’m can say that i’m have very good results without any problems - if nozzle clean - no problems with first layer - if I ever have problems with accuracy I will try to do what you advise thank you.
Strange but i’m cant edit with web interface z offset -
SAVE_CONFIG section ‘load_cell_probe’ option ‘z_offset’ conflicts with included value
YES this fix problems - very thanks!!