Y-Endstop not triggering despite proof of functionality

General Discussion
1

Basic Information:

Printer Model: Ender 3 V2 4.2.2
MCU / Printerboard: Raspberry Pi Zero 2 W
Host / SBC (sorry I don’t quite know what this is)
klippy.log (unfortunately there is no klippy.log as i have just updated my system in hope of it fixing the issue, and for some reason it deleted all the log files?)

Describe your issue:

I’ve run into the problem of my bed on my ender 3 v2 4.2.2 crashing the bed into the y=0, making an alarming sound of the motorrattling. checked the endstops using:

16:43:51 $ query_endstops
16:43:51 x:open y:open z:TRIGGERED

Also I’ve just noticed but possible that it wasn’t any different before this problem occured: when starting the printer, it shows that the BLTouch didnt verify:

16:43:36 // Failed to verify BLTouch probe is raised; retrying.
16:43:38 // Failed to verify BLTouch probe is raised; retrying.
16:43:40 // Klipper state: Ready

BLTouch always worked fine. no clue if that error message also showed up despite working a week ago.

I’ve just now encountered this problem after months of perfect functionality. didn’t change/update a thing. multimetered the wiring, the endstop switch and all works fine. checked the connections on the motherboard, everything sitting secure. yet no triggering of the y-endstop happening, it is in a constant “open” position, causing my bed to crash into y=0. Any idea? i didn’t update anything, it just malfunctioned from one print to the next.

my y-stepper config (always was pin ^PA6. deleting the pullup (^) doesnt fix it. neither does adding an exclamation mark (!)):

[stepper_y]
step_pin: PB8
dir_pin: PB7
enable_pin: !PC3
microsteps: 16
rotation_distance: 40
endstop_pin: ^PA6
position_endstop: 0
position_max: 230
position_min: 0
homing_speed: 50

I also tried switching the pins on the motherboard to the ones from the z-endstop that are free due to the BLTouch being in use. remembered to change to the ^PA7 pin in the config, just as it is documented on the ender 3 v2 config reference and just as it used to work with my z-endstop before buying a BLTouch.

HELP! nothing works and I now own an 8 kg paper weight.

2

See Verify endstops.

If the endstop suddenly stopped working and IF you changed nothing then you have 3 possible scenarios:

  1. Defect in wiring
  2. Defect microswitch
  3. Defect pin on the board
4

I have verified endstops using QUERY_ENDSTOPS. the y-endstop shows open, whether it is being pressed or not. the switch and wiring was tested using my multimeter. nothing was changed in the config or anywhere. it printed, then i wanted to start the next print, and y-carriage rammed into y=0.

considering i have changed the pins to the z-endstop on my motherboard, including the necessary config change, wouldn’t it be a huge coincidence that both the y-endstop pins AND the z-endstop pins both stopped working at the same time?

nonetheless, you suggest getting a new board then?

5

This sounds very much like a wiring issue.

When you tested with a meter, where did you test and how?

Think about the wiring run, when you tested this, was the cable in the same position it would be when triggered? - intermittent wire breaks are not uncommon on moving cables.

P.S - don’t forget to restore your config back to ^PA6

6

What you could try is shortening the two pins of your endstop connector on the board directly (DuPont cable, screwdriver whatever) and see if Klipper reacts. Of course, using the pin you actually have configured

8

i tested both cables running from the pins on my motherboard to the endstop switch. both cables showed to run current.
i also tested the endstop switch on the pins S and G, showing no trigger upon not pressing the endstop and showing a trigger upon triggering the switch.
the y-endstop cable should not be moving anyways as it is fixed to the y=0.

9

thanks for the help sineos.
I tried shorting the pin ^PA6 with jumper cables and no change to the query_endstop.
what is even weirder is teh following:

i changed the x-endstop pin to ^PA6 in the config and the y-endstop pin to ^PA5 (so i switched them in the config). i then manually triggered the switch on the x-axis which is now wired to the y-endstop pin ^PA6, so it should show the y-endstop to be triggered when manually done so. however query_endstop still showed the x-axis to be triggered and y-endstop to be open. when i let the x-endstop (wired to the y-endstop pin) go, query_endstop showed the x-endstop to be open and y-endstop to be open. so it shows the same result as if i didnt change a thing in the config file. this makes absolutely no sense anymore.

the problem can’t be the board then as ^PA5 (x-endstop) works. ^PA6 (y-endstop) always shows open. z-endstop isn’t needed due to virtual_z_ednstop of the BLTouch. the weird part is that changing the config for the x-endstop to be on ^PA6 (y-endstop pin) and manually triggering ^PA5 (usual x-endstop pin), the x-endstop shows to trigger/open. this must be software? why is klipper not accepting my changes in the config? i did save and restart klipper properly.

