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
No, this is on purpose, read: https://os.ratrig.com/docs/configuration/adaptive-meshing
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...
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.
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.
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)
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.
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
btdt..well ATDT
alternative that always works is to probe the whole bed of course
(Am There Doing That) so ..same logistics when I asked previously about this same priming location issue
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
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
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 issueThis 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
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
how a bout a simple post processor script for orca to correct to a xy -z vs xyz move
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.
ah - i see - you mean do the xy move as well aside lift z
that will work
indeed
perhaps advance to params.x1, params.y0 (assuming xmax,y0 is the location of prime line)
that will bring the head within the mesh right before first print commands
Basically just
Should do the trick
Yeah whichever point you want 🙂
what is the parameter for default speed moves in ratos btw?
(to use for the F part)
So it would be like
macro_travel_speed
Configuring RatOS Macros | RatOS
RatOS comes with a bunch of flexible predefined macro's that can be customized via variables and macro hooks.
there's one for z too
i guess z will hit max speed limited by printer.cfg regardless what we call there
which should be fine even if we ask for 1 meter/s
yeah
is there proper way to change the macro to not interfere with the ratos updates?
You don't need to change anything you just paste https://discord.com/channels/582187371529764864/1129425782347923611/1129499123159150672
into user overrides in printer.cfg and call that instead of START_PRINT in your slicer
It's a wrapper, so nothing is changed
thx
But in case you want to replace/change an actual RatOS macro you can just paste the entire thing into printer.cfg at the bottom, and it'll get overriden.
just like everything else