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.
444.png

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

@jay_s_uk it was btncmd that caused the problem

bltouch back on io1 with your updated build works. fantastic! thanks!

fixed in 3.4RC1

I don't know when exactly this got solved, but starting with one of thhe 3.4 beta builds, this is no longer an issue and works fine again. 🙂

@phaedrux
Ahh ok, so you already adjusted the partition scheme, great to hear 🙂

According to serial my board was 2021-06.
Nevertheless I'd add a note to Setup/install guide, I'd written something but can't find my docu credentials at the moment.

@dc42 Morning, I'm using a Duet 2 Wifi.

@educatingsavvas could be the case. I think the last job I ran was with beta 4 or 5

@gloomyandy @phaedrux
That fixed it. It works correctly in standalone mode with M669 S1, but not with the PI, strange.

@moth4017 I have now fixed this in the source code and tested it. The fix will be included in RRF 3.4.0rc1. Thanks for your help in getting this fixed.

@phaedrux it's a bug in 3.4b7

Think @dc42 is aware

Personally, I've never seen the point of having a standby temperature for the bed, and I would prefer to get rid of it.

@alankilian I like the way you're thinking! Unfortunately I'm still seeing Issue #1 and Issue #2 with the 713728.3125 value (more on both #1 and #2 in a moment).

There is an option in the post-processor to limit the maximum arc radius. Currently it is set to... 1000000mm 😊

It should have been obvious to anyone reading, but issue #1 and #2 are just different side effects of the same issue. #1 occurs with the 'troublesome' command at higher speeds, with #2 occurring at low speeds. At higher speeds we see the overshoot, and at lower speeds, we see the single-axis oscillation.

Post-processor wise, limiting the maximum arc radius to a reasonable value seems like a solid idea. For my own curiosity, I want to collect more data on these large radius moves.

@jay_s_uk ahhh thank you.

@julian_wicht said in Problem with PID-Tuning (RRF 3.4.0-b7):

@argo
i try it now with M303 H1 S240 to PID my Left Hotend

It did not make a difference whether i PID via tool or heater, the result are now the Heater are not Starting

@educatingsavvas said in M291 S3 not blocking when called with M98:

WiFi firmware version 1.23

Not really related, but your wifi server is a bit out of date. How have you been updating the firmware? Regardless, you should be able to update just the wifi firmware by uploading the latest version.

https://github.com/Duet3D/RepRapFirmware/releases/download/3.3/DuetWiFiServer.bin

@dogma2k in your #3 I had the same issue. Then I cut a USB 3.0 cable and use this Cable, Problem fixed

There is also in the wiki a notice about this trick

Had something similar happen a few times, not sure if it's an issue in my config but sounds similar. it just decides to go take a walk in the opposite direction, stop then it runs the next command which is usually homing X/Y then it resumes like normal. sometimes it tries to go too fast and the steppers buzzz like they're stuck but there's nothing in the way.... it works normally in every other scenario. it's glitched but seems hard to reproduce.

@theolodian said in Expansion boards not working on 3.4b7?:

@dc42 OK, thanks. That’s a no then. Can you call for a feedrate of a million, and then let the max feedrate in config.g sort it out?

Yes.

If you have no real rotary axes then you could use the M584 S parameter to have the extra linear axes treated as rotary axes for the purposes of feed rate calculation.