@SputnikOC3d

Hi,

would you share the stl from your umbilical-1lc-mount-combination?

Thank you very much,
Pierre

@justus2342 i dont know the answer, but i am not worried about it since 8gb SD cards are so cheap and common now, even if it accelerates the shelf life, i can live with replacing the SD card once every 2 years.

but its a good question. @dc42 may know.

Will it be possible to determine backlash with the X-carve XYZ touch probe?

I'm sure there's a macro to find the center of the XY-hole, but can it spit out backlash numbers, too?

@dc42
Guess that's all true, and how i'm currently doing it.

The reasoning on my end was to have it as a safeguard more than anything. To avoid a 250+ degree nozzle kissing the bed.

@deckingman
Like i touched on above i was thinking down the lines of avoiding having a too hot nozzle touching the bed surface. I run my nozzle at 150c when probing, to soften any oozed plastic, but I also don't want to have it much hotter than that since I'm quite sure it will leave marks in the PEI over time.

That said, i will keep doing it in the macros ✌️ And rather look into polishing the safeguards/how it's handeled in the macros.

@justus2342 for CoreXY and similar printers using linear kinematics, per-motor limits are already applied. However, we have received a complain about this, because Klipper doesn't apply per-motor limits; which means that if you configure RRF and Klipper with the same M201 and M203 limits then Klipper prints faster. In fact RRF should be configured with larger limits than Klipper, to benefit from the greater speeds available when both motors contribute to XY movement.

Good morning @DC42,

Thank you very much, you don't know how glad I am to hear it, I'm looking forward to try beta2, I'll be preparing my codes to test it.

It's really wonderful to work with you

Best regards
Aitor

@dc42
Thanks for implementing this so quickly.
Can we also have the other math functions extended as time permits?
abs()
mod()
etc...

I know Prusa slicer and Cura both warn when the print is too big for the printer. AFAIK, all slicers will prevent you from generating gcode files that go beyond the print limits of the machine- that's why they want to know how big the bed is and the maximum Z dimension when you configure the printer.

If you're trying to run gcode generated for a different machine on your printer all bets are off. For that I'd say either don't do it or write a simple processor that reads the coordinates of all the moves in the gcode file and looks for any that are beyond the limits of your printer. Movement beyond axis limits is only one problem. There could be all sorts of other problems buried in the gcode, such as print speed or acceleration being too high for the printer.

If you're trying to detect layer shifting while printing, you'll need some limit switches that detect movement beyond axis limits because in a layer shifted print, the controller thinks everything is fine, even if it sends the extruder and/or bed beyond the limits of an axis. Keep in mind that layers can shift without moving beyond axis limits, so those added switches may not do any good. Some Markforged printers detect layer shifting by rehoming X and Y axes after every layer. If the extruder and/or bed travels the correct distance to reach home, the print isn't shifted and it's OK to print the next layer. I ran an experiment with this idea when I installed optical endstops in my corexy printer. The problem with rehoming every layer is it adds significantly to the total print time even as it minimizes wasted filament. You could rehome every 10th layer- that would reduce time spent rehoming but allow some waste of filament if the print was shifted.

My printer doesn't shift, ever, because I use conservative settings and maintain the mechanism. If you're experiencing frequent layer shifts, maybe there's a hardware problem that needs to be addressed, or it's time to adjust your expectations of the printer's performance limits and reconfigure accordingly.

@Merlin246 here are some possible workarounds:

Reduce the overshoot by increasing the M307 R parameter. This will only help if the bed surface temperature overshoots. If the temperature sensor is close to the heater and the surface temperature lags the sensor temperature then it may actually make things worse.

Many slicers have the option to wait until the bed is at temperature before they heat the hot end. The hot end heating time may be enough for the bed temperature to stabilise.

Typically, if the slicer sees a heating command in your start GCode, it won't generate the heating command itself. So you should be able to put the bed heating command followed by a G4 delay in your slicer start GCode.

@jay_s_uk thanks for a great suggestion! Will implement ASAP 🙂

@OwenD said in Speed Based Pressure Advance:

@CCS86
Just curious...
Do your PA tests at various speeds include the use of non linear extrusion?
I would think that for PA to be consistent over a range of speeds that first the volume extruded would have to be consistent.

I do not use non-linear extrusion. I tested for this and could never demonstrate the need for it within the range of volumetric flow rates that I use.

@dc42
Exactly, that was a problem I had with the hashPrinter. I wanted to use the "mini-Z axis" for z-hop and mesh levelling. But the firmware for simultaneous printing is still in the making.
Two tools using the same heightmap at different XY-coordinates simultaneously is another hurdle.

@mher a new function fileexists(name) is already implemented in the RRF 3.5 source code.

@sebkritikel Perfect. Thought it was an admin setting and not a user setting.

If the mesh itself doesn't change much once the tilt is resolved, you could just load the saved heightmap rather than re-doing the mesh. G29 S1.

If you want to save a mesh to a new file without overwriting the default, you can specify a file name.

See the detailed usage of G29 here: https://docs.duet3d.com/en/User_manual/Reference/Gcodes#g29-mesh-bed-probe

If your dual Z motors each have their own driver, you could automate the tilt correction: https://docs.duet3d.com/en/User_manual/Connecting_hardware/Z_probe_auto_levelling

It's hoped to be in 3.5, but probably not for the initial beta release.

@tekstyle said in force cancel print after a M190 P0 S60 command?:

sometimes, I mess up and forget things the moment i started a print and I need to cancel it altogether. the only problem is it won't let me interrupt the bed heating up to target temperature.

This is already on my list to fix in RRF 3.5.

@dc42 It's working! The sensorless homing does indeed work for the extruders as suggested. Thanks again for the support. 😄