Consistently spaced, Uninstructed Y-axis movements
Hello, I've got an odd one that hopefully someone can help me resolve. My printer has been working great for months, no issues. Last night, I started getting the behavior seen in the 3 videos. 1 video shows the printer during a print, and the other 2 show it just at idle after I cancelled a print, steppers still enabled, moving the Y motor without me instructing it to.
Not sure if this is relevant, but I just moved to Beacon contact, and after it does a nozzle probe during print (G28 Z METHOD=CONTACT CALIBRATE=1), this issue starts. I will try induction homing to see if there is any difference. I would expect to see the same behavior after I enable the steppers at all, but I do not. I can home and the erratic movements don't occur.
Printer info: Ratrig v-core 3.1 300mm
Mods: BRS Engineering tensioner and AWD, klipper-tmc-autotune
Motors: 48v on X, X1, Y, Y1 motors
Electronics: BTT Octopus Max EZ, 5160 Pro drivers on X, X1, Y, Y1 motors
start_print macro: https://github.com/matthewj301/rat-race/blob/e9f0a843678497ac3e1b9e0ac7d4bdfb1547d637/custom/ratos_macros.cfg#L95
motor definitions: https://github.com/matthewj301/rat-race/blob/main/custom/steppers/motors/ldo/tmc5160/42STH48-2504AH.cfg
Link to all vids: https://photos.app.goo.gl/fJSrN5S8a9MHe4Bg9
Steps already taken: swapped stepper drivers, swapped motor plug locations on physical BTT board, retightened all grub screws, fasteners, etc, resynced X and Y motors, retentioned belts, confirmed there is no obstruction when moving toolhead by hand
At this point I'm wondering if it's the board itself, but any help would be much appreaciated!
GitHub
rat-race/custom/steppers/motors/ldo/tmc5160/42STH48-2504AH.cfg at m...
My RatOS/Klipper Configs for the RatRig V-Core 3.1 - matthewj301/rat-race
GitHub
rat-race/custom/ratos_macros.cfg at e9f0a843678497ac3e1b9e0ac7d4bdf...
My RatOS/Klipper Configs for the RatRig V-Core 3.1 - matthewj301/rat-race
Solution:Jump to solution
After swapping all x/y motors to different MCU ports, rather than just the ones acting erratic, the issue has disappeared and the problem seems to be located --> the board itself
2 Replies
Reverting back to configs prior to Beacon Contact showed the same issues during print, so that's ruled out
Solution
After swapping all x/y motors to different MCU ports, rather than just the ones acting erratic, the issue has disappeared and the problem seems to be located --> the board itself