Sensorless homing and tap with CANBus on EBB36

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.

klippy (1).log (1.3 MB)

Got it!

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.

  1. The desired behavior after issuing the g28 command is that the appropriate axis travels to contact the frame and then stops. Correct?
  2. I want the highest number that allows the travel to complete reliably. Correct?
  3. I’ll post my questions about configuring TAP with EBB36 in another thread.

Thanks!

To your questions:

  1. Correct. Make sure that the two contact points can survive contact with the steppers running at full power. Make sure there are no wires that can get pinched.
  2. Personally, I try to establish a range which at one end the gantry barely moves before detecting a false contact and the other end being where contact with the frame doesn’t cause the stepper to stall and stutter. With this range, I then use the value in the middle which gives (me) reliable operation.
  3. Sure. I don’t have any experience with that.

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

Got it. Thanks!

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