@dc42 Thanks, that's good to know. I'll dumb-proof my macros.

Yesterday I ran a bunch of jobs using various unit settings and they all ran flawlessly, so... I'm going to put it down to user error for now.

@dc42 Hi, I tested your files and the homing could be done properly.
Just to confirm I reverted to the public rc1 and the problem happens again, using rc1+2 behaves as expected.
Thanks for the help.

I wonder if it just doesn't catch the first layer change because it doesn't have a leading 0

G1 Z.5 F6000

@moth4017 2000c.jpg
just happend againg , i will see if i can track it down

@dc42
Thanks,
Not sure I follow entirely.
I'll do some tests when I get this print done.

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