MCU / Printerboard:Octopus pro V1.0
Host / SBC Raspberry Pi 3b+
klippy.log
Fill out above information andin all cases attach yourklippy.logfile (use zip to compress it, if too big). Pasting yourprinter.cfgis not needed Be sure to check our “Knowledge Base” Category first. Most relevant items, e.g. error messages, are covered there
Describe your issue:
…
After installing the Canbus BTT 2209 endstop Y does not work (X is OK). I have already tried connecting Stop2 (PB6) and GND, Stop3 (PB7) and GND. Of course, by making the changes in the printer.cfg. He is always open. I’ve tested it without the micro switch, just joining the wires, with no result. It already replaces the strands.
I couldn’t get any help on the internet in my research. So in desperation I appeal to you.
My setup: Voron 2.4 with Octopus pro V1.0, SB2209 v1.0, Raspberry pi 3b.
I hope someone can help me.
Just looking at your klippy.log and one thing jumps out at me - what are you using for your X/Y drivers?
Everything else seems to be TMC2209s but you have a [stepper2209 stepper_y] statement in two of your tests, but you don’t have any [tmc2209 stepper_x] statements at all.
Regardless, It looks like you’re using “Driver1” as your Y Axis, do you have the jumper installed for MDIAG1 (which is the PG9 pin you’ve specified)? If it’s not in place, then you won’t get anything from the end stop switches.
Hi Mykepredko, thank you for your quick reply.
All drivers are tmc22209 and I’m using “Driver1” as Y Axis.
I didn’t have this Jumper (MDIAG1). Is it the same DIAG1 indicated on the back of the Octopus Pro V1.0 board?
I put this jumper (DIAG1) and unfortunately it didn’t change the result. The problem continues.
My endstop connector is using the Stop3 and GND pins on the SB2209 board. Why doesn’t it work if I indicate endstop pin PB7 in “Printer.cfg”?
And thank you very much for your assistance. Unfortunately I don’t have the necessary knowledge to solve it myself.
You need to specify that the endstop pin is on the BTT 2209. It should be EBBcan: PB7 not just PB7.
It wasn’t clear that you had put the endstop pin on the toolhead controller - is this the same case for the X axis endstop? If it is, then you need to to add the EBBcan: PB6 there as well.
You should also put in the [stepper2209 stepper_x] and [stepper2209 stepper_y] statements into your printer.cfg file so you can take advantage of the TMC222209 operation there.
WORKING!!
His orientations were fundamental, including in relation to the
" [stepper2209 stepper_x] and [stepper2209 stepper_y] statements into your printer.cfg."
I had only one problem because the “c” was not capitalized. It was just a matter of changing. Now it’s working.
Thank you very much mykepredko
After having the endstops working, I started to have a problem with HOME. The toolhead went first in the Y direction instead of going in the direction of the X endstop. After searching the internet I added to the Printer.cfg:
[homing_override]
gcode:
G28 Y0
G28 X0
G28 Z0
and commented on section [safe_z_home].
With this modification, the Home step starts with the X endstop, but… Endstop X is not triggered.
If I test it with QUERY_ENDSTOPS I verify that it is operational. But on Home it doesn’t work.
Result: I need help. Again.
Also, I’m not sure about your macro. Where did you get the idea to add the Zero after the Axis (ie G28 X0)? I’ve never seen that usage before, normally just the axis is specified (G28 X):
Now, I did find a discussion of it, but it’s from 19 years ago:
For my CoreXY printers (including my Voron 2.4), I use something like:
[gcode_macro _HOME_X]
gcode:
SET_TMC_CURRENT STEPPER=stepper_x CURRENT={printer["gcode_macro global"].xy_home_current}
SET_TMC_CURRENT STEPPER=stepper_y CURRENT={printer["gcode_macro global"].xy_home_current}
G4 P500 # Wait for StallGuard registers to clear
G28 X
SET_TMC_CURRENT STEPPER=stepper_x CURRENT={printer["gcode_macro global"].xy_run_current}
SET_TMC_CURRENT STEPPER=stepper_y CURRENT={printer["gcode_macro global"].xy_run_current}
G91 # Move away to centre of build surface
G1 X125 F1200 # Changed for Micro Swiss NG
[gcode_macro _HOME_Y]
gcode:
SET_TMC_CURRENT STEPPER=stepper_x CURRENT={printer["gcode_macro global"].xy_home_current}
SET_TMC_CURRENT STEPPER=stepper_y CURRENT={printer["gcode_macro global"].xy_home_current}
G4 P500 # Wait for StallGuard registers to clear
G28 Y
SET_TMC_CURRENT STEPPER=stepper_x CURRENT={printer["gcode_macro global"].xy_run_current}
SET_TMC_CURRENT STEPPER=stepper_y CURRENT={printer["gcode_macro global"].xy_run_current}
G91 # Move away to centre of build surface
G1 Y-140 F1200 # Changed for Micro Swiss NG
[homing_override]
axes: xyz
gcode:
{% set home_all = 'X' not in params and 'Y' not in params and 'Z' not in params %}
{% if home_all or 'X' in params %}
_HOME_X
{% endif %}
{% if home_all or 'Y' in params %}
_HOME_Y
{% endif %}
{% if home_all or 'Z' in params %}
G28 Z
QUAD_GANTRY_LEVEL # Added 2023.07.11
G1 Z10
{% endif %}
This is for sensorless homing but note that it places the toolhead in the middle of the workspace before homing on the next axis.
Amazing how Canbus complicated everything. This printer worked well with Duet 2 and Raprap firmware. I decided to change it to get rid of the multitude of wires. It seems that I won’t be able to. I also have the option of keeping the wires only for the micro swtich. I’m thinking out loud. klippy (7).log (2.5 MB)
That’s the reason why I use CAN, it does simplify things but you have to make sure you’re correct when working with it, follow examples exactly and, if you make deviations, you understand what you’re doing exactly.
Case in point…
Where did you get G28 X0? I can’t find “X0”, “Y0” or “Z0” anywhere in that link. I provided the 19 year old link to indicate that it wasn’t something that was currently in use.
I’m not sure why you’re doing the Y axis first - if you read the link, you’ll see that is questioned. The conventional way of listing the axis is in order X, Y & Z - I’m not sure it will cause problems with the software, but it may.
Change the order to X, Y and then Z.
Along with that, you need to look at what’s in your printer.cfg and the files that are included there. When I look at your klippy.log, I see this space in the PRINT_END macro:
Following your suggestions.
After making this modification, homing started again on the Y axis. I interrupted the movement by manually activating the X micro switch not the Y micro switch.
The question is how to make homing start on the X axis.
As for the Macros, I commented almost all of them to eliminate any influence at this time when there is no work. And you’re right about following the examples. I’ve been making an effort. When I change, I always follow information from the internet that worked (from 2019 is not valid, I didn’t pay attention to the date. It’s the desperation to make it work.) In addition, my knowledge of Klipper is very little, which makes everything difficult.
I continue to count on your good will to help me
Please be as complete in your information as possible. In your last post, I’m not sure what happens when you “manually activiting the X micro switch not the Y micro switch.” Does this mean the printer wasn’t responsive to the Y endstop?
Follow @Sineos link and put in what is required for the [homing_override]
English is not my language so I get confused.
When I do HOME, the printerhead moves in the Y direction. The correct thing would be to move in the X direction. Also, as you understood, printer wasn’t responsive to the Y endstop. The printer taps the aluminum profile. I did a HOME test and activated the X-axis micro switch and the printer even moving in the Y direction stopped.
The correct pin for X endstop is displayed on the “printer.cfg”.
[stepper_x]
step_pin: PF13
dir_pin: !PF12
enable_pin: !PF14
rotation_distance: 40
microsteps: 32
full_steps_per_rotation:200 #set to 400 for 0.9 degree stepper
endstop_pin: !EBBCan: PB6
position_min: 0
Homing and Gantry Adjustment Routines
##############################################################
[idle_timeout]
timeout: 1800
[homing_override]
gcode:
G28 X
G28 Y
G28 Z
#[safe_z_home]
XY Location of the Z Endstop Switch
Update -10,-10 to the XY coordinates of your endstop pin
(such as 157,305) after going through Z Endstop Pin
Location Definition step.
#home_xy_position:-10,-10
#speed:100
#z_hop:10
Much easier to read and follow.
You’re still not following the information in the link (Configuration reference - Klipper documentation) @Sineos provided.
You need to have the axes: xyz parameter in in your [homing_override]’ statement. I know they have a comment (#) at the start of the line, but it’s mandatory.
Try adding the axes: xyz parameter and, if that doesn’t change things, then go through the macro I provided you above and try that in your printer.cfg.
Let’s see if I did the right thing. According to (Configuration reference - Klipper documentation) we have :
# Homing and Gantry Adjustment Routines
#################################################
[idle_timeout]
timeout: 1800
[homing_override]
gcode:
G28 X
G28 Y
G28 Z
axes: xyz
#[safe_z_home]
### XY Location of the Z Endstop Switch
### Update -10,-10 to the XY coordinates of your endstop pin
### (such as 157,305) after going through Z Endstop Pin
### Location Definition step.
#home_xy_position:-10,-10
#speed:100
#z_hop:10
Result: no change.
Homing keeps moving in the Y direction, the endstop doesn’t act. But if I repeat the Homing and hand trigger the X endstop, the Y movement stops and nothing else happens.
To use your macro ( sensorless homing) we don’t need to make modifications to the hardware ? (jumpers for example?)
My X/Y Stepper Settings
# X/Y Stepper Settings
#####################################################################
## B Stepper - Left
## Connected to MOTOR_0
## Endstop connected to DIAG_0
[stepper_x]
step_pin: PF13
dir_pin: !PF12
enable_pin: !PF14
rotation_distance: 40
microsteps: 32
full_steps_per_rotation:200 #set to 400 for 0.9 degree stepper
endstop_pin: !EBBCan: PB6
position_min: 0
##--------------------------------------------------------------------
## Uncomment for 300mm build
position_endstop: 300
position_max: 300
##--------------------------------------------------------------------
homing_speed: 25 #Max 100
homing_retract_dist: 5
homing_positive_dir: true
## Make sure to update below for your relevant driver (2208 or 2209)
[tmc2209 stepper_x]
uart_pin: PC4
interpolate: false
run_current: 0.8
sense_resistor: 0.110
stealthchop_threshold: 0
## A Stepper - Right
## Connected to MOTOR_1
## Endstop connected to DIAG_1
[stepper_y]
step_pin: PG0
dir_pin: !PG1
enable_pin: !PF15
rotation_distance: 40
microsteps: 32
full_steps_per_rotation:200 #set to 400 for 0.9 degree stepper
endstop_pin: EBBCan: PB7
position_min: 0
##--------------------------------------------------------------------
## Uncomment for 300mm build
position_endstop: 300
position_max: 300
##--------------------------------------------------------------------
homing_speed: 25 #Max 100
homing_retract_dist: 5
homing_positive_dir: true
## Make sure to update below for your relevant driver (2208 or 2209)
[tmc2209 stepper_y]
uart_pin: PD11
interpolate: false
run_current: 0.8
sense_resistor: 0.110
stealthchop_threshold: 0
When I was out, I was thinking about your problem and wondered how do you know you have your X & Y Stepper Drivers wired to the correct motors?
You can’t use the Klipper Stepper Buzz command to check but what happens if you reverse the stepper motor wires going into the X/Y sockets on your Octopus Pro?
Mike!!! You’re the guy.
That was it. Engine A (Y) was in the wrong direction. Dude, I really appreciate your patience and willingness to help me. If it wasn’t for you, this CanBus would end up on the barbecue and I was already getting ready to go back to the miles of infernal wires.
Thank you very much.
Let’s now move on to the next steps hoping they will be less problematic.
PS: I made a mark on the pulley and used Stepper Buz
