So I have changed my wiring from 20AWG to a single 16AWG pair (connected exactly like the documentation, a single pair from the PSU and short wires from the Duet to the Duex). The behavior has not changed, the wiring was not to blame.

Reproducing this is easy, leave the printer with the motors energized for 24-48 hours. Then eventually the I2C timeouts will take over and pause movements during a print, essentially ruining it. After that I get the random driver failures, which are likely caused by the I2C timeouts and not the root cause of the problem.

One thing that might be important, my printer uses 4 motors for Z, and all four are on the Duex. XYE are on the Duet, the rest are unused. So at any given time, 7 steppers are energized. Perhaps the recent rewrites in 2.02/2.03 have some unintended side effects?

The printer is not a new build, I have been printing for hundreds if not thousands of hours with RRF without problems. I will try going back to earlier RRF releases...

I have attached the new diagnostics output:
diagnostics.txt

You can find a complete copy of my config here.

Thanks. One last attempt at getting back on topic, what about probe type P5 and K1?

That's good to know. Then the G29 issue becomes that I must never ever forget to supply K1 with it, otherwise I will crash during probe moves and likely damage my hardware (I had a similar safety problem with RRF2 and multiple probe activation macros). If there was a pre/post macro for G29 then that could be automated and made safe. But I digress...

Does that mean there is no plan of allowing the P5 probe type to work at another index than 0? As long as there is only a single one defined in the config, of course.

I know you can only define a single P5 probe in RRF3.01. However it seems that unfortunately the probe index for P5 is also hardcoded as 0...

In my setup I have two Z probes, one is an inductive probe set up as K0 and the other is an endstop as K1. I wanted to try to enable filtering for K1 but this yields a non-working K1 probe input in DWC (the signal value never changes for K1):

M558 K0 P8 C"^zprobe.in" T18000 F120 H5 A5 S0.01 R0.2
M558 K1 P5 C"^zstop" T18000 F60 H2 A10 S0.005 R0.2

As a workaround I need to exchange K0 and K1, so that the single P5 probe is at K0. That works fine, however it is problematic since G29 always uses probe index 0 and there is no way to change this.

In the past (RRF2) I used macros to change the current probe type based on the operating context, but with RRF3 supporting multiple Z probes implicitly I no longer had to do this so it was a nice quality of life upgrade. I hope I don't have to go back to a similar setup.

@Phaedrux

It turns out varying the probe speed is an acceptable workaround. I typically level in three passes so during the first one the dive height is high but so it the probe speed, this is reduced to 4mm and 1mm for subsequent passes (with gradually slower speeds). I've been running with this for a bit and while not ideal, it's good enough.

I still think the dive depth range should be configurable, because as it is today the probe depth always has to be centered +/- the dive height at the Z offset.

Thanks for the suggestion!

Cheers,
Ben.

Increasing the dive height means a higher start position for the probe move, making it longer. What I want is to enable probing lower without raising the starting height.

Let's look at a concrete example, assuming a setup with a dive of 5mm and a trigger offset of 2.5mm:

M558 K0 P8 C"^zprobe.in" T18000 F120 H5 A5 S0.01
G31 K0 P500 X0 Y25 Z2.5

With this setup, a call to G30 will move Z to 7.5, then try to probe until -2.5, then give up if nothing was found.

If I want to increase this depth range, I need to increase the dive height:

M558 K0 P8 C"^zprobe.in" T18000 F120 H10 A5 S0.01

This works, but now I have raised the starting point to Z=12.5 in order to allow probing until Z=-7.5! So while this works I am spending most of the probing time moving through an area where I know the trigger won't happen (because the endstop established a valid Z=0).

I guess I could make the first pass move much faster so the wait doesn't sting so much. But again I know most of the probe move will never trigger so it seems wasteful to have to raise the starting height.

IMO it would be quite elegant just to add a D parameter (for example) to M558 which allowed one to specify the desired depth range, and just assume H x 2 when not supplied. RRF is famous for not having hardcoded behaviors and leaving choice to the user, so I would have expected this to be the case here too.

