Rat Rig Community [Unofficial]•12mo ago

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•12mo ago

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...

miklschmidt•12mo 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•12mo 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.

harsh-harlequin•12mo 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•12mo 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.

harsh-harlequin•12mo 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•12mo ago

btdt..well ATDT

harsh-harlequin•12mo ago

alternative that always works is to probe the whole bed of course

ptegler•12mo ago

(Am There Doing That) so ..same logistics when I asked previously about this same priming location issue

harsh-harlequin•12mo 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•12mo 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•12mo 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}

harsh-harlequin•12mo 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•12mo ago

how a bout a simple post processor script for orca to correct to a xy -z vs xyz move

miklschmidt•12mo 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.

harsh-harlequin•12mo ago

ah - i see - you mean do the xy move as well aside lift z that will work

miklschmidt•12mo ago

indeed

harsh-harlequin•12mo ago

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

miklschmidt•12mo ago

Basically just

G1 Z1
G1 X{params.X1} Y{params.Y1} F36000

G1 Z1
G1 X{params.X1} Y{params.Y1} F36000

Should do the trick Yeah whichever point you want 🙂

harsh-harlequin•12mo ago

what is the parameter for default speed moves in ratos btw? (to use for the F part)

miklschmidt•12mo ago

So it would be like

[gcode_macro START_PRINT_INIT]
gcode:
  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}
  G1 Z1 F6000
  G1 X{params.X1} Y{params.Y1} F36000

[gcode_macro START_PRINT_INIT]
gcode:
  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}
  G1 Z1 F6000
  G1 X{params.X1} Y{params.Y1} F36000

macro_travel_speed

miklschmidt•12mo ago

https://os.ratrig.com/docs/configuration/macros#speed

Configuring RatOS Macros | RatOS

RatOS comes with a bunch of flexible predefined macro's that can be customized via variables and macro hooks.

miklschmidt•12mo ago

there's one for z too

harsh-harlequin•12mo ago

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

miklschmidt•12mo ago

yeah

harsh-harlequin•12mo ago

is there proper way to change the macro to not interfere with the ratos updates?

miklschmidt•12mo ago

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

harsh-harlequin•12mo ago

thx

miklschmidt•12mo ago

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

Gaming

Programming

Prime line/blob position control?