10

Your board is neither something special (on the contrary) nor are any issues known with respect to such “trivial” functionality like endstops. If there was a systematic issue, you could be quite sure that this place is like exploding with reports.

So, while it is not full clear what is going on, I’m pretty sure that is an effect local to your setup.

It is correct that for a Creality 4.2.2 board the endstops are: ^PA5, ^PA6, ^PA7 for X, Y and Z.
Note that the X, Y, Z designators are arbitrary, this means you can connect your X endstop to the Z-connector as long as you configure the correct pin in the printer.cfg.

To systematically diagnose the issue, I would configure:

[stepper_x]
...
endstop_pin: ^PA5

[stepper_y]
...
endstop_pin: ^PA6

[stepper_z]
...
endstop_pin: ^PA7

and then close the pins directly on the board, one by one, and check with QUERY_ENDSTOPS if and how they react.

The current configuration with which Klipper is working is always recorded in the klippy.log upon each restart. The entries at the bottom of the log are the most recent ones. So check the log to validate, if it reflects the configuration you are targeting.

11

To systematically diagnose the issue, I would configure:

I configured it that way and QUERY_ENDSTOPS results in:

x:TRIGGERED y:open z:TRIGGERED

when all switches are being manually manipulated. if all of them are left alone:

x:open y:open z:open

As previously mentioned, changing the y-endstop pin in the config from ^PA6 to ^PA5 and physically keeping the connection on the board as intended by default (x: ^PA5; y: ^PA6; z: ^PA7) should result in a “TRIGGER” for the y-axis when the x-endstop switch is being manually triggered (agree?).

however when manually triggering the x-endstop switch (configured to function as the y-endstop) my printer still shows the following:

x:TRIGGERED y:open z:TRIGGERED

oh and on a completely other note, i just realized that both nozzle and heatbed constantly show 70°C. when trying to heat up in order to cold pull some leftover filament i had loaded from my last print, klipper shuts down due to unexpected heating.

I have just reinstalled everything by SD card, which unfortunately didn’t solve my issues.

12

Are you sure you flashed the board with the correct settings?

You also may take in consideration that the board is broken.

13

I flashed it with the same file i used previously. it worked before. fluiddpi-rpi-lite-v1.19.0. On the official github it is recommended to use kiauh to install fluidd, yet both were tried and both yielded the same result.

After installing and entering fluidd via http://fluiddpi.local, i setup the printer.cfg by copying the example for the ender 3 v2. additionally, i tried by using an old printer.cfg file i had as a backup from when everything worked.

I’m now leaning more and more towards the possibility that the board just broke randomly. however, buying a new board just to realize that wasn’t the problem should remain my last option.

I used this ender 3 v2 for some months with klipper without problems. i just ordered a bambu lab a1 to replace my ender 3 v2 as i am too frustrated to constantly having to fix things. i still want to fix my ender in order to take it to our vacation home in a month, so i’d love to be able to fix it until then…

14

I’m not sure, that I understand what you are reporting, but to reiterate from above:

  • The X, Y, Z labeling on you board does not have any practical meaning
  • You have 3 endstop pins ^PA5, ^PA6, ^PA7 associated with their respective connectors on the board.
  • If you plug your X-cable into the Z-connector and configure your X-endstop to use PA7 will work the same as when you follow the labeling on the board

Overall, this seems to me that the board has one or multiple defects. One seems quite confirmed, as apparently the endstop works as expected, except for Y.

15

I understand this point, it makes sense.

oh, so it should. but when actually plugging the x-cable into the z-connector on the board and reconfiguring the config for the z-connector to be the new x-endstop, QUERY_ENDSTOP after a manual trigger of the x-switch wired to the x-cable plugged into the z-connector (acting as a z-endstop) shows as following:

x:TRIGGERED y:open z:open

so, despite having it configured and plugged in as a z-enstop, it triggers the x-endstop. this works when nothing is plugged into the x-connector on the board and when the pins of the x-connector are shorted using a jumper cable.

if this doesn’t make any sense to you, it doesn’t to me, either.
if nobody has any more ideas what could be happening, i guess i’ll start looking around for a new board.

16

I’m still not sure that I follow you.
If you configure:

[stepper_x]
...
endstop_pin: ^PA7 # <------------ Pin labeled ON THE BOARD as Z

then you have associated the pin PA7 with your X-Stepper and a result like:

is expected and correct. Again, Klipper (or Marlin or RRF) does not care about how a pin is labeled on the board. It only cares about the pin number, e.g. PA7, and how it is defined in the respective configuration.