New 3D Printer User Seeking Help

[3dCase]

Thanks for the responses. I didn't realise the pins would pop out, so will give that a go. Some of the connections, although working, could do with being recrimped and remade, so the crimper wont go to waste.

I haven't had a chance to redo the jst on the y, but I did change the printer.cfg to match the proper pins, and now it registers as open/triggered, so the switch seems to be working fine. But progress is still stalled a bit. I still can't "home" because x, z and probe are still saying triggered.

I double checked my x settings vs the generic + TMC2209 config from BTT. The endstop still registers as Triggered, but now the x motor actually moves, a little.

This is my current configuration for x:

[stepper_x]
step_pin: PE2
dir_pin: !PB4
enable_pin: !PC11
microsteps: 16
rotation_distance: 40
position_min: 0
position_max: 500
position_endstop: 0
endstop_pin: tmc2209_stepper_x:virtual_endstop

[tmc2209 stepper_x]
uart_pin: PC10
diag_pin: PF3
run_current: 1.2
hold_current: 0.7
sense_resistor: 0.110
stealthchop_threshold: 0
driver_SGTHRS: 70

When I press home I get 2 seconds of tool head juddering along x (maybe moving 3mm), and receive the following error:
G28
Endstop stepper_x still triggered after retract.

So I tried DUMP_TMC STEPPER=stepper_x, to see what it came up with:

23:15// SG_RESULT:  00000018 sg_result=24
23:15// PWM_AUTO:   001700ff pwm_ofs_auto=255 pwm_grad_auto=23
23:15// PWM_SCALE:  000d0074 pwm_scale_sum=116 pwm_scale_auto=13
23:15// PWMCONF:    c80d0e24 pwm_ofs=36 pwm_grad=14 pwm_freq=1 pwm_autoscale=1 pwm_autograd=1 pwm_reg=8 pwm_lim=12
23:15// DRV_STATUS: 800c00c0 ola=1(OpenLoad_A!) olb=1(OpenLoad_B!) cs_actual=12 stst=1
23:15// CHOPCONF:   34010053 toff=3 hstrt=5 tbl=2 mres=4(16usteps) intpol=1 dedge=1
23:15// MSCURACT:   011001c3 cur_a=-61 cur_b=-240
23:15// MSCNT:      00000228 mscnt=552
23:15// TSTEP:      000fffff tstep=1048575
23:15// FACTORY_CONF: 0000000e fclktrim=14
23:15// IOIN:       21000041 enn=1 pdn_uart=1 version=0x21
23:15// OTP_READ:   0000000e otp_fclktrim=14
23:15// IFCNT:      00000010 ifcnt=16
23:15// GSTAT:      00000000
23:15// GCONF:      000001c0 pdn_disable=1 mstep_reg_select=1 multistep_filt=1
23:15// ========== Queried registers ==========
23:15// SGTHRS:     000000c8 sgthrs=200
23:15// TPOWERDOWN: 00000014 tpowerdown=20
23:15// COOLCONF:   00000000
23:15// TCOOLTHRS:  00000000
23:15// TPWMTHRS:   000fffff tpwmthrs=1048575
23:15// IHOLD_IRUN: 0008150c ihold=12 irun=21 iholddelay=8
23:15// SLAVECONF:  00000200 senddelay=2
23:15// ========== Write-only registers ==========
23:15DUMP_TMC STEPPER=stepper_x

In case there was a resistance problem with the toolhead/belt/etc, I plugged it into a 5th motor that the previous user had seemingly just attached to the back of the gantry, that has a plastic battarang glued to the end of the motor spindle (Why?) It seems to be spare as there was no wire for it. So, yeah, I plugged the x cable into it and ran the home test. It rotates about 33 degrees, before coming up this error:

23:20// SG_RESULT:  00000028 sg_result=40
23:20// PWM_AUTO:   001a0024 pwm_ofs_auto=36 pwm_grad_auto=26
23:20// PWM_SCALE:  0031003f pwm_scale_sum=63 pwm_scale_auto=49
23:20// PWMCONF:    c80d0e24 pwm_ofs=36 pwm_grad=14 pwm_freq=1 pwm_autoscale=1 pwm_autograd=1 pwm_reg=8 pwm_lim=12
23:20// DRV_STATUS: 800c00c0 ola=1(OpenLoad_A!) olb=1(OpenLoad_B!) cs_actual=12 stst=1
23:20// CHOPCONF:   34010053 toff=3 hstrt=5 tbl=2 mres=4(16usteps) intpol=1 dedge=1
23:20// MSCURACT:   00ef003c cur_a=60 cur_b=
23923:20// MSCNT:      00000028 mscnt=40
23:20// TSTEP:      000fffff tstep=1048575
23:20// FACTORY_CONF: 0000000e fclktrim=14
23:20// IOIN:       21000041 enn=1 pdn_uart=1 version=0x21
23:20// OTP_READ:   0000000e otp_fclktrim=14
23:20// IFCNT:      00000063 ifcnt=99
23:20// GSTAT:      00000000
23:20// GCONF:      000001c0 pdn_disable=1 mstep_reg_select=1 multistep_filt=1
23:20// ========== Queried registers ==========
23:20// SGTHRS:     0000008c sgthrs=140
23:20// TPOWERDOWN: 00000014 tpowerdown=20
23:20// COOLCONF:   00000000
23:20// TCOOLTHRS:  00000000
23:20// TPWMTHRS:   000fffff tpwmthrs=1048575
23:20// IHOLD_IRUN: 0008150c ihold=12 irun=21 iholddelay=8
23:20// SLAVECONF:  00000200 senddelay=2
23:20// ========== Write-only registers ==========
23:20DUMP_TMC STEPPER=stepper_x

