Topics created by justGuner

@justGuner said in G32 causes printhead to go beyond limits:

However, I keep on getting the following error:

Error: Some computed corrections exceed configured limit of 1.00mm: 2.404 -2.621

That's coming from your M671 command in config.g, which defines the leadscrew positions:

... M671 X-22:287 Y163:163 ...

See https://docs.duet3d.com/User_manual/Reference/Gcodes#m671-define-positions-of-z-pivot-points-or-bed-levelling-screws
You have omitted the S parameter, so it is defaulting to 1mm. If the levelling is likely to move, it's worth making the first probe have a wider limit eg M671 ... S5, with more probe lift (M558 H parameter).

Ian

@justGuner That's very odd, it must be something specific to your board/driver/wiring/steppers/config because we must have loads of users running with stealthchop and not getting random short to vin errors.

First print with the new board at relatively high speeds (compared to the previous setup) and no CAN disconnects! I guess this means that the cabling is fine.

@justGuner What does M122 b124 (or whatever board number your RRF36 is) report when it is in this "low power" state? What current setting do you have for the driver? Is this in a heated chamber? How are you determining that the power has been reduced?

@gloomyandy good to know

@justGuner ADXL345 is not supported in RRF. 3.5 supports the lis2dw which also is supported in Klipper.

I finally installed a esp32 from btt and it works just fine. Too bad I couldn't find an answer for the original question that started this thread. I might revisit this at some point in the future, who knows...

@justGuner I don't think I've ever had a problem with missed steps during a print that hasn't also been part of a much bigger problem (so recovery was not an option). I've also found that sensorless homing is more than accurate enough to operate my e3d toolchanger (which needs pretty accurate and repeatable homing to be able to pick up and drop off tools). I think the reports of problems with accuracy are somewhat overstated. Honestly I think you are more likely to have issues with false triggers from stall detection during a print (especiially if you want to operate at higher speeds), but I guess only you know what will be best with your setup. Certainly the simplest setup would just be to use endstops and ignore stall detection completely! Good luck!

@droftarts yes it's still supported at present but will be removed in a future version of RRF, hence the warning.