Twotrees SK1 Z-probe failure

General Discussion
1

Basic Information:

Printer Model: Twotrees SK1
MCU / Printerboard: Twotrees proprietary (very similar to Makerbase SKR PI), STM32F401 on the main board, and RP2040 on the toolhead
Host / SBC: Twotrees proprietary (very similar to Makerbase SKI PI)
klippy.log attached
klippy.log (141.9 KB)

Describe your issue:

When homing, Z-probe does not trigger, and toolhead hits the plate. Even though sensor itself clearly triggers (a LED lights up when sensor is close to a metal), the QUERY_PROBE command still reports z probe is open.

Everything was working fine for the recent few weeks. Printer suddenly stopped printing, and after reboot it no longer can home on Z axis. There were no recent configuration changes (most of them are even factory).

The print head features a quite rare sensor, named PuXey LT-04N. I tested the sensor separately, and it seems to work - the signal line gets low when metal is near the sensor (though it looks a bit like a low duty cycle PWM - it is low most of the time, but there are 1ms pulses every 100ms)

It is not really clear whether this is a HW or SW issue. Can someone suggest a test? This particular toolhead had issues previously, but after a patch it worked normally for about a month.

2

Well, if:

  • it worked before
  • you did not change config
  • you did not update the software components

then it is quite likely that it is a failing hardware or issue with the wiring.

AFAIK, an inductive sensor should stay triggered as long as it detects something.

3

I am pretty sure it is. But I cannot understand where exactly.

I tried to flash Micropython to the toolhead’s microcontroller to see whether it sees the value change on the pin, and it seems to work fine. Now I would like to understand why Klipper does not see it.

Is there a way to log communication with the toolhead and see what the toolhead’s reply on probe query command?

4

No, you would need to hook up an oscilloscope or just a digital multimeter.

Basically these are just switches. Depending on the type, either:

  • Signal line is pulled up to high (3.3V)
  • Signal line is pulled to GND (0V)

During the sensor is detecting something the switch state needs to be stable.

5

This indeed was a hardware problem - the toolhead contains a MCU board with 24V->5V DC-DC. It is a known problem that main board and toolhead board use poor quality solder that tend to break on a little force or vibration. Perhaps this was a reason why 5V became 4V, and the sensor simply did not work as expected. I soldered everything around the DC-DC and the issue has gone.

2 Likes
6

I had this happen. Upon inspection - I found the THR board was failing at multiple contact points. The surface mounts were barely being held on by the metal side locks - and the solder points were no longer soldered. I resodlered and this solved the issue. I have requested a new board.
Int he meantime I am going to go to mainline klipper and armbian to have more control. Their printer.cfg is such a mess - it has no error checks - uses values that are not current and other problems. That is why the macro for leveling continues on even after failure. It snapped my nozzle completely off, gouged out the bed, and ripped the cover off the extruder. All because they are using defaults not probed values - and there is no catch in the nest of if/then statements to detect an error state.