JaminCollins
JaminCollins
RRCRat Rig Community [Unofficial]
Created by JaminCollins on 9/7/2024 in #fix-my-printer
No trigger on probe after full movement, but only rarely
Any idea what would cause an infrequent, but persistent:
No trigger on probe after full movement
No trigger on probe after full movement
See the attached video, this is the last minute of a repeated probe accuracy before it fails Before this run I'd done a couple 100 sample runs without issue.
69 replies
RRCRat Rig Community [Unofficial]
Created by JaminCollins on 9/6/2024 in #ratos-support
RatOS 2.x + Beacon ignoring configured offset and discarding offset at print end
I believe I've accurately followed the steps outlined here: https://github.com/HelgeKeck/RatOS/blob/documentation_v2.1/site/docs/configuration/beacon_contact.md#6-first-print-and-fine-tuning I've printed a simple single layer print, baby stepped the offset, and then executed SAVE_Z_OFFSET. Doing so resulted in the following output on the console:
Beacon model offset has been updated, new value is -0.00524
You must run the SAVE_CONFIG command now to update the
printer config file and restart the printer.
Beacon model offset has been updated, new value is -0.00524
You must run the SAVE_CONFIG command now to update the
printer config file and restart the printer.
Which is, in fact, reflected in my printer.cfg:
#*# [beacon model default]
#*# model_coef = 1.476854667586476,
#*# 1.8257187670592463,
#*# 0.8000676386844287,
#*# 0.3652225333958514,
#*# 0.2946874145303699,
#*# 0.27036577839966525,
#*# -0.13702065685017686,
#*# -0.22685839327522975,
#*# 0.16605067102751772,
#*# 0.167889650961572
#*# model_domain = 1.8412885714875363e-07,1.939865108701818e-07
#*# model_range = 0.200000,5.000000
#*# model_temp = 50.332679
#*# model_offset = -0.00524
#*# [beacon model default]
#*# model_coef = 1.476854667586476,
#*# 1.8257187670592463,
#*# 0.8000676386844287,
#*# 0.3652225333958514,
#*# 0.2946874145303699,
#*# 0.27036577839966525,
#*# -0.13702065685017686,
#*# -0.22685839327522975,
#*# 0.16605067102751772,
#*# 0.167889650961572
#*# model_domain = 1.8412885714875363e-07,1.939865108701818e-07
#*# model_range = 0.200000,5.000000
#*# model_temp = 50.332679
#*# model_offset = -0.00524
However, when a print starts, I see:
RatOS | BEACON: Nozzle expansion offset of 0.044757mm applied to T0
RatOS | BEACON: Nozzle expansion offset of 0.044757mm applied to T0
And sure enough, the first layer doesn't squish/adhere very well. Furthermore, if I babystep back to my above value, things look good. Until the next print. An additional item of note is that it appears any babystepped value is cleared at the end of the print. So, it seems, one must execute SAVE_Z_OFFSET during the print.
339 replies
RRCRat Rig Community [Unofficial]
Created by JaminCollins on 8/22/2024 in #fix-my-print
terrible embossed lettering
No description
5 replies
RRCRat Rig Community [Unofficial]
Created by JaminCollins on 5/3/2024 in #ratos-support
LGX Lite configured (by default) to run HOT (out of spec)
15 replies
RRCRat Rig Community [Unofficial]
Created by JaminCollins on 5/1/2024 in #fix-my-printer
Beacon revH - bed mesh hangs klipper/mainsail
Just added a Beacon revH to my RR400. Updated the printer.cfg, removed the references to the previous probe (klicky). The probe itself seems to work fine for Z homing and Z tilt calibration. However, when I try to do a bed mesh, the printer becomes unresponsive at the end of the scan. I've tried various configurations for the bed mesh. I've seen others use as high as a 50x50 mesh with the beacon probe. I've tried lowering the probe_count all the way to 7x7.
[bed_mesh]
speed: 200
horizontal_move_z: 15
# 10 off each max range, plus the y-offset
mesh_min: 10, 37
mesh_pps: 390, 390
#algorithm: bicubic
#mesh_max: 380, 380
#probe_count: 50, 50
#probe_count: 15, 15
probe_count: 7, 7
[bed_mesh]
speed: 200
horizontal_move_z: 15
# 10 off each max range, plus the y-offset
mesh_min: 10, 37
mesh_pps: 390, 390
#algorithm: bicubic
#mesh_max: 380, 380
#probe_count: 50, 50
#probe_count: 15, 15
probe_count: 7, 7
Attached is a klippy.log that should show the startup, homing, z tilt, and attempted bed mess (default-testing). The system appears hung once the following appears in the klippy.log:
Sampled 27705 total points over 2 runs
Samples binned in 49 clusters
Sampled 27705 total points over 2 runs
Samples binned in 49 clusters
With the lower number of samples it does eventually continue, memory usage approaches 1G. Then Mainsail goes into a retry loop, and Mobileraker goes into an endless notification loop about the printer now being in Standby. The host system is an RPi4 2G.
11 replies