I wasnt sure what that meant, so I had to ask ChatGPT to parse it a bit. It said:
ola=1, olb=1 - Open Load A and Open Load B are both still showing 1, meaning:
- The driver still detects no valid coil connection
- Even with another motor using the same cable

So looking at what others have written about this with the Manta m8P, the motor wiring may be wrong.

Not sure how acurate that is, but I'm going to have a look at the wiring tonight and see.

The M8P 1.1 pinouts for the motors are 2B 2A 1A 1B, but my motors dont seem to have any markings on to ID the pins, but as I understand it they look like the ones supplied by Creality for the CR10 so I will see if I can find a pinout for them. Although I have no clue what the 5th one is/was for.

This stuff feels so heavy for a noob, I just wanted to print something

Again, thanks for all the help.

If you cannot find the colour layout for you motor, there is a simple trick you can do.
Disconnect the motor and rotate with you fingers. While rotating short two pins until you feel the motor resist harder. Those two pins are a coil. Then try with the others and confirm your two coils. Just make sure now you connect the coils to either A+ and - and the other coil to B+ and -. It does not matter if A and B are the wrong way around. If the rotation is wrong you can change that in the cfg or simply swapping one coil + to -
Some motor mfg use other colours so you cannot rely on them to be foolproof. Creality is a weird company and they do not provide much help. They also steal opensource stuff and close it as if it becomes their product and thereafter nobody can use it as intended. Never buy a Creality klipper printer, you will not find help other then from them, and that is a dissaster imho.
With regards to feeling a noob, don’t! You came this far already and suddenly it all falls in its place. You already learned a lot which will be helpful to you in the future.

 

[shiftingtech]

Seems like you haven't really got sensorless setup on X yet. I'd suggest making sure the appropriate diag jumper is installed, and the pullup (^) is enabled in the config.

 

[3dCase]

Seems like you haven't really got sensorless setup on X yet. I'd suggest making sure the appropriate diag jumper is installed, and the pullup (^) is enabled in the config.

I think he hasn’t because it was not the intention. The machine never has worked yet but it came with limitswitches installed, thetefor I would think it would be best to try and get it to work as originally intended before going on to modifying things.
The new owner jumped into the deep end with this second hand printer and personally I think if he got some results first, they would serve as great motivators.

 

[shiftingtech]

I think he hasn’t because it was not the intention. The machine never has worked yet but it came with limitswitches installed, thetefor I would think it would be best to try and get it to work as originally intended before going on to modifying things.

One. it came with *one* limit switch installed.

Unless Ive misunderstood something (always a possibility!), the intention appears to be sensorless x, mechanical switch y.

 

[3dCase]

One. it came with *one* limit switch installed.

Unless Ive misunderstood something (always a possibility!), the intention appears to be sensorless x, mechanical switch y.

Oh really? Just one sensorless, that is weird for me but also a possibility I suppose, although I do not see the logic, it is not my place to question or judge such things.
Maybe the OP can tell us what is the intention he has and we can look at providing correct and non conflicting information!

 

[Rhoobarb2005]

Thanks to all for the asnwers, again. I do appreciate the help.

So, I have made some progress. I am now getting:

EndstopSTEPPER_XOPEN
EndstopSTEPPER_YOPEN
EndstopSTEPPER_ZTRIGGERED
ProbeTRIGGERED

My only concern is it may be false reporting x.

Because x will now move on home, but it hits the end and keeps trying to move for 3 seconds. Then it gives this error:

Unable to read tmc uart 'stepper_y' register IFCNT
Once the underlying issue is corrected, use the
"FIRMWARE_RESTART" command to reset the firmware, reload the
config, and restart the host software.
Printer is shutdown

I have adjusted SGTHRS VALUE from 50 to 200, but it doesnt seem to change anything, unless the sweet spot is really precise.

UART mode jumpers are installed and the DIAG jumpers are installed.

