Basic Information:
Printer Model: RatRig V-Core Pro 1.3
MCU / Printerboard: BTT Octopus V1.1
klippy (2).log (102.3 KB)
I have to be honest and say that the printer.cfg displayed in your klippy.log is unreadable - there is literally over 1,000 lines of macros in the 1,300 or so lines of printer.cfg. Topping it off, you have a bunch of pin aliases which make it difficult to verify that the pin assignments are correct. I’m guessing this is your first time with Klipper and you picked up the printer.cfg and the included macro files from somewhere else but this is a problem.
When I look at your [stepper_x]/[tmc2209 stepper_x] statements in printer.cfg I can see that you haven’t defined the endstop pins properly using the statement in [stepper_x]:
endstop_pin: tmc2209_stepper_x:virtual_endstop
but, I don’t think things will work if you just add this statement (and a similar one for the Y axis) - your driver_sgthrs values won’t be reasonable and there are probably other problems lurking out there. There’s just too much here to try and figure out all that’s wrong in one fell swoop.
Could I ask of you:
- Send pictures of your Octopus with the X and Y axes TMC2209 modules removed so that we can see how you configured all the jumpers.
- Remove the pin aliases in your
printer.cfg; it might be the “right” way to do things from a software perspective but it makes it impossible to check to see if the pins are specified correctly - I’m not going to (and I would be surprised if anybody else will) go back more than 1,000 lines to verify that the correct MCU pin connection is specified for the specific TMC2209’s pin. - Remove ALL of your macros. At a cursory glance, I don’t see any issues but I’m not up to (and, again, I would be surprised if anybody else will be) trying to understand every one that’;s called during a homing operation and try to figure out if things are set up correctly.
Once you have that done, you should be able to get sensorless homing working on the X & Y axes fairly easily and I can work with you to get the basic homing macro/G28 override working properly.
The config i’m using is from RatOS which i assumed was the best for their printer, I’ve commented out the board config and copied the settings without aliases, but commenting out the macros results in an error: Option ‘gcode’ in ‘gcode_macro RatOS’ must be specified’
This may be rather messy, but this is the klippy log after i’ve cut and pasted all the code into the main config file without any [include] files or macros. as of now, neither the x nor y carriages move upon homing, but the z axis (with a physical endstop) homes successfully:
klippy (7).log (5.8 KB)
Okay thanx. I wanted to confirm your jumpers.
One comment, it looks like you have all the “diag” jumpers installed. If you are using M0 as “X” and M1 as “Y” then you should only have two installed (the top two in your photograph).
To set your jumpers, this pinout diagram is an excellent resource to use:
Thank you for making the changes to your printer.cfg - it makes it a lot easier to work through.
Sorry, I just wanted you to pull the TMC2209 driver modules in order for me to see the jumpers, I should have told you to put them back in after taking the picture.
The UART jumpers look correct and, as I noted in my previous reply, I think you have more “DIAG” jumpers set than you need.
Now, looking at your updated printer.cfg, I see you added the endstop_pin = tmc2209_stepper_x:virtual_endstop and endstop_pin = tmc2209_stepper_y:virtual_endstop statements. Thank you.
With the TMC2209 modules back in, could you make your stepper X/Y statements look something like (with ### indicating my changes):
[stepper_x]
step_pin = PF13
dir_pin = PF12
enable_pin = !PF14
rotation_distance = 40
microsteps = 16
homing_speed = 25 ### The original "50" was too fast
homing_retract_dist = 0
position_min = 0
position_max = 300
position_endstop = 0
endstop_pin = tmc2209_stepper_x:virtual_endstop
[tmc2209 stepper_x]
stealthchop_threshold = 999999
interpolate = True
uart_pin = PC4
run_current = 0.6 ### This is for homing - we'll set you up with a macro for normal operation
#driver_tbl = 1 ### Not required
#driver_toff = 3 ### Not required
#driver_hend = 0 ### Not required
#driver_hstrt = 0 ### Not required
sense_resistor: 0.110 ### You want to use the internal resistor
diag_pin = ^PG6
driver_sgthrs = 100
I normally put the [tmc2209 stepper_... statement immediately after the [stepper_... statement as it makes them easier to fine.
Now, turn things on and try just homing the X axis and adjust the driver_sgthrs for stepper_x to try and get sensorless homing working. If you get it working then go on to stepper_y.
Let me know how you make out.
This helps a lot, thank you, I didn’t know which of the diag pins needed jumpers so installed all of them
klippy (10).log (7.1 KB)
I have the stallguard threshold at 1 but the x and y axis do not move and set home as the position they were in. Endstops X and Y also read triggered constantly
You’re going to have to experiment with different values.
Start at the middle value (127) and add/subtract half the value (63 and 191) to see which seems to work better, then halve the value again and keep experimenting.
Personally, for my CoreXY printers, I usually end up with a '2209 threshold of around 60 to 70. You could even start here.
I’ve used a range of values from 0-255 and the x/y axes still don’t move when homing, but seem to just assume the point they turn on at is at 0,0. After doing G28 X/Y , i can move the motors correctly, they just don’t home.
Have you run STEPPER_BUZZ to make sure that they can move?
https://www.klipper3d.org/Config_checks.html#verify-stepper-motors
If they’re moving properly then you’re going to have to experiment with your run_current, driver_SGTHRS and homing_speed.
I suggest you create a table to test the values and something should come together for you.
STEPPER_BUZZ results in a small diagonal movement on each motor, but after trying quite a few different configurations of the three, the toolhead still stays in that one spot that it defines as 0,0. Does sensorless homing usually read triggered when checking the status of endstops? I tried to invert the diag pin after these settings didn’t work which resulted in the endstops all reading open but the toolhead performed the opposite action, moving towards the rail to home and crashing into them, with no settings stopping it.
Could you share your latest klippy.log and printer.cfg files?
Also, what values did you try for the different variables?
klippy (11).log (7.3 KB)
printer.cfg (15.4 KB)
For the variables, i used interchangeably 0.2, 0.5 and 1.0 for run_current, 0 for driver_SGTHRS and 10,25 or 50 for homing_speed, and 255 for driver_SGTHRS when inverting the diag pin.
Your printer.cfg looks good - the only comment I would make is delete the interpolate: argument in your [tmc2209 stepper statements as per:
Regardless, following:
https://www.klipper3d.org/TMC_Drivers.html#configure-printercfg-for-sensorless-homing
I suggest that you start with a run_current of 0.5 (0.2 is too small) and increase in 0.1A increments. Along with this, use 64 for driver_SGTHRS and keep homing_speed to 25.
Let’s see what happens.
I’ve set driver_SGTHRS to 64, homing_speed to 25, and tested the run_current from 0.5 all the way to 1.7 with no changes in behaviour. Using a 1.7 current with an inverted diag_pin does not stop it either.
Sorry, what is the behaviour? Is it moving or not moving?
Are you using the “G28 X” command in the console?
The carriage doesn’t move if i use G28 X or G28 Y at all but acts as if it has homed successfully, setting the respective position to 0 in the interface and allowing use of manual control, the other behaviour where the carriage did not stop was if I inverted the diag_pin in the code which I used incase the signals were inverted. Not sure if that is actually useful so I’ll not change it from now on.
I’m stumped. I’m running experiments here on one of my CoreXY printers using your printer.cfg without any issues.
Can you confirm that the jumpers you’ve set are the same as what’s in the image below:
This is the CoreXY I’m trying your code on and using an 'F446 Octopus V1.1 which should be the same as yours.
Having them missing is the only thing I can think of that would cause your problems.
Both jumpers are in the same place, is it possible that sensorless homing isn’t available on the specific type of TMC2209’s I’m using? They are TWOTREES TMC2209 V2.0. These only have two rails of pins, looking at some other models there appear to be two pins at the front too, where there are holes on these drivers.
EDIT: I’ve run out of replies for a new user so I’m replying here, but that first image is exactly what i have. It’s great to know what the problem may be after all, I’ll go and see if i can’t nab some pins from some connectors and see if i can solder them in.
EDIT 2: It was indeed the pins! This is annoying since I tried to use sensorless homing specifically since i had the TMC2209s and wanted to get rid of some wires, turns out these modules couldn’t even use it to begin with. I’ve soldered the pins onto both the stepper_x and stepper_y drivers, and i can now home sensorlessly without a problem. Thanks for the help!
Should i revert back to the original config while carrying over the changes from here for the macros or keep this config.cfg?
1 Like