@phaedrux omg, I just noticed this reply 😧

ok, so this means I can not hide or remove one completely? (since it shows the one and only installed fan twice)

@dc42 I found the problem.

When tool T1 was being returned, the Y "parking" coordinate was off by 1 mm. The tool parking location didn't budge but the firmware thought that the tool location was 1mm beyond where it actually was. The machine is a corexy (E3D), so even though only the Y coordinate was off, I suspect it affected both the x and y location from the the firmware's perspective.

@juliann said in [3.4.0beta6] After update: Heater 1 fault shows 409.9 °C:

After finishing this installation, can I send you this second tool board to repair it as well?

Yes, please do.

@o_lampe said in Very! strange height map results:

I'd check the drag-chain if it causes the BLTouch mount bending/tilting.

It uses the E3D spring trip arrangements to hold the cables as upright loops, so any "pull " is consistently towards the front centre.

Nothing was moving much or retaining any offset when I was deliberately trying to create head<>rail movements & the BLTouch is attached directly and rigidly to the underside of the printed cap I had the dial gauge on.

I'll do more measurements and gauge tests when I get chance.

I'll also try running heightmap with a tool on the head - the Hemera Direct tools are quite heavy and should produce a change if anything is loose anywhere.

@pcr Yes, thats right. Unfortunately PrusaSlicer uses an invalid content type for the G-code request so I had to work-around it.

M600 is now properly processed within the gcode stream. 🙂

I write code and know how hard it is write for another audience. It is hard to write "down to" someone less familiar with the given task. Yes, it is confusing.

@dc42 I hadn’t seen any other errors. In the abundance of caution I am replacing the heater and sensor, and will run prints again. The stoppage is rather random and doesn’t happen all the time, but I e posted about the issue since the first beta. It had not been happening prior to that.

That being said I have had with the previous beta where the printer hadn’t stopped but the head was cold and had not been extruding at all; without an error report of some kind, the head was moving, but the heater was not operational.

@achrn I have a fix for the rendering that I have setup a pull request for and will likely be in the next 3.4 build. dfd3a29d-c306-418e-be51-22cf4842a996-image.png

@dc42 Thank you for the update, I started to be concerned that my board might be defective as I was the only one reporting this issue - I was close to test one from another printer or just buy another one.

Let me know if you have a pre-beta version you want to be validated, I can do it fairly quickly.

@dc42 Thank you for the answer! I found running it only in spread cycle the best option for this setup.

@achrn this behaviour changed between 3.3 and 3.4beta. See https://duet3d.dozuki.com/Wiki/GCode_Meta_Commands#Section_Use_of_expressions_within_GCode_commands and the release notes for RRF 3.4.0beta2.

@t3p3tony Thankyou, I missed that when checking the code for it....

@gloomyandy My bad, I searched but I missed this post.

Thanks!

@alexth https://duet3d.dozuki.com/Wiki/Pressure_advance
or
https://forum.duet3d.com/topic/25764/pressure-advance-tuning-with-conditional-g-code?_=1635840827943

@dc42 @T3P3Tony

The new board arrived and the Out channels are now properly controlling the LED strips. Thank you for helping me sort out my issue. The offending hardware is boxed up and will be arriving to you shortly. Thanks again!!!

@t3p3tony If it happens again I will run the M122

P.

@pcr Short answer no.

Longer answer:
At the moment beta6 does not allow you to capture more then 64K samples. But you may be able to get it to work by using a lower capture data rate in M956 and then modifying the script to match, but this is not something I have tried. It looks like the next RRF build should have support for larger captures: https://github.com/Duet3D/RepRapFirmware/commit/020e9fbc171b1a519d9b8f01df2e68f1c273beaf

0 dc42 committed to Duet3D/RepRapFirmware Support collecting more than 64k acceleraometer samples

@phaedrux said in [3.4.0beta6] M32 Response too long error check console:

@supernovae said in [3.4.0beta6] M32 Response too long error check console:

but there is nothing in console other than showing lead screw adjustments.

The "response too long" message is trying to tell you that the lead screw adjustments results are too long to show as a popup and to see them in the console.

oh hahaha.. it took a bit for my brain to digest that. I was thinking there should be another error in the console not that the leadscrew adjustment warning was too big to show.

I think DWC used to show it in a green box but now it just throws that error popup

@gloomyandy Thanks, I'll check what's going on. It will be fixed in the upcoming version.