Basic Information:
Printer Model: Voron 2.4 R2
MCU / Printerboard: Octopus 1.1
Host / SBC Raspberry PI
klippy.log
Fill out above information and in all cases attach your klippy.log
file (use zip to compress it, if too big). Pasting your printer.cfg
is not needed
Be sure to check our “Knowledge Base” Category first. Most relevant items, e.g. error messages, are covered there
Describe your issue:
Hey y’all! New guy here. Probably bit off too much on my first Voron build here, but; I went with CANBus, TAP and Stealthburner with CW2 Extruder. Then I decided I wanted Sensorless Homing to boot.
I followed the guides put the jumpers on the X and Y Diag pins and made what I understood to be the appropriate changes in my printer config.
At this point when I issue the g28 x0 or y0 commands the Z axis seems to travel down 10 to 20 mm but there is no movement from the X or Y axis and indication that anything happened. Interestingly, before I set homing_retract_dist = 0 I would get movements in either X or Y axis accompanied by errors
klippy.log (13.1 KB)
.
…
I probably should have gotten it working first before setting up sensorless homing, but here I am.
Is the klippy.log
representative of what you are running?
It doesn’t have any of the required lines for sensorless homing.
Here is the X Axis statements from my 2.4:
[stepper_x]
dir_pin: !PB4
step_pin: PE2
enable_pin: !PC11
microsteps: 16
rotation_distance: 40
endstop_pin: tmc2209_stepper_x:virtual_endstop
homing_retract_dist: 0
position_min: -25
position_max: 225
position_endstop: -5
homing_speed: 25
[tmc2209 stepper_x]
uart_pin: PC10
run_current: 0.8
sense_resistor: 0.110
stealthchop_threshold: 999999
driver_SGTHRS: 70
diag_pin: PF3
You’re going to have to add the correct endstop_pin:
line to the stepper_x
parameter as well as driver_SGTHRS:
and diag:
to the tmc2209 stepper_x
statement.
Once that’s in place, you’ll have to tune the driver_SGTHRS:
value for your printer.
Regardless, when I look over your klippy.log
, you don’t have a connection between your host and main controller board. Along with that, I don’t see any canbus
connection statements for the main controller board or the toolhead controller.
Thank you for your response. I’m afraid I don’t understand the klippy.log. It doesn’t seem to agree with printer.cfg. I did follow the guide and add the statements as I understood them. Should I post my printer.cfg?
I did see somewhere online that this should be set to 0.
I backed up and redid some steps and it looks like a ! on the diag_pin for X, Y and Z may have been the problem. I found this doing the query_endstops and all reported as triggered. Removing the ! now I get what seems to be appropriate movement.
Since I’m using TAP and it’s connected by CANBus, I suppose it will be the Z end stop but I can’t find anything on configuring it with CANBus.
Could you share your most recent klippy.log
?
The most recent one seems to be dated 07/15/2024. Is there a way to get it more recent?
If you’re on Mainsail, go to the “Machine” page and then it’s available at the bottom right for download.
Got the klippy.log
and things look a lot better.
Going back to the original thread, you’re not getting any movement on X & Y when you start homing?
The problem is that you are not setting a low enough value for the driver_sgthrs
lines. I typically use 60 to 70 on my printers and you have 200 & 255. They should also be the same values.
I would suggest starting at 150, testing to see if things start moving and if they don’t, drop another 25 until things start coming together.
Good luck!
Thank you for your help. This has me headed in the right direction I believe.
- The desired behavior after issuing the g28 command is that the appropriate axis travels to contact the frame and then stops. Correct?
- I want the highest number that allows the travel to complete reliably. Correct?
- I’ll post my questions about configuring TAP with EBB36 in another thread.
Thanks!
One more quick question please.
After issuing the G28, I have to use the emergency stop IOT be able to move the toolhead back to a neutral position. Is this normal at this stage?
It is for me.
I’m sure there’s a better way of doing it (hopefully somebody will pipe up), but I make sure the gantry is well above the print surface so there’s no chance of contact, start with the X axis (you should find with a CoreXY the X axis value you find can be used with the Y axis) and reduce your SGTHRS values by 25 or so until the gantry starts moving and continue until the gantry hits its stop and the motor starts stuttering.
You have your basic range - set SGTHRS to the value between the two extremes and you should have something pretty close to your final value.
1 Like
To keep the position of the tool head at a known point, the motors stay on.
You can turn off the motors with M18
or M84
https://www.klipper3d.org/G-Codes.html
1 Like
So a similar process for the Z axis?
Do you mean “Y” or “Z”?
If it’s “Y”, then yes, but you should have the same SGTHRS value (or one very close) as what you came up with for “X”.
If it’s “Z”, then you’re going to have to first get X and Y homed and then follow the Tap procedure (which I’m not familiar with).
I have X and Y set as per your instructions to find the mid point between just contacting the frame and contacting the frame too hard. That was very helpful.
1 Like