My printer is a VORON V2 which is rather unique, in that the bed is fixed and it is the gantry itself that is moving & being leveled. There is an endstop switch at the back to establish Z=0, and then a separate inductive probe is used to align the gantry. Because the motors are at the back of the gantry, it is almost guaranteed that the back will be lower than the front, because that's how it will move when unpowered. So that is why I know the back probes will always trigger near Z=0, and the front probes at some negative Z value.

Does this help put a better context to my question?

Cheers,
Ben.

Hello, it seems that there is currently no way to configure the valid probing depth when doing a G30, it is implicitly defined as being twice the dive height specified by M558.

Would it be possible to add a parameter to M558 to configure this range if needed?

Currently the only way to increase the valid probing depth is to increase the dive height, which increases the probing time quite a bit.

My current setup makes an initial home with a Z endstop to establish a valid Z=0 reference, then four separate G30 calls with an inductive probe to align the gantry to the bed plane.

Since the initial position for that dive is the Z probe offset + the dive height from M558, I end up starting quite high (H5 + 2.5mm Z probe offset = 7.5mm starting Z!) when I know that the trigger won't occur until at least reaching Z=0 or lower. In order to allow triggering below Z=-2.5mm I need to increase the dive height quite a lot and that slows down all probes, simply because the depth range isn't adjustable.

I could also work around this by making my Z offset lower (or even cheating by making it negative to bring down the starting Z!) but that makes the G29 heightmap generation rightfully complain that the Z heights aren't all near Z=0.

Does that make sense?

If there is no interest (or not enough spare time!) I could look into adding this myself and submitting a PR.

For reference I am running firmware 3.2beta3 on a Duet2 1.03 Ethernet, using a Fysetc 12864 display.

Cheers,
Ben.

One thing I noticed yesterday (running 3.2beta3) is that setting a negative tool offset for Z seems to permanently disable movement for that axis. You can move the axis in the Dashboard panel, the current position changes, but no actual movement occurs.

For example if I do G10 P0 X0 Y0 Z-0.06 then any Z axis movement is disabled and the board behaves as if the drivers were busted. Maybe a similar problem occurs for U.

It took me a while to realize this was caused by the negative G10 P0 Z-0.06 bit, I was convinced I had somehow managed to kill all four Z drivers on my Duex.

I have not been able to reproduce the issue with 2.01 since the last time I posted (without touching the hardware), it seems I was just really lucky to get it (or unlucky based on your point of view...). I used to get it a lot and very easily, not so much now.

Since then I tried the 2.03RC2 release, and haven't seen an I2C reset yet. Still keeping an eye on it. I don't have any endstops on the Duex but all my fans are on it due to the 12V regulator.

@deckingman I believe if the Duex communication fails, the fans on the Duex will simply never turn off, even when below the temperature threshold (this is what happened for me, the hotend fan was stuck on even at room temp). So you should be able to confirm this without changing your config.

@deckingman I found the other threads later and noticed the problem also occurs in 2.0. I had hopes when seeing the I2C resistors hack but sadly you later confirmed it does not fix this problem.

I will leave my 2.01 setup running for now until the next occurrence (to validate Duex detection with M115 after a soft reset, as asked in another thread), and then downgrade again to 1.21.

The repro is easy for me, I just leave the steppers powered all the time. As I said before my setup is somewhat unique in that I have 4 Z motors on the Duex that are constantly moving, most printers are not built like that. Sometimes I get the error within a few hours but so far I've always reproduced it with 1 or 2 days of having the steppers powered-but-idling.

I have never seen the problem occur when turning off the steppers after each print (even if the printer itself stayed on), although I suppose it could have happened mid-print and I was just lucky until now.

@deckingman Thank you for this, I was feeling quite alone! I have since downgraded to 2.01, as I know 2.02 is also affected by this (I was discussing with someone else on Discord with the same printer / same problem and they are using 2.02).

I tend to upgrade RRF only when non-beta/non-RC versions are available, I don't know why I upgraded to 2.03beta3. Last year I was turning off the motors after each print, it is only recently that I've started to keep the steppers powered all the time.

EDIT: 2.03beta3 not RC3, this is especially important to get this right now that RC1 actually exists.