@Adamfilip When I installed optical X and Y endstops on my printer I ran a test of the precision of those stops. I added some custom gcode to the slicer so that the machine would rehome X and Y at every layer change. This function can be used in some MarkForged printers to detect layer shifting (a lot of their filament is very expensive, so you'd want to stop a shifted print early). In the MarkForged printers, they count steps to the home position and if the number is off, stop the print because it has shifted.

The result of my test was that my optical endstops were very precise, but homing at every layer change adds a lot of extra time to a print- typically 10-20 sec per layer which adds up over hundreds of layers. Homing at every 10th layer would be more practical.

"Autorecovery from step loss" isn't really recovery because it doesn't fix the problem causing the step loss. It just starts the next layer at the proper position, but that layer may also shift.

You've created a heightmap based on the photos, but you don't have it loaded when you've sent M122. It's only loaded after creating a fresh one with G29, or loading a saved one with G29 S1.

Okay, I've got it sorted...

What was confusing me is that I was trying to use it the G30 P0 ... set the exact same way as I do on my printer that has the DC42 IR probe, which doesn't deploy. It does work the way that I was using it, though I can see from the "proper" use of it that I am doing it a bit weird, by manually accounting for the probe offset.

@droftarts said in BLTouch driving me bonkers...:

usually used in a macro to level a bed with multiple independent motors.

Which is exactly what I wanted to use it for, as I have 3 independent Z motors (On drives 2, 3, and 4)

Took me a while to get back to this, but it's all good now.

Well i received the new nema 17 today and installed then , very close of achieving the speed i want , i did double my acceleration from 9-10k to 19k . only things stopping me right now i think is the duet 3 version i have that only support 32V , if i had the newer version that support 48V i would have achieve my goal here . i j ust need to tweak my printer a bit more and this build will be done. than after i guess the next build for high speed lol

Thank you, @T3P3Tony

I was glad to help where I could, after all the help I had had!

What firmware version were you using before updating?

Did you also update your DWC files?

At this point I think you should probably use Bossa to flash the latest firmware directly, and then manually update the DWC files on the SD card.

Use this procedure to flash the firmware: https://docs.duet3d.com/en/User_manual/RepRapFirmware/Updating_firmware#fallback-procedure-2

Use this firmware file: https://github.com/Duet3D/RepRapFirmware/releases/download/3.4.5/Duet2CombinedFirmware.bin

Then update the DWC files by putting the SD card into your PC and extract the contents of this zip file into the WWW folder on the SD card: https://github.com/Duet3D/RepRapFirmware/releases/download/3.4.5/DuetWebControl-SD.zip

When you are all done and connected to DWC, upload this zip file to the system tab in DWC. https://github.com/Duet3D/RepRapFirmware/releases/download/3.4.5/Duet2and3Firmware-3.4.5.zip

So suppose I run firmware 3.4.5, I have my heater tuned (several times) and in 90% of cases all is fine. In the last 10% of the cases, the heater faults out during the initial stages of heating from cold to operating temperature (usually closer to the final temperature). The error is always something to the effect of 'the heating rate is lower than what is expected'.
Once operating temperature is achieved, the heater seems totally reliable.
M307 gives me R,D,E and K parameters to play with.
What parameter(s) should I tweak slightly (and in which direction) to signal the firmware that a slightly lower heating rate is ok while at the same time not messing with the perfectly working situation once the heater is at operating temperature?
As it happens, this is for the hotend and not the chamber heater but the question really applies to any heater.
Can I just reduce my R value a bit (which seems to primarily be relevant when the heater is cold but that is not where things fail) or will that screw with things at operating temperature.
My apologies if this post is seen as a thread highjacking - it is not meant to be and I think the question is relevant in the spirit of the original question.

@Ivan-Miranda glad it's sorted!

@Phaedrux No it has not done it since. I am running 3.4.5. I think it created the folder. I have a similar error for a filaments folder that I think I can fix not that I better understand the directory.

See my post here explaining it.

https://forum.duet3d.com/post/306984

@dc42
Ok, I can try, even if I've never put my hand to the Reprap firmware I think I can do it. But I try to make another request: is it possible to insert the retraction in the special movements managed by M201.1? also would it be possible to include in the special movements also the return to position between the two probes if, for example, 2 passes are used with the Bltouch?

@achrn No need to be sorry. BTW, after thinking about it, there’s a real use case when you specify filament directories: there, you can provide multiple (partial) config.g files.

https://docs.duet3d.com/en/User_manual/RepRapFirmware/Updating_PanelDue

@JoergS5 thank you, I'm in the learning stage myself. This is why I thought it would be a good idea to seek outside assistance.
Cheers for the link gives me plenty of information to go by.

@Diamondback thanks! lets hope a pattern does not appear!

@Phaedrux Hi, this printer was originally mine, and we debugged it.

The issue turned out to be that the crash had left the front-left corner of the plate much higher than the center of the bed (three Z steppers on a D-Bot, front left and right on same controller, not tied together with a single belt (obviously)). The macro would probe center of bed first to establish a "zero", then build the height map. Because the plate was so askew, on deploy the probe would hit the plate immediately in that front left corner, causing the fail.

While the root issue was the corner being too high, the fail could be avoided by moving to Z=10 after the first probe, leaving room for the probe to deploy. So that was added to the macro.

@droftarts This fixed it, thank you!
edited config.g to M671 X223:-30 Y0:0 S1

@Phaedrux
Thanks guy, the problem was that I didn't know that when you do a G32 that then it goes to call the BED.G
the probe does not activate in the moment of fast descent towards the floor, but it activates in the moment in which it proceeds with the probing coordinates, I thought that the probe activated in the moment in which the G32 command is given, while if the command is given G30 followed by the coordinates the probe is active