the problem turned out to be the steppers themselves. they looked identical, but the noise from them was great. replacing the steppers solved my problem.

It looks like I found what was the reason for the hotend temperature fluctuations. It's all about the slicer settings. The fact is that when printing bridges, the slicer increases cooling. But the bridges were so small that the actual speed of the coolers did not have time to change. But the firmware already included heating compensation. And for this reason there were temperature jumps. This affects the quality of the model wall. I should have written about it here. Perhaps someone else will encounter a similar effect.

@dc42 have you considered adding some time delay to the firmware to enable compensation. Or activation of compensation by double analysis of changes in fan rotation speed with an interval of several seconds. Perhaps this would help to avoid such an effect.

A few days ago I faced the same problem. Tried many ways. Changed the wi-fi channel. Turned on and off DHCP. Rebooted the router. I changed the firmware from 3.4 b 7 to 3.4 rc1. This did not improve the situation in any way. When pinging via cmd, packets were constantly lost and there was a big ping.

Packet exchange from 192.168.1.10 to 32 bytes of data:
The waiting interval for the request has been exceeded.
Response from 192.168.1.10: number of bytes=32 time=316ms TTL=255
Response from 192.168.1.10: number of bytes=32 time=207ms TTL=255
Response from 192.168.1.10: number of bytes=32 time=122ms TTL=255

Ping statistics for 192.168.1.10:
Packets: sent = 4, received = 3, lost = 1
(25% loss)
Approximate receive-transmit time in ms:
Minimum = 122 m sec, Maximum = 316 m sec, Average = 215 m sec

I had a spare router. After replacing the router, the problem went away. The ping is minimal. The connection is not lost. Maybe this will help you.

Packet exchange from 192.168.1.10 to 32 bytes of data:
Response from 192.168.1.10: number of bytes=32 time=1ms TTL=255
Response from 192.168.1.10: number of bytes=32 time=1ms TTL=255
Response from 192.168.1.10: number of bytes=32 time=1ms TTL=255
Response from 192.168.1.10: number of bytes=32 time=1ms TTL=255

Ping statistics for 192.168.1.10:
Packets: sent = 4, received = 4, Lost = 0
(0% loss)
Approximate receive-transmit time in ms:
Minimum = 1msec, Maximum = 1msec, Average = 1msec

@infiniteloop Unfortunately, socialism has lost to capitalism...probably with our help.

Hello.
There is a device with kinematics as shown in the figure.
Duet 3 6HC and Duet 3 Expansion Board 3HC are available. I wanted to find out if the reprap firmware supports such kinematics with the features indicated in the image. I would be grateful for answers and any help.
Klipper, as I understand it, does not support this(.

A few days ago I faced the same problem. Tried many ways. Changed the wi-fi channel. Turned on and off DHCP. Rebooted the router. I changed the firmware from 3.4 b 7 to 3.4 rc1. This did not improve the situation in any way. When pinging via cmd, packets were constantly lost and there was a big ping.

Packet exchange from 192.168.1.10 to 32 bytes of data:
The waiting interval for the request has been exceeded.
Response from 192.168.1.10: number of bytes=32 time=316ms TTL=255
Response from 192.168.1.10: number of bytes=32 time=207ms TTL=255
Response from 192.168.1.10: number of bytes=32 time=122ms TTL=255

Ping statistics for 192.168.1.10:
Packets: sent = 4, received = 3, lost = 1
(25% loss)
Approximate receive-transmit time in ms:
Minimum = 122 m sec, Maximum = 316 m sec, Average = 215 m sec

I had a spare router. After replacing the router, the problem went away. The ping is minimal. The connection is not lost. Maybe this will help you.

Packet exchange from 192.168.1.10 to 32 bytes of data:
Response from 192.168.1.10: number of bytes=32 time=1ms TTL=255
Response from 192.168.1.10: number of bytes=32 time=1ms TTL=255
Response from 192.168.1.10: number of bytes=32 time=1ms TTL=255
Response from 192.168.1.10: number of bytes=32 time=1ms TTL=255

Ping statistics for 192.168.1.10:
Packets: sent = 4, received = 4, Lost = 0
(0% loss)
Approximate receive-transmit time in ms:
Minimum = 1msec, Maximum = 1msec, Average = 1msec

@dc42 Yes, I know about it. But I didn't have these arduino models in stock. It was interesting to connect the "nano" that I had. And everything worked out...

@alankilian yes, I have heard that it is possible to assign digital pins for rx and tx. But I've never programmed an arduino. I need to figure out how to do this.
I didn't use the level shifter. It is stated that the io_0-io_4 ports on the duet3mini have resistors and are capable of receiving a signal up to 30V.

I removed the resistors r6 and r7 from the board, which connect the tx and rx with the ch340. the connection has appeared.Both on port io_0 and io_1, depending on the settings of the m575. Some functions work. We need to correct the sketch. But it will be inconvenient to flash now...

here is a section of the arduino nano circuit. can the connection with the ch340 interfere with communication?

@alankilian changing pins Rx/Tx does not give results.
changing the port from io_1 to io_0 with the command M575 p1 does not give results.
Connecting 5 volts to the port does not give results.
How to access arduino from the console?

@alankilian I used port io_1 after reading these messages: https://forum.duet3d.com/topic/24557/neopixels-duet3-mini5/14?_=1643657549949#

@alankilian I will now try to switch to port and io_0 and configure it as M575 P1 . But I think I've already done that today

@alankilian Only Tx flashes at the same interval