Are you using sensor less homing or an actual limit switch, I can't recall?

If you are using sensor less here is the documentation for it. https://docs.vorondesign.com/tuning/sensorless.html
If not, disregard.

I checked that, but i get down to this bit "In this path, you will need to download some macros dependong on your printer. If you do not have a v0 or a 2.4, you can tweak whichever makes the most sense for you." which is something I have yet to encounter, and I'm suddenly stuck again.

If you cannot find the colour layout for you motor, there is a simple trick you can do.
Disconnect the motor and rotate with you fingers. While rotating short two pins until you feel the motor resist harder. Those two pins are a coil. Then try with the others and confirm your two coils. Just make sure now you connect the coils to either A+ and - and the other coil to B+ and -. It does not matter if A and B are the wrong way around. If the rotation is wrong you can change that in the cfg or simply swapping one coil + to -
Some motor mfg use other colours so you cannot rely on them to be foolproof. Creality is a weird company and they do not provide much help. They also steal opensource stuff and close it as if it becomes their product and thereafter nobody can use it as intended. Never buy a Creality klipper printer, you will not find help other then from them, and that is a dissaster imho.
With regards to feeling a noob, don’t! You came this far already and suddenly it all falls in its place. You already learned a lot which will be helpful to you in the future.

Again, I appreciate it. As x is now moving (if only 1 way), does that still mean the wiring could be wrong?

Seems like you haven't really got sensorless setup on X yet. I'd suggest making sure the appropriate diag jumper is installed, and the pullup (^) is enabled in the config.

I think he hasn’t because it was not the intention. The machine never has worked yet but it came with limitswitches installed, thetefor I would think it would be best to try and get it to work as originally intended before going on to modifying things.
The new owner jumped into the deep end with this second hand printer and personally I think if he got some results first, they would serve as great motivators.

One. it came with *one* limit switch installed.

Unless Ive misunderstood something (always a possibility!), the intention appears to be sensorless x, mechanical switch y.

Oh really? Just one sensorless, that is weird for me but also a possibility I suppose, although I do not see the logic, it is not my place to question or judge such things.
Maybe the OP can tell us what is the intention he has and we can look at providing correct and non conflicting information!

Yes, x does not seem to have a physical endstop or cable on it. Y does.

Z and the probe also are always triggered, but I dont think I can diagnose that until x and y are correct (or can I?).

My up to date printer.cfg below if that helps:

[include mainsail.cfg]

[mcu]
canbus_uuid: e48efe7da441
canbus_interface: can0

[mcu EBBCan]
canbus_uuid: a420eb1fbf59

[virtual_sdcard]
path: /home/biqu/printer_data/gcodes

[printer]
kinematics: cartesian
max_velocity: 300
max_accel: 3000
max_z_velocity: 5
max_z_accel: 100
square_corner_velocity: 5.0

[temperature_sensor MCU]
sensor_type: temperature_mcu

[temperature_sensor SoC]
sensor_type: temperature_host

###################################
# X Stepper
###################################

[stepper_x]
step_pin: PE2
dir_pin: !PB4
enable_pin: !PC11
microsteps: 16
rotation_distance: 40
position_min: 0
position_max: 500  # or whatever your X bed allows
position_endstop: 0
endstop_pin: tmc2209_stepper_x:virtual_endstop
homing_speed: 80
homing_retract_dist: 0

[tmc2209 stepper_x]
uart_pin: PC10
diag_pin: ^PF3     # ✅ Correct DIAG for Motor 1
driver_SGTHRS: 100
run_current: 1.2
hold_current: 0.7
sense_resistor: 0.110
stealthchop_threshold: 0


###################################
# Y Stepper
###################################

[stepper_y]
step_pin: PF12
dir_pin: PF11
microsteps: 16
rotation_distance: 40
endstop_pin: ^PB3
position_min: 0
position_endstop: 0
position_max: 500
homing_speed: 50
homing_retract_dist: 5
homing_positive_dir: false


[tmc2209 stepper_y]
uart_pin: PF13
interpolate: True
run_current: 0.8
hold_current: 0.7
sense_resistor: 0.110
stealthchop_threshold: 0
##diag_pin: PB3
driver_SGTHRS: 255

###################################
# Z Stepper
###################################

[stepper_z]
step_pin: PD7
dir_pin: PD6
enable_pin: !PF10
microsteps: 16
rotation_distance: 40
gear_ratio: 80:16
position_min: -5
position_max: 500
homing_speed: 8
second_homing_speed: 3
homing_retract_dist: 3
endstop_pin: probe:z_virtual_endstop

[tmc2209 stepper_z]
uart_pin: PF9
interpolate: true
run_current: 0.8
hold_current: 0.8
sense_resistor: 0.110
stealthchop_threshold: 0

###################################
# Z1, Z2, Z3 Steppers
###################################

