@dc42 It works! And it works flawlessly!
With this build I've done some multihour prints with many tool changes and they worked perfect, no more resets (at least from thar reason).
For the PanelDue, using PanelDueFirmware-3.5.0-rc7-testcomm DWC is more responsive, more fluid, it updates more often and the connection is more consistent.
As a side note - annoying but don't bother me too much - after some time the DWC disappears altogether. I can ping the board, but no DWC. But until that point works flawlessly. By the way, trying to disable and reenable the wifi module (idle or printing) resulting in a stuckinspinloop when trying to enable it again.

Again, thank you very much for your time and help solving this issue! 😊

@Diamondback thanks, I'll flag this as solved.

@dc42 Ah okay, that's great!

@Adrian52 thanks, I've added that newline.

@dc42 the answers were able to resolve the problem, thanks everyone for the help!

No, i'm not using G92 during my print at all. It's being used for the homing process of the coupler axis once, but that's about it.

My profuse apologies for:

my (very) late answer digging up this old topic (Halloween trick or treat ?!)

but my answer is still relevant (based on the code base of the RRF 3.5.0 rc1 and 3.4.6).

@dc42 said in G30: unexpected probe dive motion range:

If you set the dive height to some value H [...] the code starts the dive at (trigger_height + H) and ends it if the probe is not triggered first at (trigger_height - H)

That is my expectation, but not what the G30 command currently does.

You will notice in the code of G30 command the mention of platform.AxisMinimum(Z_AXIS), variable which I can't make sense of:

ms.coords[Z_AXIS] = (IsAxisHomed(Z_AXIS)) ? platform.AxisMinimum(Z_AXIS) - zp->GetDiveHeight() + zp->GetActualTriggerHeight()

This is in contrast to the probing code of the G29 command, which works as you described without ever using platform.AxisMinimum(Z_AXIS):

ms.coords[Z_AXIS] = -zp->GetDiveHeight() + zp->GetActualTriggerHeight();

Hence my (old yet still relevant) pull request.

Hopefully this patch would not bring any regression, however it might save multiple RRF user from less than desirable unexpected nozzle crashes.

Nevermind, looks like the reason F0 did not work was due to some connector issue.

And the wrong indication for F4 & F5 was probably due to Duet Web Control still being on 3.4.0 and not 3.5.0.

Everything works fine now. Issue not related to 3.5.0-rc.1.

Please disregard.

@chrishamm
Thanks for verifying that that was a legitimate error/concern.
By default, does 3.5-rc.1 have large SPI transmissions right off the get-go but 3.4.6 does not? Perhaps that's why 3.4.6 was connecting but not faulting out like 3.5-rc.1?

After further testing:
For Bullseye (Deb 11), this works:

echo "options spidev bufsiz=8192" | sudo tee /etc/modprobe.d/spidev.conf

For Bookworm (Deb 12), it does not.

Instead, I had to add:

spidev.bufsiz=8192

to the end of

/boot/cmdline.txt

After a reboot, when I:

cat /sys/module/spidev/parameters/bufsiz

I get 8192 and DWC now connects to the 6HC with 3.5-rc.1 in SBC mode.

I know we are probably an early adopter of Bookworm on the Pi w/Duet SBC so I'll report out anything else I run into. We'll be exercising our system heavily over the next few weeks.

@dc42 That is correct. When shutting down in open-loop mode what happens is: (in this order)

Power off by hand (unplugging power cord) or emergency stop by DWC motors lose currect (lose their holding torque) and gantry moves down. after a slight delay (0.5sec) brakes engage bc of loss of power and stop the gantry from falling further down.

When the gantry weight was still 250kg's the brakes couldnt stop the downward movement and it continued to fall down.
Now we have 2x 100kg's counterweights and the ''weight'' of the gantry is now 50kg's. So now they can stop it when it falls. But that doesnt happen anymore as long as i do the shutdown procedure.

Startup procedure:

At startup it runs the config file wich contains M569 P50.0 S0 D4. (closed-loop without tuning maneuvre so brakes are engaged) after that i manually run a startup macro: M569 P50.0 S0 D0 and run open loop mode.

Shutdown procedure:

Run macro wich only contains 5x M569 P50.0 S0 D4. for all the motors (to engage the brakes again) Power off (unplug the cord)

.
NOTE: When updating the boards to new firmware, the motors lose holding torque AND the brakes are dis-engage. wich makes the gantry fall down too. i dont know if its in open-loop or closed loop when starting the update, but i could replicate this if you like.

@Phaedrux m122

This is fixed, It was my error when updating

@dc42 yes I think this is the issue.
I thought I also encountered it on beta 4 but it is possible the firmware didn't flash back to the previous version correctly.

@chrishamm
Hey, thank you for the feedback! It is nice to see suggestions are being taken into account.

@dc42 I see, I expected the file to be "reloaded" after saving and then not being found afterwards because of the renaming. Thank you for the solution!

@CCS86 I've been doing some research and it seems Duet took the wrong approach. I just recently installed klipper on my duet 6hc and toolboard to fool around with until Duet figures out a new implementation. David hinted at reevaluating after 3.5 is officially released.

If you want an interesting read, look at Dmitry Butyugin's comment thread about 2/3 the way down.

https://www.youtube.com/watch?v=bqf382QDSKY

@gloomyandy I hadn't noticed he was printing at 0.1mm layer height. I suppose that will help a bit with getting consistent extrusion since he's only having to get to 30mm³/s rather than 60mm³/s (I'm asuming 0.5mm width). But still he seems able to print each of the holes very cleanly even though he's going from retration to 30mm³/s with an acceleration of 35,000mm/s² and a jerk of 30 (or 1800 in RRF language).

My point was just that it does seem he is able to get the extruder to keep up with incredible acceleration and that, in my opinion, it's not pointless to reduce X carriage and printhead weight.

I'm still on a 24v system and 2 motors, whereas Vez is using 4 motors and 48v, so I won't be hitting the speeds he's getting. I seem to be able to get decent results with 200mm/s outer walls, 250mm/s inner walls at 4000mm/s² acceleration and 300mm/s, 10,000mm/s² acceleration for infill. All at 1200 jerk and 0.2mm layer height. Weirdly 600 jerk was causing the ringing in low poly curves to be much worse.

I did try going back over to 3.5.0-rc.1 just to test if the input shaping changes would improve the low poly curve banding, but the result was identical.

@nikscha at present there is no locking around M569.4. However, M569.4 will fail if the motor is moving due to a previous G1/G2/G3/G4 command.