Issue with SB2209 – Z Endstop Triggered Error During Print Start

General Discussion
1

Basic Information:

Printer Model: Voron 2.4
MCU / Printerboard: Octo 1.0.1 / SB2209 RP2040
Host / SBC BTT Pi
klippy.log

logs-20260522-111616.zip (452.1 KB)

issue:

I recently had to perform maintenance on my extruder. After reassembling everything, I encountered an issue with my SB2209 board when trying to start a print: I received a Z endstop error.

I checked the status in Mainsail and noticed that the TAP signal was not responding, even though the LED on the board was changing color. Both the Z endstop and probe were constantly showing as “Triggered”, regardless of any interaction.

I verified the jumper configuration, but the behavior did not change — it remained permanently triggered.

Since I had a spare SB2209 board, I decided to flash it and install it. On the first power-up, I performed all the tests, and everything seemed to work correctly:

  • The endstop status showed as “Open”, as expected.

  • When manually activating the TAP, it switched to “Triggered” and then back to “Open”, behaving normally.

Before starting a print, I performed a warm-up to typical operating temperatures. Everything continued to function correctly for several minutes.

However, when I started a print, the printer heated up, successfully completed QGL (Quad Gantry Leveling), but during the bed mesh process, I encountered the same Z endstop error again.

At this point, I am experiencing the same issue on two different SB2209 boards. Both boards have previously worked without any problems, which likely rules out any misconfiguration in my printer.cfg.

2

Hello @Danmr and welcome to the forum!

What probe do you use?
After reassembling, is the probe in the correct distance to the bed?

So do you use the probe or the endstop?

3

It’s an OptoTap (link) sensor. Both the probe and the Z endstop always report the same state — either “open” or “triggered” at the same time. I’m not entirely sure which one is actually being used by the system

Could all of this be caused by a CAN bus issue?

Just to add more context: the machine has already completely cooled down since the issue first appeared, and even after restarting, the error did not go away — it’s still stuck as “triggered” in Mainsail. I tried to attach a screenshot, but it seems I can’t yet since I’m new here.

4

Sounds like a floating pin. Try a pullup resistor.

pin = ^EBBCan:gpio6
5

I tried enabling the pull-up configuration, but it didn’t change anything.
Also, I noticed something odd — the X endstop occasionally shows as triggered in Mainsail, even though there’s no interaction with it.

6

I’d suspect you’ve plugged the optical switch into the wrong spot OR the switch was damaged during handling.

GPIO6 has a PNP/NPN jumper which makes me wonder if the software pullup is enabled.

1030000161-EBBSB2209USBEN25
1030000161-EBBSB2209USBEN251000×1250 168 KB

Use a DVM and measure the voltage on the toolhead board pin gpio6. If it doesn’t change when the pin is triggered then test at the switch. I’m guessing the signal wire is broken or shorted.

7

In my first assembly, I actually connected the TAP to the X endstop port and vice versa, but I corrected that mistake afterward.

When I installed the second board (which was completely new), I paid extra attention to avoid making the same mistake again. Unfortunately, I still ended up with the same issue — the Z endstop is stuck as triggered.

At the moment, I don’t have a multimeter to perform the measurements you described, but I’ll try to get one so I can run those tests and provide more accurate diagnostics.

8

Make sure the jumpers in the green circle match the voltage mode switch on the optical switch board. Should be okay if the leds are switching but double check anyway.

image
image1485×822 158 KB

Add or remove jumper in the red circle to enable hardware pill up.

How is the wire routing to the switch board? Any chance of a crushed wire or bad crimp?

9

Regarding the pull-up: does it only work if the NPN jumper is removed?

The wiring and crimps are fine — I double-checked them already.

Also, the part you highlighted in green is actually the PWM fan voltage selector, according to the Voron build guide. I’m not using that function, but in any case, it is currently set to the 24V position. I’m not sure if that is relevant here, but I left it as it came from the pre-assembled kit, and it was working before.

When I installed the new board, I made sure to replicate all the jumper positions exactly as they were on the previous one.

10

The green jumpers select the the volts to the 3 pin connector. In fan mode GPIO6 is PWM to ground, in inductive mode GPIO6 is a sensor pin.

I assume the jumper pulls the sense pin high… I don’t have a board or a schematic so I’m only guessing, but it should be save to test in both modes.

11

I just noticed there is another jumper to switch the 3 pin connector from “fan” to “ind”, Blue box in image below.

image
image1354×1191 167 KB

12

Indeed, there is a jumper here and it is set correctly.

image
image747×1600 230 KB

13

As I mentioned at the beginning, I have two boards showing the issue. After spending several days trying to find the problem, I noticed that on one of the boards the trigger issue is consistent — it always stays in the “triggered” state. On the newer board, however, the issue only starts during bed leveling. I’m not sure if it’s related to some peripheral or something else.

I ended up leaving everything off for a few days so I wouldn’t keep going in circles. Today I decided to try starting a print without the motor connected, just to see if anything changes.

At this point, it’s been about 30 minutes since I started the print, and around 20 minutes since the leveling finished. Obviously, it’s running without filament, but I’ve been repeatedly running QUERY_ENDSTOPS and so far there are no signs of the issue occurring.