[stepper_z1]
step_pin: PD3
dir_pin: !PD2
enable_pin: !PD5
rotation_distance: 40
gear_ratio: 80:16
microsteps: 16

[tmc2209 stepper_z1]
uart_pin: PD4
interpolate: true
run_current: 0.8
hold_current: 0.8
sense_resistor: 0.110
stealthchop_threshold: 0

[stepper_z2]
step_pin: PC9
dir_pin: PC8
enable_pin: !PD1
rotation_distance: 40
gear_ratio: 80:16
microsteps: 16

[tmc2209 stepper_z2]
uart_pin: PD0
interpolate: true
run_current: 0.8
hold_current: 0.8
sense_resistor: 0.110
stealthchop_threshold: 0

[stepper_z3]
step_pin: PA10
dir_pin: !PD15
enable_pin: !PA15
rotation_distance: 40
gear_ratio: 80:16
microsteps: 16

[tmc2209 stepper_z3]
uart_pin: PF8
interpolate: true
run_current: 0.8
hold_current: 0.8
sense_resistor: 0.110
stealthchop_threshold: 0

###################################
# Extruder (EBB SB2209)
###################################

[extruder]
step_pin: EBBCan:gpio6
dir_pin: EBBCan:gpio7
enable_pin: !EBBCan:gpio8
microsteps: 16
rotation_distance: 22.6789511
gear_ratio: 50:17
nozzle_diameter: 0.400
filament_diameter: 1.75
heater_pin: EBBCan:gpio0
sensor_type: EPCOS 100K B57560G104F
sensor_pin: EBBCan:gpio27
min_temp: 10
max_temp: 270
min_extrude_temp: 170
control: pid
pid_kp: 26.213
pid_ki: 1.304
pid_kd: 131.721

###################################
# Bed Heater
###################################

[heater_bed]
heater_pin: PB7
sensor_type: Generic 3950
sensor_pin: PA0
control: watermark
min_temp: 0
max_temp: 130

###################################
# Probe (Voron Tap)
###################################

[probe]
pin: EBBCan:gpio2
x_offset: 0
y_offset: 0
z_offset: 0
samples: 3
samples_result: median
samples_tolerance: 0.006
samples_tolerance_retries: 3
speed: 5.0

[filament_switch_sensor runout_sensor]
pause_on_runout: true
runout_gcode: PAUSE
switch_pin: EBBCan:gpio10

 

[shiftingtech]

Z and the probe also are always triggered, but I dont think I can diagnose that until x and y are correct (or can I?).

You should be able to. Tap isn't really dependent on any particular toolhead movement. It should be reading open when the toolhead is out in the middle of wherever, and lifting the toolhead by hand should trigger it just as effectively as the actual movement system doing it.

Again, I appreciate it. As x is now moving (if only 1 way), does that still mean the wiring could be wrong?

Generally no. If it moves properly in one direction, the wiring is fine. Are you using the stepper_buzz command to test that?

 

[Rhoobarb2005]

You should be able to. Tap isn't really dependent on any particular toolhead movement. It should be reading open when the toolhead is out in the middle of wherever, and lifting the toolhead by hand should trigger it just as effectively as the actual movement system doing it.



Generally no. If it moves properly in one direction, the wiring is fine. Are you using the stepper_buzz command to test that?

Ah, Ok, unfortunately tap has always been TRIGGERED. I'm guessing it's a cfg issue I haven't got to yet. I was just working my way down the list.

No, if I press Home, it zooms from left to right, hitting the right side, then making a ratcheting noise to try and continue for about 3 seconds. Then bringing the error up.

Last time I just pressed the X button underneath home instead, it did the same, hitting the end and trying to continue, but with no error message. The X button just stayed blue that time.

Had I known all this beforehand...

 

[shiftingtech]

So it sounds to me like you haven't really done anything that *should* cause it to move the other direction. I'd encourage you to use the stepper_buzz command to verify correct operation of the movement axis *before* trying to home.

Configuration checks - Klipper documentation

www.klipper3d.org

As for the x axis movement, remember that when the sensorless sensitivity is turned all the way up (255, where you should be starting) it should barely move at all before triggering.

 

[Rhoobarb2005]

So it sounds to me like you haven't really done anything that *should* cause it to move the other direction. I'd encourage you to use the stepper_buzz command to verify correct operation of the movement axis *before* trying to home.

Configuration checks - Klipper documentation

www.klipper3d.org

As for the x axis movement, remember that when the sensorless sensitivity is turned all the way up (255, where you should be starting) it should barely move at all before triggering.

OK, so x seems to be functioning properly. The value needed was 166. I am not sure why it wasn't affecting anything before, although I did reset some of the other settings I have been tinkering with. It will now go all the way to the right, stop, and then let me adjust the distance + and -.

But yeah, another step done. Thank you so much for the guidance.

