Prime line/blob position control?

Is it possible to control the prime line/blob position to be next to the part with adaptive mesh on, rather than x-max,0 corner?
29 Replies
miklschmidt
miklschmidt•15mo ago
Adaptive Meshing (BETA) | RatOS
RatOS comes with it's own adaptive meshing (functionality was previously handled by PAM by Helge Keck), similar to KAMP. When enabled and configured in your slicer, RatOS will only probe the print area and your configured probe location, potentially saving a lot of time on smaller prints on bigger printers. RatOS will keep the resolution of your...
miklschmidt
miklschmidt•15mo ago
I've yet to see a reliable implementation of adaptive purging. There are always cases where it'll fuse with the parts or in case of prime blob collide with the duct.
miklschmidt
miklschmidt•15mo ago
That said, if you want to move your prime line/blob, use the macro variables: https://os.ratrig.com/docs/configuration/macros#nozzle-priming
Configuring RatOS Macros | RatOS
RatOS comes with a bunch of flexible predefined macro's that can be customized via variables and macro hooks.
leobg
leobg•15mo ago
blob is going to be a problem indeed, if nearby. There is always case when blob would collide with print head though. It is just a matter of model geometry. Line is safer option in most cases. I wonder if possbile to do conditional priming - position Y-10 on the y-min of the subject and if negative (outside print area limits) - skip the priming at all for safety? (or X - based on orientation of prime line)
ptegler
ptegler•15mo ago
I just asked this a day/2 ago myself...I understand MK's logic now though, and defaults. The blob does work better ..as it assists cleaning the nozzle of any debris. I'd considered 'conditionals' to set the primeblob/line location but in the end as you wear away that one location on your print bed you can always just move the blob a mm or 2 to the left or right as desired. My own testing really did not show any advantage to moving the prime line closer to the printed part, other than removing the one mesh point the sys takes over at the priming location vs where your part is printed.
leobg
leobg•15mo ago
if your bed is less then ideally flat and is large (ie 500), that far location tends to cause nozzle drag over the bed when advancing from the priming position to where print happens to start. priming goes well thanks to the probe point there, but the unprobed area when printing something small is large enough to be an issue this problem goes away for me if disabling prime alltogether and purging in the skirt, but that isn't always best. only with orca slicer though, as it advances from pre-heat position to prtint starting point by x, y and z simultaneously
ptegler
ptegler•15mo ago
btdt..well ATDT
leobg
leobg•15mo ago
alternative that always works is to probe the whole bed of course
ptegler
ptegler•15mo ago
(Am There Doing That) so ..same logistics when I asked previously about this same priming location issue
leobg
leobg•15mo ago
i am laying out the reason of why i am suggesting this for consideration in ratos 🙂 i tried searching around but didn't get a good hit
ptegler
ptegler•15mo ago
ditto on the logisitcs.... hmmm... perhaps a secondary or tertiary probe point between prime and print (would raise the nozzle until over the print area
miklschmidt
miklschmidt•15mo ago
if your bed is less then ideally flat and is large (ie 500), that far location tends to cause nozzle drag over the bed when advancing from the priming position to where print happens to start. priming goes well thanks to the probe point there, but the unprobed area when printing something small is large enough to be an issue
This is a valid point. I haven't experienced it myself yet, but i got really close. I have a simple fix for that though. Raise the toolhead after the prime blob and travel to the edge of the print area at the end of start print. That would fix it. I couldn't come up with a reliable solution for adaptive purging/priming, but if you want to try stuff out, you could just make a START_PRINT macro wrapper and manipulate the probe start x/y coordinate variables and just call START_PRINT when done. like
[gcode_macro START_PRINT_INIT]
gcode:
; do you thing here
START_PRINT X0={params.X0} X1={params.X1} Y0={params.Y0} Y1={params.Y1} EXTRUDER_TEMP={params.EXTRUDER_TEMP} BED_TEMP={params.BED_TEMP} CHAMBER_TEMP={params.CHAMBER_TEMP}
[gcode_macro START_PRINT_INIT]
gcode:
; do you thing here
START_PRINT X0={params.X0} X1={params.X1} Y0={params.Y0} Y1={params.Y1} EXTRUDER_TEMP={params.EXTRUDER_TEMP} BED_TEMP={params.BED_TEMP} CHAMBER_TEMP={params.CHAMBER_TEMP}
leobg
leobg•15mo ago
would that not cause "dirty" situation with ratos? i only need to lift around 0.2 to avoid dragging entirely (it is not that bad, but i can clearly hear the nozzle zipping trough surface). trick may not work in all slicers though as superslicer for example will advance to 0.2 (or whatever initial LH is) on z before moving x and y. would work fine on orca though (which advances to start print position on all axises at the same time
ptegler
ptegler•15mo ago
how a bout a simple post processor script for orca to correct to a xy -z vs xyz move
miklschmidt
miklschmidt•15mo ago
No that goes in printer.cfg in user overrides and you just called START_PRINT_INIT from your slicer instead of START_PRINT It'll work in all slicers. Slicer doesn't take over until after START_PRINT has moved the nozzle to the print area.
Want results from more Discord servers?
Add your server