ptegler
RRCRat Rig Community [Unofficial]
•Created by ptegler on 2/1/2024 in #fix-my-printer
s2vsb=1(ShortToSupply_B!) but file triggered !??
4 replies
RRCRat Rig Community [Unofficial]
•Created by ptegler on 8/9/2023 in #ratos-support
system stopped writing files!
24 replies
RRCRat Rig Community [Unofficial]
•Created by ptegler on 7/24/2023 in #ratos-support
so what's the trick for klicky!
64 replies
RRCRat Rig Community [Unofficial]
•Created by ptegler on 7/23/2023 in #ratos-support
crowsnest issues? logs says all ok...but then fails
12 replies
RRCRat Rig Community [Unofficial]
•Created by ptegler on 7/21/2023 in #ratos-support
klicky probe drawings reversed??
was about to setup a klicky probe.... if the dock is mounted above the left front Z screw (most available printable docks avail for the V-Core-3?) aren't the drawings for the motion sequences reversed on the page at https://os.ratrig.com/docs/guides/stowable-probes ??? Wouldn't STOWING the probe (move 2 - > 3) be a X+ to X- motion, then a Y- to Y+ (3 -> 4) motion to remove the probe from the carriage arm (leaving the probe docked)? But THAT sequence is documented as DEPLOYMENT, not stowing.
-OR- shouldn't there be some annotation on the page if the 'as pictured' sequences are for a probe dock mounted on the rear (near elec panel) with a probe under the air horns.... and NOT for a front left mounted probe doc.? So I'm a bit confused, which I should configure for a front mounted, left side deploying/stowing routine. ...or as usual have I missed something here?
-OR- shouldn't there be some annotation on the page if the 'as pictured' sequences are for a probe dock mounted on the rear (near elec panel) with a probe under the air horns.... and NOT for a front left mounted probe doc.? So I'm a bit confused, which I should configure for a front mounted, left side deploying/stowing routine. ...or as usual have I missed something here?
8 replies
RRCRat Rig Community [Unofficial]
•Created by ptegler on 7/20/2023 in #fix-my-printer
Z_tilt vs mesh vs those fighting a flat mesh grid
..wasn't sure where to put this so figured it might help some people getting 'potato chips' as bed meshes.
Yes...oddball basis here...playing with a brand new 300 bed, but mounted in a 500 frame. (IDEX style bed support)
I'm getting GREAT repeatability on my mesh. Sub 0.1mm no problem. I ran into something quite interesting, that is also a carry over from past Q's I've posted here trying to understand some aspects of Klipper in general. The image below, is a screen cap of a cluster of screen caps. Two z_tilts and what they were set to, and two 3x3 bed_mesh calibrations You'll note the two meshes are within 0.009mm of each other. (goes to the repeatability of the probe used itself as well) On previous 'play times' I'd experimented with reversing the 3 z_tilt points...EG: instead of front left->rear center->front right, I swapped the z_tilt probe points to left rear->front center->right rear. In this experiment I was trying to understand the final relationships created by the post z_tilt automated adjustments, on the mesh grid resulting from those z_tilt settings. what is interesting, is there is some math anomalies that must exist somewhere here (and this is my Q here ... is what am I missing?) The z_tilt adjustments made between the two sets of point configurations, does indeed result in a bed level opposite one another. Ok... that makes sense. But the math part that intrigues me.... the z_tilt adjustments made are 1/10th the mesh grid variation, and barely approach the difference between the two meshes (~0.009 mesh diff z_tilt variations being less in both cases) Yes, the system was re-homed after printer.cfg edits to change the z_tilt probe points. This sequence was repeat 6 times today. What is pictured, is the worst I could get.
I'm getting GREAT repeatability on my mesh. Sub 0.1mm no problem. I ran into something quite interesting, that is also a carry over from past Q's I've posted here trying to understand some aspects of Klipper in general. The image below, is a screen cap of a cluster of screen caps. Two z_tilts and what they were set to, and two 3x3 bed_mesh calibrations You'll note the two meshes are within 0.009mm of each other. (goes to the repeatability of the probe used itself as well) On previous 'play times' I'd experimented with reversing the 3 z_tilt points...EG: instead of front left->rear center->front right, I swapped the z_tilt probe points to left rear->front center->right rear. In this experiment I was trying to understand the final relationships created by the post z_tilt automated adjustments, on the mesh grid resulting from those z_tilt settings. what is interesting, is there is some math anomalies that must exist somewhere here (and this is my Q here ... is what am I missing?) The z_tilt adjustments made between the two sets of point configurations, does indeed result in a bed level opposite one another. Ok... that makes sense. But the math part that intrigues me.... the z_tilt adjustments made are 1/10th the mesh grid variation, and barely approach the difference between the two meshes (~0.009 mesh diff z_tilt variations being less in both cases) Yes, the system was re-homed after printer.cfg edits to change the z_tilt probe points. This sequence was repeat 6 times today. What is pictured, is the worst I could get.
13 replies
RRCRat Rig Community [Unofficial]
•Created by ptegler on 7/20/2023 in #ratos-support
should homing be using offsets like z_tilt?
Z homing, centers the nozzle , so probes offset (not dead center) for the final Z homing. Z_Tilt.... uses the probe points from printer.cfg., as to for the mesh point locations. Why doesn't normal homing use that same offset.
I pose the question as what if there is a mesh diff between the offest point and the Z homing centered point that one would think sets the ref for the mesh center. Wouldn't that possibly add to mesh thickness issues across the bed?
I pose the question as what if there is a mesh diff between the offest point and the Z homing centered point that one would think sets the ref for the mesh center. Wouldn't that possibly add to mesh thickness issues across the bed?
18 replies
RRCRat Rig Community [Unofficial]
•Created by ptegler on 7/2/2023 in #ratos-support
smaller x/y min/max vs bed size for z-tilt
wondering about the effects of bed min/max being far smaller than Z screw positions.
I'm wondering if the z-tilt comp will work properly if/when the bed min/max for meshing is far smaller than the zscrew positions are EG: 200 bed size bed in a VC500 frame.
will RO still correctly add/sub z-tilt correctly?
6 replies
RRCRat Rig Community [Unofficial]
•Created by ptegler on 7/1/2023 in #ratos-support
Is there a straight forward way to change prime blob location?
I managed to mess up my PEI sheet right where the prime blob lays down. Is there a way to move the prime location just a mm or 2 left or right of the default location?
2 replies
RRCRat Rig Community [Unofficial]
•Created by ptegler on 6/30/2023 in #fix-my-resonance
A resonance study - test series
27 replies
RRCRat Rig Community [Unofficial]
•Created by ptegler on 5/17/2023 in #ratos-support
Can variable_bed_mesh_profile be set in the slicer?
quandary here.... for different bed temps (printing different materials) , resulting in different meshes.... can variable_bed_mesh_profile be called from the slicer g-code to load an appropriate mesh...rather than just setting it in printer.cfg?
tia
17 replies
RRCRat Rig Community [Unofficial]
•Created by ptegler on 5/11/2023 in #ratos-support
OK...what did I miss? (latest updates)
first time ever getting a move out of range. This is the first print since updating everything a couple days ago. RO 2 VC500
Octopus Pro mcu version: v0.11.0-198-g33b18fd6 host Version: v0.11.0-198-g33b18fd6-dirty homing, z-tilt even PAM mesh all ran fine. When it went to purge, the purge bead was now back at the left front (??) it started purging the bead...then lifted about 5mm, kept purging (or oozing) and just sat there..... no drag off or return to bed and wipe. then I notices the console was saying move out of range. ???? Absolutely nothing changed in my config or slicer settings for this print, as it was a repeat part print. So just to check I pulled it up in my slicer and saw nothing odd. So my Q (#1) is did the latest RO updates, move the purge back to the left front corner (pre-update, last part print...it purged at the right front) Q (#2) what might I have done to have the purge start.... lift during purge... THEN hit a 'move out of range' when it should have moved Y+ and Z- to do the wipe klipper log and printer.cfg follows......
Octopus Pro mcu version: v0.11.0-198-g33b18fd6 host Version: v0.11.0-198-g33b18fd6-dirty homing, z-tilt even PAM mesh all ran fine. When it went to purge, the purge bead was now back at the left front (??) it started purging the bead...then lifted about 5mm, kept purging (or oozing) and just sat there..... no drag off or return to bed and wipe. then I notices the console was saying move out of range. ???? Absolutely nothing changed in my config or slicer settings for this print, as it was a repeat part print. So just to check I pulled it up in my slicer and saw nothing odd. So my Q (#1) is did the latest RO updates, move the purge back to the left front corner (pre-update, last part print...it purged at the right front) Q (#2) what might I have done to have the purge start.... lift during purge... THEN hit a 'move out of range' when it should have moved Y+ and Z- to do the wipe klipper log and printer.cfg follows......
6 replies
RRCRat Rig Community [Unofficial]
•Created by ptegler on 3/15/2023 in #ratos-support
Measure_linear_vibrations_range ERROR!
was doing some testing....
Tests ran fine, and generated three graphs in the /home/pi/printer_data/config/linear_vibration folder
peak_frequencies_logscale2023-03-15T10:54:15.207785.png
peak_frequencies2023-03-15T10:54:15.207744.png
relative_power2023-03-15T10:54:14.725170.png
Then the machine reset with an error see attached klippy log c-a-p (attached here)
printer.cfg section was simply
and there are three files there in that directory as listed above.
This is RO v2 on a VC500. Test appeared to (mechanically) run fine. I'm not sure why it would come up with the typical orange text system error...fix and reset screen (parts cooling fan sent to full power etc needing a reboot to continue)
anyone run into this? or is the 'range' test not functional under R) v2?
103 replies
RRCRat Rig Community [Unofficial]
•Created by ptegler on 3/14/2023 in #fix-my-printer
Overriding Nozzle Prime position
didn't want to hijack the thread.... '(nozzzzle) is there an override in RO v2 so I could move my prime blob back over to the left front? and i though PAM would move that prime to near where the print was going.... Are they related? (settings to move these)
1 replies
RRCRat Rig Community [Unofficial]
•Created by ptegler on 3/13/2023 in #ratos-support
Post calibration print homeall stops working?
homeall worked fine. Did my first real filament calibration print. Edited some params and went to start another print. HOME x worked, then stopped with the error
I manually had to move the head back out to the middle of the bed. did a HOME X, and it homed and backed off the stop as normal. Tried a HOME Y and gotthe same error again. Had to reboot and it then homed all properly. Did a HOME ALL, a z-tilt, then started a second print whic went as expected. More parma changes,,,, started a third print and the same thing happened again. X homes, then stops with the above error. See klipper log attached WTF?? very wierd
I manually had to move the head back out to the middle of the bed. did a HOME X, and it homed and backed off the stop as normal. Tried a HOME Y and gotthe same error again. Had to reboot and it then homed all properly. Did a HOME ALL, a z-tilt, then started a second print whic went as expected. More parma changes,,,, started a third print and the same thing happened again. X homes, then stops with the above error. See klipper log attached WTF?? very wierd
5 replies
RRCRat Rig Community [Unofficial]
•Created by ptegler on 3/11/2023 in #ratos-support
klipperscreen.conf ...internals moved?
under RO 1.2.x I had a bunch of menu mods in /pi/klipper_config/klipperscreen.conf
I found /home/pi/printer_data/config/klipperscreen.conf but none of my edits are in that file version under 2.0, (obviously with a fresh 2.0 install) yet my menus are showing up on my display! none of those macros work (that were in my klipperscreen.conf 'pre 2.0') Where are those files now? how do I edit those macros to get them working again, back in my menu screens https://klipperscreen.readthedocs.io/en/latest/Configuration/#menu doesn't seem to align with RO2.0s layout these days. confused here HELP!
4 replies
RRCRat Rig Community [Unofficial]
•Created by ptegler on 3/7/2023 in #ratos-support
RO v2 what's the trick to getting timelapse showing up in the config panel again?
dirs appear to be there...but control panels does not show timelapse for configuring what you want it to do (hyperlapse, layer frame count etc.)I
Tried simple install but no luck?
....aaahhh what did i miss this time?
2 replies
RRCRat Rig Community [Unofficial]
•Created by ptegler on 3/7/2023 in #ratos-support
linear_movement _vibration
Is this built into RO 2.0??
https://discord.com/channels/582187371529764864/1069063230443507763/1069063230443507763 The directory for the output at a min is now different? was /home/pi/klipper_config/linear_vibrations/ but that path is not in R) v2.0 updates? corrections? (am i out in left field?)
https://discord.com/channels/582187371529764864/1069063230443507763/1069063230443507763 The directory for the output at a min is now different? was /home/pi/klipper_config/linear_vibrations/ but that path is not in R) v2.0 updates? corrections? (am i out in left field?)
62 replies
RRCRat Rig Community [Unofficial]
•Created by ptegler on 3/7/2023 in #ratos-support
RO2 PAM
so... WHAT is the ticket to enabling PAM under RO v2 The github is getting confusing with the flipflop between RO1.2.x and 2.0 implementation.
what needs to go into printer.cfg for RO v2.0 ? tia
6 replies
RRCRat Rig Community [Unofficial]
•Created by ptegler on 3/6/2023 in #ratos-support
wierd new home all first couple after RO 2.0 update.
Will have to do a video of this one...will make a lot more sense... VERY odd moves going on.
The order and movements doing the very first 'home all after getting everything up and running under RatOS v2. were REALLY weird.
1- hit 'home all' in mainsail (trigger finger on the EMO just in case...)
2- Z drops 10mm , X slowly heads left, hits the x stop... backs off and retouches.... then Z drops another 5 or so mm and x zips quickly back to center of bed where Z drops again
3-gantry heads for Y max - taps the end stop, backs off then slowly taps again, then before zipping back to bed center yet another bed drop another 5 or so mm
4- carriage hits x250/y250 (bed center) then dances once or twice between nozzle being centered and z probe being centered, end with probes at 250,250
5- bed now has to rise nearly 50-80mm to hit the z-probe. where that all ends normally.
In short form..it seems like at the start of every 'travel' , the bed would drop as if moving out of the way for homing function.
It did it heading for X stop, then again heading back to bed center before heading for the Y stop, after the Y stop before going back to bed center for the final Z probing
very wierd.
Biggest Q though.... why did the 'home all' routine change? old 'home all' use to just got to X0 end stop, then the gantry would go to Y max end stop then diagonally right to bed center for the z-probe.
...any way to return to the old x -> y -> center -> z probe routine?
15 replies