@fcwilt I didn't understand now I understand perfectly thanks. you have the sailing canoe and pedals, beautiful

@fcwilt It worked. Thank you so much!!

@dc42 will try it later, thanks

After extensive testing, I concluded that something was distorting my sensor reading. Since I had two SameSky CUI AMT10E3 capacitive encoders.
WhatsApp Image 2025-03-14 at 20.22.22.jpeg

I set them to 2500PPR and mounted them. Now closed loop runs whisper quiet. Here are two examples:

stealthchop.mp4
closed loop.mp4

@kazolar said in Odd bed mesh:

Wondering if there are plans to true zero like beacon/cartographer do to auto calibrate my understanding all they're doing is measure variations in eddy currents until they stop changing meaning nozzle touched the bed.

From the 3.6.0-beta.3 release notes:

[Duet 3] Experimental support for using supported scanning inductive Z probes (i.e. Duet3D Scanning Z Probe and TOOL1RR tool board) in touch mode is available. This support is enabled using the new M558.3 command. See https://docs.duet3d.com/en/User_manual/Tuning/scanning_z_probe_calibration#using-the-szp-in-touch-mode-to-set-z-height. Use it with caution!

@aceranic said in New XZmotors problem:

Is there a guide enywhere for the configuration of this board?

Just the linked BTT PDF, and https://docs.duet3d.com/en/User_manual/Connecting_hardware/Motors_connecting_external

Ian

It's likely that your end stop wiring is picking up interference.

https://docs.duet3d.com/en/User_manual/Connecting_hardware/Sensors_endstops#interference

@fcwilt I think both of those would work too.

@Tech_Sam03 have you tried slightly lower P and slightly higher D?

@jltx Without the K1 it would have been using the other probe, as K0 is the default. I believe that's been around since RRF 3.01-RC5 (see https://docs.duet3d.com/en/User_manual/Reference/Gcodes#g30-single-z-probe) so I think either your probe config has changed, or you were using G30 K1 ... before.

Note that the G31 K1 ... probe offsets is commented out in your config.g, so it will be using the default values.

Ian

@kuon @T3P3Tony Yes something like that - I think in Klipper - you can specify in a Macro - Rename_existing: - That renames the original command, and then you can then put some logic before or after it - and if required still call the original command using its new name.

For example in the SV09 Klipper config the M106 fan control command has been overridden to cause both print head cooling fans to turn off and on at the same time.

In the standard SOVOL SV08 configuration the following commands have all be overriden.
M109, M190,M106, M107, M600.

So in the example of M203 you could either completely disable it, or have some logic that set some limits or circumstances when it could be called.

@sebkritikel
Silicone tip would be better ofc, that bed wont go over 130 °C at 24v, The heating element is glued to the underside of the bed.

@engikeneer

Thanks for the feedback.

I shall proceed as you suggest.

Frederick

A quick update: did a test with my concrete macros on 3.6beta4 and the same delay/pause occured.

Need to fiddle around more with the code to understand which combination/code-part actually is causing the delay. More to test ... 😉

@Snippy all working now?

@dc42 I ended up removing M596 and M486 instructions indeed, they were causing issues in my case, where i was restarting the print with T1 instead of T0. Thank you for your replies

@jay_s_uk Thank you for the really helpful information. You were absolutely right, this was the solution.

@jay_s_uk
There is no Q value, tried 500, no effect, 15000 fan works from 85% on dwc to 99% on fan