Another plus point, I adusted the settings for the SBB2209, back to defaults, with a little tweaking. Now all the stops and the probe are open. Although I dont know if it's a red herring and just saying that, or it actually is working. I did do an endstop test for the Tap, but it didnt change after lifting it a little bit. So not sure A problem for later.

So the next issue is the Y not working.

I tried both the y and z buttons, both said the same thing;

Unable to read tmc uart 'stepper_y' register IFCNT
Unable to read tmc uart 'stepper_z2' register IFCNT

Respectively.

Prety sure the UART pics are prepared properly, but I've been wrong many times on this so far.

Oh, and also when testing the bed and extruder temps by manually setting them to 50 degrees C. They throw up errors too.

That is on top of the tap seemingly being quite stiff to move. When I got it there was only 3 ball bearings total left in the guide rails, so I added more, not sure if I have added too many now. Also another issue for another day.

Glorious!

Again, thank you for the help.

 

[3dCase]

Thanks to all for the asnwers, again. I do appreciate the help.

So, I have made some progress. I am now getting:

EndstopSTEPPER_XOPEN
EndstopSTEPPER_YOPEN
EndstopSTEPPER_ZTRIGGERED
ProbeTRIGGERED

My only concern is it may be false reporting x.

Because x will now move on home, but it hits the end and keeps trying to move for 3 seconds. Then it gives this error:

Unable to read tmc uart 'stepper_y' register IFCNT
Once the underlying issue is corrected, use the
"FIRMWARE_RESTART" command to reset the firmware, reload the
config, and restart the host software.
Printer is shutdown

I have adjusted SGTHRS VALUE from 50 to 200, but it doesnt seem to change anything, unless the sweet spot is really precise.

UART mode jumpers are installed and the DIAG jumpers are installed.


I checked that, but i get down to this bit "In this path, you will need to download some macros dependong on your printer. If you do not have a v0 or a 2.4, you can tweak whichever makes the most sense for you." which is something I have yet to encounter, and I'm suddenly stuck again.

Again, I appreciate it. As x is now moving (if only 1 way), does that still mean the wiring could be wrong?




Yes, x does not seem to have a physical endstop or cable on it. Y does.

Z and the probe also are always triggered, but I dont think I can diagnose that until x and y are correct (or can I?).

My up to date printer.cfg below if that helps:

[include mainsail.cfg]

[mcu]
canbus_uuid: e48efe7da441
canbus_interface: can0

[mcu EBBCan]
canbus_uuid: a420eb1fbf59

[virtual_sdcard]
path: /home/biqu/printer_data/gcodes

[printer]
kinematics: cartesian
max_velocity: 300
max_accel: 3000
max_z_velocity: 5
max_z_accel: 100
square_corner_velocity: 5.0

[temperature_sensor MCU]
sensor_type: temperature_mcu

[temperature_sensor SoC]
sensor_type: temperature_host

###################################
# X Stepper
###################################

[stepper_x]
step_pin: PE2
dir_pin: !PB4
enable_pin: !PC11
microsteps: 16
rotation_distance: 40
position_min: 0
position_max: 500  # or whatever your X bed allows
position_endstop: 0
endstop_pin: tmc2209_stepper_x:virtual_endstop
homing_speed: 80
homing_retract_dist: 0

[tmc2209 stepper_x]
uart_pin: PC10
diag_pin: ^PF3     # ✅ Correct DIAG for Motor 1
driver_SGTHRS: 100
run_current: 1.2
hold_current: 0.7
sense_resistor: 0.110
stealthchop_threshold: 0


###################################
# Y Stepper
###################################

[stepper_y]
step_pin: PF12
dir_pin: PF11
microsteps: 16
rotation_distance: 40
endstop_pin: ^PB3
position_min: 0
position_endstop: 0
position_max: 500
homing_speed: 50
homing_retract_dist: 5
homing_positive_dir: false


[tmc2209 stepper_y]
uart_pin: PF13
interpolate: True
run_current: 0.8
hold_current: 0.7
sense_resistor: 0.110
stealthchop_threshold: 0
##diag_pin: PB3
driver_SGTHRS: 255

###################################
# Z Stepper
###################################

[stepper_z]
step_pin: PD7
dir_pin: PD6
enable_pin: !PF10
microsteps: 16
rotation_distance: 40
gear_ratio: 80:16
position_min: -5
position_max: 500
homing_speed: 8
second_homing_speed: 3
homing_retract_dist: 3
endstop_pin: probe:z_virtual_endstop

[tmc2209 stepper_z]
uart_pin: PF9
interpolate: true
run_current: 0.8
hold_current: 0.8
sense_resistor: 0.110
stealthchop_threshold: 0

###################################
# Z1, Z2, Z3 Steppers
###################################

