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
miklschmidt
miklschmidt2y ago
This is not reproducible on stock RatOS v2.0 so.. what changes did you make Post your printer.cfg
conscious-sapphire
conscious-sapphire2y ago
miklschmidt
miklschmidt2y 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
conscious-sapphire
conscious-sapphire2y ago
Ok will do some checking tonight.
conscious-sapphire
conscious-sapphire2y 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.
conscious-sapphire
conscious-sapphire2y ago
Is there new slicer start Goode settings for RatOS 2.0?
miklschmidt
miklschmidt2y ago
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.
conscious-sapphire
conscious-sapphire2y ago
START_PRINT EXTRUDER_TEMP=[first_layer_temperature] BED_TEMP=[first_layer_bed_temperature]
conscious-sapphire
conscious-sapphire2y ago
conscious-sapphire
conscious-sapphire2y ago
I'll change prime line as you suggest and give it another go.
conscious-sapphire
conscious-sapphire2y ago
miklschmidt
miklschmidt2y ago
Everything here looks fine. I'm gonna need you to film whats happening, because it isn't making much sense at this point.
conscious-sapphire
conscious-sapphire2y 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?
conscious-sapphire
conscious-sapphire2y 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.
miklschmidt
miklschmidt2y ago
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.
Want results from more Discord servers?
Add your server