RatOS 2.0 Euclid Probe odd behaviour on Print
Installed a Euclid probe and was set to run my first print.
RatOS ran primeline as expected but then proceeded to grab the Euclid probe BEFORE it commenced the print with the Euclid probe still attached!! Hmmmm. Hit the emergency stop just in time.
18 Replies
This is not reproducible on stock RatOS v2.0 so.. what changes did you make
Post your printer.cfg
fascinating-indigo•16mo ago
What does your start gcode look like?
Your config is a bit of a mess and you're missing a bunch of the toolboard includes
All your custom stuff should be below "USER OVERRIDES"
It's hard to compare things because you deleted a bunch of stuff
But i can't see anything that would cause the issue you're describing so i'm suspecting your slicer setup
fascinating-indigo•16mo ago
Ok will do some checking tonight.
fascinating-indigo•16mo ago
Reworked the whole printer configuration file and still get the same weird behaviour. Note for my Hemera I have the Euclid dock on the RHS looking from the front. I also shifted the primeline to x=max and y=150mm to ensure the printer head was at a safe distance from the Euclid dock.
fascinating-indigo•16mo ago
Is there new slicer start Goode settings for RatOS 2.0?
No. But please past your start gcode
Also post your klippy.log
Something isn't right
Wait
RatOS ran primeline as expected but then proceeded to grab the Euclid probe BEFORE it commenced the print with the Euclid probe still attached!! Hmmmm. Hit the emergency stop just in time.Do you mean it accidentally moves over the euclid dock? Or does it do the actual 4 point euclid deploy movement? also i strongly recommend using primeblob over primeline.
fascinating-indigo•16mo ago
START_PRINT EXTRUDER_TEMP=[first_layer_temperature] BED_TEMP=[first_layer_bed_temperature]
fascinating-indigo•16mo ago
fascinating-indigo•16mo ago
I'll change prime line as you suggest and give it another go.
fascinating-indigo•16mo ago
Everything here looks fine. I'm gonna need you to film whats happening, because it isn't making much sense at this point.
fascinating-indigo•16mo ago
So the printhead didn't move directly to the primeblob coordinates. The movement to the primeblob coordinates was 1) maxed-x followed by 2) y-axis move which resulted in the printhead being placed over the euclid dock and with the y move the printhead picked up the probe. Would moving the primeblob to say the middle of the LHS of the print bed alleviate this issue?
fascinating-indigo•16mo ago
I do have another solution but it will take time to design and implement. Need to setup a retractable Euclid dock.
Moving primeblob did the trick.
Thanks for your help. It's a steady learning process.
Yeah there's no bug here. Your dock and probe mount is in the opposite side of where it's intended to go. You have a deadzone around the dock where you can't print because you risk picking up the probe.
Your primeblob position is weird. Reset to the default and then switch x to the other side and you should be good to go.
to clarify:
variable_nozzle_prime_start_x: "min"
and your problem is solved.
This is intended. It's moving along the side of the plate to avoid accidents in case you messed up your Z offset, etc.
See the changelog: https://os.ratrig.com/changelog#minor-changes
Changelog | RatOS
RatOS V2.0
Switch sides of the primeblob and you're good to go.
fascinating-indigo•16mo ago
Missed the changelog. Thanks and done for moving the primeblob to the LHS. Did the trick nicely. I put the Euclid on the RHS of the Hemera body because of ease of mounting. I only lose movement in a small zone around the Euclid dock itself. With the Hemera tool head it looks like the only thing I would gain by mounting the Euclid probe on the LHS is additional complication.