[stepper_z1]
step_pin: PD3
dir_pin: !PD2
enable_pin: !PD5
rotation_distance: 40
gear_ratio: 80:16
microsteps: 16

[tmc2209 stepper_z1]
uart_pin: PD4
interpolate: true
run_current: 0.8
hold_current: 0.8
sense_resistor: 0.110
stealthchop_threshold: 0

[stepper_z2]
step_pin: PC9
dir_pin: PC8
enable_pin: !PD1
rotation_distance: 40
gear_ratio: 80:16
microsteps: 16

[tmc2209 stepper_z2]
uart_pin: PD0
interpolate: true
run_current: 0.8
hold_current: 0.8
sense_resistor: 0.110
stealthchop_threshold: 0

[stepper_z3]
step_pin: PA10
dir_pin: !PD15
enable_pin: !PA15
rotation_distance: 40
gear_ratio: 80:16
microsteps: 16

[tmc2209 stepper_z3]
uart_pin: PF8
interpolate: true
run_current: 0.8
hold_current: 0.8
sense_resistor: 0.110
stealthchop_threshold: 0

###################################
# Extruder (EBB SB2209)
###################################

[extruder]
step_pin: EBBCan:gpio6
dir_pin: EBBCan:gpio7
enable_pin: !EBBCan:gpio8
microsteps: 16
rotation_distance: 22.6789511
gear_ratio: 50:17
nozzle_diameter: 0.400
filament_diameter: 1.75
heater_pin: EBBCan:gpio0
sensor_type: EPCOS 100K B57560G104F
sensor_pin: EBBCan:gpio27
min_temp: 10
max_temp: 270
min_extrude_temp: 170
control: pid
pid_kp: 26.213
pid_ki: 1.304
pid_kd: 131.721

###################################
# Bed Heater
###################################

[heater_bed]
heater_pin: PB7
sensor_type: Generic 3950
sensor_pin: PA0
control: watermark
min_temp: 0
max_temp: 130

###################################
# Probe (Voron Tap)
###################################

[probe]
pin: EBBCan:gpio2
x_offset: 0
y_offset: 0
z_offset: 0
samples: 3
samples_result: median
samples_tolerance: 0.006
samples_tolerance_retries: 3
speed: 5.0

[filament_switch_sensor runout_sensor]
pause_on_runout: true
runout_gcode: PAUSE
switch_pin: EBBCan:gpio10

Well it is moving in the correct direction. If the motor moves the wiring is correct imho. I do not believe it could move at all if the poles are mixed up or if you are missing one connection.
With regards to the sensorless homing, on my board where the stepper driver plugs in, is a selection of jumpers (mine are under the driver so I have to pull my driver to get to them) These must be selected correctly for either way of your operations. Better check this as the machine will not otherwise detect you hit the hardstop. Then read up on how to set homing current and the sensitivity for your driver. You should go carefully down from max with steps of 10 or 5 even, to find where it starts detecting the hardstop. When sens is too high it will simply stop before the hardstop. Be careful with g28 in this test because it will continue with all axes homing but your sensorless axis will be in de wrong place! Better to only home the axis you work on.

I am sorry I cannot comment on some of the other things currently, its too confusing because right now I am setting up my own printer with new hardware and my head is going to explode

 

[shiftingtech]

I'd say there are basically 3 possible causes of the Y & Z UART errors

1. config issues
2. incorrectly configured jumpers under the drivers
3. missing power jumpers
4. bad drivers


Config issues: Stepper_y seems to be missing its enable pin. I don't think that's causing this issue, but it's still probably something you should fix
uart config jumpering: looks okay from what I can see in your photos from before
power jumpers: I can't actually make these out in your photos, so that's something to check
bad drivers: you could rotate the drivers through the working X slot to make sure they all actually function (power off before each move!).
bonus: there's a weird thing in the manta where driver 3 has two outputs: "3a and 3b". I believe you currently have your Z motors in 3a and 3b. You don't want that. you want to move Z1 over, so it's on "motor4".

I have no comment on the heater/temperature errors, since I don't know specifically what error you got there.

As for the tap rail, that all sounds like bad news. Since its supporting your entire toolhead, Tap really Requires a good quality rail with a decent amount of preload. I would discard and replace that rail (a number of vendors in the Voron space sell good quality rails for tap at reasonable prices. No specific suggestions, since I have no idea where you are in the world)

 

[Rhoobarb2005]

Well it is moving in the correct direction. If the motor moves the wiring is correct imho. I do not believe it could move at all if the poles are mixed up or if you are missing one connection.
With regards to the sensorless homing, on my board where the stepper driver plugs in, is a selection of jumpers (mine are under the driver so I have to pull my driver to get to them) These must be selected correctly for either way of your operations. Better check this as the machine will not otherwise detect you hit the hardstop. Then read up on how to set homing current and the sensitivity for your driver. You should go carefully down from max with steps of 10 or 5 even, to find where it starts detecting the hardstop. When sens is too high it will simply stop before the hardstop. Be careful with g28 in this test because it will continue with all axes homing but your sensorless axis will be in de wrong place! Better to only home the axis you work on.

