Matthew Johnson
RRCRat Rig Community [Unofficial]
•Created by Matthew Johnson on 6/6/2024 in #fix-my-printer
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!
4 replies
RRCRat Rig Community [Unofficial]
•Created by Matthew Johnson on 5/23/2023 in #ratos-support
RatOS Adaptive Mesh requires manually editing bed_mesh horizontal_move_z
Not sure if this is know to be required, but when adaptive meshing with a euclid probe (just installed), the bed was not moving down enough with the horizontal_move_z of 5.
This was causing the probe to continue to be triggered as the toolhead moved over to probe the priming location, which caused RatOS to think the probe was stowed instead of deployed.
Specifically, these are the klipper logs when it happens during the "CALIBRATE_ADAPTIVE_MESH" and nested "PROBE_FOR_PRIMING" macros (newest msg first).
9:16 PM
Error evaluating 'gcode_macro _ASSERT_PROBE_STATE:gcode': gcode.CommandError: expected probe state to be deployed but is stowed (1)
9:16 PM
probe: TRIGGERED
9:16 PM
echo: PROBE_FOR_PRIMING: Probing the prime location at X: 292.942 Y: 36.75
9:16 PM
echo: Probing the prime location..
9:16 PM
echo: CALIBRATE_ADAPTIVE_MESH: Recieved coordinates X0=64.0715 Y0=77.0533 X1=235.931 Y1=225.53
Looking at the "PROBE_FOR_PRIMING" macro, it takes the z_hop value from: z=printer.configfile.settings.bed_mesh.horizontal_move_z
Where it is then used here in the "PROBE_FOR_PRIMING" macro, and where I believe my issue appeared:
Lift to horizontal_move_z
G0 Z{z} F{z_speed}
Once I edited the bed_mesh horizontal_move_z value from 5 to 15, I no longer saw this issue.
Is this expected behavior, in that the user should update the horizontal_move_z value to support the probe they're using? I would have thought it would either use the "z_hop" value overridden in the euclid.cfg config (below), or would define its own bed_mesh horizontal_move_z in the probe configs to compensate.
[ratos_homing]
z_hop: 25
16 replies
RRCRat Rig Community [Unofficial]
•Created by Matthew Johnson on 5/22/2023 in #ratos-support
Stowable probe docks and homing: toolhead runs into dock when homing if in line with probe dock
I have a PCB_Klicky installed on my V-Core 3.1, with a dock at the front-left corner of the printer. If my toolhead is in line with the dock, and running the default homing procedure, the toolhead will run into the dock. I have a custom probe implementation for the PCB_Klicky, but it inherits from the official klicky config (config attached).
This only really happens when I've been messing with the toolhead and have it at the front of the printer, but still, something I'd like to never have to worry about.
I've gotten around this by overriding the "ratos_homing" macro and swapping the "x" and "y" if statements so Y is homed first, but is there a better way to do this? I'd rather not override the macro and feel like I may be missing something in how RatOS implements stowable probe logic since this seems like a situation others would run into.
Thanks in advance!
1 replies