I’m going to let it run for a few more hours, hoping the EBB temperature increases, so I can try to correlate the problem with higher temperature on the SB2209.

image
image1248×581 48.3 KB

14

Well, as I mentioned in my update yesterday, I tested “printing” without connecting the extruder motor to the board. The program ran from start to finish without any kind of interruption, and the endstop states were always behaving correctly.

At the moment, I’m limited in the tests I can perform since I still don’t have a multimeter or any other electronic measuring tool, so I’m trying to work empirically to identify at which point the failure starts.

Today I moved one step further in the testing: I connected the extruder driver to see if anything would change when it was powered. I started a print (without filament), and everything began normally — QGL and bed leveling both completed successfully.

Right after that, I went to the console and ran QUERY_ENDSTOPS, and Klipper shut down with the error:
“Unable to obtain ‘endstop_state’ response”

I’m not sure if this was caused by timing or overload from communication, but I’m attaching the log for reference klippy.log (977.7 KB). Essentially, it was the same procedure as the previous test.

image
image529×425 20.8 KB

To validate this further, I started the test again. It was only possible because after restarting the firmware the endstop states returned to normal. This time, I avoided querying the endstops until the print had actually started. Everything began correctly, and after about one minute I requested the endstop state — the printer responded and everything looked fine. However, shortly after that, the printer stopped due to a GSTAT error on the extruder driver.

Once again, the failure happened when I tried to interact with the printer. I’m attaching the log from this attempt ( klippy #understat.log (1.7 MB)).

To be sure it wasn’t related to communication attempts, I ran a third test without sending any commands at all — just letting it run. After a few minutes, the printer stopped again, this time also due to a GSTAT error.

At this point, this is a very different error from what I was seeing when I first opened this topic.

15

When looking at your GSTAT reports in your klippy.log

Line 3272: TMC ‘stepper_z’ reports GSTAT: 00000001 reset=1(Reset)
Line 3273: TMC ‘stepper_z1’ reports GSTAT: 00000001 reset=1(Reset)
Line 3274: TMC ‘stepper_z2’ reports GSTAT: 00000001 reset=1(Reset)
Line 3275: TMC ‘stepper_z3’ reports GSTAT: 00000001 reset=1(Reset)
Line 3276: TMC ‘stepper_z’ reports GSTAT: 00000000
Line 3277: TMC ‘stepper_z1’ reports GSTAT: 00000000
Line 3278: TMC ‘stepper_z2’ reports GSTAT: 00000000
Line 3279: TMC ‘stepper_z3’ reports GSTAT: 00000000
Line 3281: TMC ‘stepper_x’ reports GSTAT: 0000001d reset=1(Reset) uv_cp=1(Undervoltage!) register_reset=1 vm_uvlo=1
Line 3282: TMC ‘stepper_y’ reports GSTAT: 0000001d reset=1(Reset) uv_cp=1(Undervoltage!) register_reset=1 vm_uvlo=1
Line 3283: TMC ‘stepper_x’ reports GSTAT: 00000000
Line 3284: TMC ‘stepper_y’ reports GSTAT: 00000000
Line 3862: TMC ‘extruder’ reports GSTAT: 00000001 reset=1(Reset)
Line 3863: TMC ‘extruder’ reports GSTAT: 00000000
Line 7821: TMC ‘extruder’ reports GSTAT: 00000002 drv_err=1(ErrorShutdown!)
Line 7822: TMC ‘extruder’ reports GSTAT: 00000000
Line 7895: TMC ‘extruder’ reports GSTAT: 00000002 drv_err=1(ErrorShutdown!)
Line 7896: Transition to shutdown state: TMC ‘extruder’ reports error: GSTAT: 00000002 drv_err=1(ErrorShutdown!)

all drivers produced at least once a GSTAT report. So it is not a specific driver gone bad.

There are undervoltage reports. Could it be your power supply or wiring?

Since the GSTAT reports start after about 1.5 hours after turning on your printer, I would start checking the power supply.

16

That’s interesting, because this error does not occur when I run a “print” without the extruder connected.

17

I was referring to

Those show similar behaviour

When you say

Which klippy.log are you referring to?

18

This log contains the GSTAT error,klippy #understat.log, This was during a simulation with the extruder driver connected and with an additional ground wire from the motor case to a spare hole on the TAP structure.

Unfortunately, I didn’t save the log from the simulation where I ran it without the motor connected.

As an update: I tried connecting the motor again without adding any extra grounding. This time, I ended up using the motor from the CW2 instead of the new one that came with the Galileo kit. I know I didn’t follow the best practice of changing only one variable at a time, but for some reason everything has been working fine so far — I’ve already completed three prints of about 5 hours each without issues.

I’m not ready to consider this resolved yet, as I still need to test if the issue comes back when using the motor that came with the kit, and I also need to figure out what went wrong with the other SB2209.

19

Did you check your power supply? Check your 24V when everything is connected, if possible with a scope.

Don’t confuse yourself. You had a working system before you performed maintenance on your extruder.