I am sorry I cannot comment on some of the other things currently, its too confusing because right now I am setting up my own printer with new hardware and my head is going to explode

I'd say there are basically 3 possible causes of the Y & Z UART errors

1. config issues
2. incorrectly configured jumpers under the drivers
3. missing power jumpers
4. bad drivers


Config issues: Stepper_y seems to be missing its enable pin. I don't think that's causing this issue, but it's still probably something you should fix
uart config jumpering: looks okay from what I can see in your photos from before
power jumpers: I can't actually make these out in your photos, so that's something to check
bad drivers: you could rotate the drivers through the working X slot to make sure they all actually function (power off before each move!).
bonus: there's a weird thing in the manta where driver 3 has two outputs: "3a and 3b". I believe you currently have your Z motors in 3a and 3b. You don't want that. you want to move Z1 over, so it's on "motor4".

I have no comment on the heater/temperature errors, since I don't know specifically what error you got there.

As for the tap rail, that all sounds like bad news. Since its supporting your entire toolhead, Tap really Requires a good quality rail with a decent amount of preload. I would discard and replace that rail (a number of vendors in the Voron space sell good quality rails for tap at reasonable prices. No specific suggestions, since I have no idea where you are in the world)

Thank for the responses.

So, prgress has been made. Of sorts.

On y, I removed the TMC and checked, all the jumpers are correct. I swapped the TMC with the one on motor 8. Now y moves! So the driver was either not seated properly or was faulty, it seems.

In the end I just ditched the physical endstop on y and have gone full virtual endstops. I had increase the sensitivity as it was ratcheting. I also had to increase the amperage going to the motor from .8 to 1.2 as it would seem to get stuck and ratchet at points along the way.

So, now x, y and z all move. With x & y virtual stops now working.

Z is my next roadblock, specifically the voron tap. It is using an Optotap (2 types of taps? Something else I have learned today). But what I have realised, is that the back plate that breaks the optical beam is missing, The beam never breaks, so the sensor can never work.

So, I am at a crossroads really.

Do I stick trying to get this Stealthburner running, not knowing what other issues there are along the way with it. Or do I go for a more basic toolhead for now, just to get it working.

I could print a new back plate, IF I had a working printer.

Is it worth the hassle starting from a more basic head, or stick with the SB even though it may have more issues along the line?

Is it a sunk cost fallacy at this point?

 

[3dCase]

Thank for the responses.

So, prgress has been made. Of sorts.

On y, I removed the TMC and checked, all the jumpers are correct. I swapped the TMC with the one on motor 8. Now y moves! So the driver was either not seated properly or was faulty, it seems.

In the end I just ditched the physical endstop on y and have gone full virtual endstops. I had increase the sensitivity as it was ratcheting. I also had to increase the amperage going to the motor from .8 to 1.2 as it would seem to get stuck and ratchet at points along the way.

So, now x, y and z all move. With x & y virtual stops now working.

Z is my next roadblock, specifically the voron tap. It is using an Optotap (2 types of taps? Something else I have learned today). But what I have realised, is that the back plate that breaks the optical beam is missing, The beam never breaks, so the sensor can never work.

So, I am at a crossroads really.

Do I stick trying to get this Stealthburner running, not knowing what other issues there are along the way with it. Or do I go for a more basic toolhead for now, just to get it working.

I could print a new back plate, IF I had a working printer.

Is it worth the hassle starting from a more basic head, or stick with the SB even though it may have more issues along the line?

Is it a sunk cost fallacy at this point?

Great you managed your sensorless homing. Took me also some time to figure it out so it became reliable. Now I love it. Congrats on that.

IMHO it is not ever a sunk cost falacy, as long as you end up with it giving you what you want/need. Obviously I do not know what it has costed you to date but a good 3d printer is not cheap. The cheap ones are nearly all rubbish I found and will only give the owner satisfaction from tiukering until they modified them sooo much they became a good printer. And for those cases the cost does not matter, well almost.
I have never had a tap of any kind so I cannopt help you with that. Obviously if you need something printed I am sure any of us will help, depends on location if it is worth it with regards to shipping. I am also a technical designer of sorts, so if you have 3d models that need tweaking I can do that for you and for free. just send me step files and explain what you want.
So if that could be of help just see if it is feasible, my location is Bulgaria. But for file modifications it does not matter, I can do that from anywhere. just to be clear, stl files are possible but will sometimes have limitations. STEP files are no trouble ever. Any other files I need to check before promising.

 

[Rhoobarb2005]

