@maxgyver please see this post https://forum.duet3d.com/post/271971 and run the test I described there.

@tknque no, the way that PID constants provided via M301 are used should not have changed.

@dc42 @dc42 hi My fault the DWC was RC1 but the firmware had not updated from Beta 7

We hope to release 3.4.0RC2 within the next 1 to 2 days. Meanwhile you can see the issues we found in 3.4.0RC1 by looking at the draft RC2 release notes, at https://github.com/Duet3D/RepRapFirmware/wiki/Changelog-RRF-3.x-RC#reprapfirmware-340rc2. Preview builds to fix these for some boards are at https://www.dropbox.com/sh/2dt7sbqpx6l74np/AADn4-lpcil1iqnWKkiVri3Ia?dl=0.

@dc42 Hi David

We've tested the 3.4RC+2 files from your Dropbox link in our printer and it worked. This problem is solved.

Currently we have main 6HC with 3.4RC1 fw, DWC 3.4RC1, all boards 1XD and LC1 with 3.4RC1+2. Tested standalone, not in SBC due to global RPI shortage.

For the moment we have not found any other problems with this version.

@jay_s_uk @achrn thank u

@dc42 The update has resolved the issue. Thank you very much!

@dc42 Cura-DuetRRF Plugin to embed thumbnails just landed on the public Ultimaker Cura Marketplace - but due to this issue it is not yet compatible with 3.4-rc1.

So, with the next RC it should immediately work with the latest Cura plugin version v1.2.5.

@dc42 did a down load today now RC1 , Thanks

@chrishamm Thanks. Here is a bit more info. I'll see what else I can capture if they keep occurring.

The 503 errors were from a reboot earlier today The ERR_NAME_NOT_RESOLVED is curious as we haven't had any other DNS related issues The 404 (in the middle) is one of concern as that is one where it couldn't write a file I was editing, but did save just fine on a second try. No, we don't use M505 The 409 was me testing to try to recreate the issue

@oozebot Thanks for your report. Depending on your slicer it's better to use something like

;NUM_LAYERS: [total_layer_count]

somewhere at the start or end of your G-code file, that will give you an accurate number of layers.

I'll check why the total object height is off.

Thanks, seems I have missed that! I guess I will take that as "i have done something wrong" - until version 3.5 🙂

@vali3d I confirm this is a bug. I will fix it in the next RC, and I will probably make a test version available before then.

@resam No, there is nothing to be concerned about - I saw this with an earlier beta but didn't see any side effects. I think duettools is installed before duetruntime is updated and an install script from duetpimanagementplugin attempts invoke a program from it which loads an outdated assembly. I'll check again if I can fix it by adding a new dependency from duettools to the correct duetruntime version.

@diamondback Yes I was, thank you. In that case I missed it two places! Sorry.

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. 🙂