Great you managed your sensorless homing. Took me also some time to figure it out so it became reliable. Now I love it. Congrats on that.

IMHO it is not ever a sunk cost falacy, as long as you end up with it giving you what you want/need. Obviously I do not know what it has costed you to date but a good 3d printer is not cheap. The cheap ones are nearly all rubbish I found and will only give the owner satisfaction from tiukering until they modified them sooo much they became a good printer. And for those cases the cost does not matter, well almost.
I have never had a tap of any kind so I cannopt help you with that. Obviously if you need something printed I am sure any of us will help, depends on location if it is worth it with regards to shipping. I am also a technical designer of sorts, so if you have 3d models that need tweaking I can do that for you and for free. just send me step files and explain what you want.
So if that could be of help just see if it is feasible, my location is Bulgaria. But for file modifications it does not matter, I can do that from anywhere. just to be clear, stl files are possible but will sometimes have limitations. STEP files are no trouble ever. Any other files I need to check before promising.

Thank you so much for the kind offer, I will keep that in mind. I'm in the UK btw.

But... It seems that I don't need it!!

I remade the wire between the tap sensor and the SB2099 and lo and behold, it works!

So, in all honesty, I don't know what is going on with it because it says optotap on it, there is no rear plate with the protrusion (looking at the SB 3d files), in fact it doesn't look like anything I have yet seen, yet it seems to work. I just don't know..

So..., x, y and z all home.

Now I need to sort the temp errors...

Again, thank you everyone so far for the help.

 

[3dCase]

Thank you so much for the kind offer, I will keep that in mind. I'm in the UK btw.

But... It seems that I don't need it!!

I remade the wire between the tap sensor and the SB2099 and lo and behold, it works!

So, in all honesty, I don't know what is going on with it because it says optotap on it, there is no rear plate with the protrusion (looking at the SB 3d files), in fact it doesn't look like anything I have yet seen, yet it seems to work. I just don't know..

So..., x, y and z all home.

Now I need to sort the temp errors...

Again, thank you everyone so far for the help.

Sometimes it is like that, but it works
With regards to your temps, what actually is the error and what does it say?
P.S. I saw your post on klipper discourse also. Those two people who answered so far ar really good at what they do with Klipper. Mike is spot on with electronics and Sineos is a klipper expert from a long time ago already. As long as you keep doing what they suggest and you systematically feed them the correct info after checks, I am sure between them you will get this sorted.
But like Sineos said, systematic approach is key. You seem to do that so far and bit by bit you are making progress.

 

[Rhoobarb2005]

Sometimes it is like that, but it works
With regards to your temps, what actually is the error and what does it say?
P.S. I saw your post on klipper discourse also. Those two people who answered so far ar really good at what they do with Klipper. Mike is spot on with electronics and Sineos is a klipper expert from a long time ago already. As long as you keep doing what they suggest and you systematically feed them the correct info after checks, I am sure between them you will get this sorted.
But like Sineos said, systematic approach is key. You seem to do that so far and bit by bit you are making progress.

Well, I have hit another issue (shock!).

The bed doesn't want to heat up.

I checked the power, Motor Power has 24v, POWER has 24v, BED-Power has 24v, but BED-OUT does not have anything.

I tested it via SET_HEATER_TEMPERATURE HEATER=heater_bed TARGET=60 and just setting the temps in the klipper ui, but the voltage doesn't change, it just stays at 0v.

I'm worried something has blown now :/

 

[3dCase]

Well, I have hit another issue (shock!).

The bed doesn't want to heat up.

I checked the power, Motor Power has 24v, POWER has 24v, BED-Power has 24v, but BED-OUT does not have anything.

I tested it via SET_HEATER_TEMPERATURE HEATER=heater_bed TARGET=60 and just setting the temps in the klipper ui, but the voltage doesn't change, it just stays at 0v.

I'm worried something has blown now :/

Did it work before?
Is it a24v bed or a mains bed?
Have you checked you are at the correct outlet for bed in your situation?
EDIT!!! Your board has several other HE outlets that you could use with a SSR in case you have blown the 24 volt bed outlet somehow. You just need to reconfigure wiring and pins in your cfg. Does your conttol board have another bed outlet to configure? (My octopus has two, one direct 24 v and another to drive a ssr for mains bed.)
If all above is checked and still no luck I hope your board has the second output for ssr. If so get an ssr and define bedpins to those and hookup your bed through the ssr.
If it hasnt got the second outlet then maybe you could find a second hotend outlet. If you have that do check wattage! If the bed is higher wattage then the hotend outlet better use a relay again (ssr) but I do not know how well it will respond to the PWM if it uses that. Sounds like more research.

Check this out, https://docs.vorondesign.com/build/electrical/v2_octopus_wiring.html this is my octopus and the ssr for the bed is connected to HE1. In case you are stuffed with a broken bed output you can use this method also.