Pre-release 3.5 beta 2 now available

chrishamm

On behalf of the Duet3D team I am happy to announce the next pre-release v3.5 beta 2.
This release brings several new features and bug fixes since v3.5 beta 1 with the highlights being:

Ability to reassign individual array elements using the set command
New code editor in DWC including new G-code highlighting to support meta G-code expressions
Improved support of custom array variables
Several improvements for multiple motion systems
MQTT publisher support on Duet 3 series WiFi enabled boards (M586 P4 and M586.4)
Keepout zones (M599)
Backlash compensation (M425)

Please do not forget to read the upgrade notes for

Starting from this release, DSF and DWC will use SemVer v2 for versioning.
This means if you are using MintyTrebor's ReleaseMgr plugin to track impacts on your configuration, you need to upgrade it as well.

In standalone mode, you can obtain the latest versions from here. Please check out to the docs if you want to try it out in SBC mode.

If you encounter any issues, please open a new thread with [3.5.0-b2] in the title and describe it there.

oliof

@dc42 any plans to integrate ADXL accelerometer support by @gloomyandy upstream? That would allow to make full use of RP2040 based boards on the market that usually have ADXL accelerometers on board for the klipper people.

mikeabuilder

Has support for the new M291 message options been added to the PanelDu fw yet? If not, and ETA?

T3P3Tony

@mikeabuilder said in Pre-release 3.5 beta 2 now available:

Has support for the new M291 message options been added to the PanelDu fw yet? If not, and ETA?

No. I don't have an ETA yet.

dc42

@oliof said in Pre-release 3.5 beta 2 now available:

@dc42 any plans to integrate ADXL accelerometer support by @gloomyandy upstream? That would allow to make full use of RP2040 based boards on the market that usually have ADXL accelerometers on board for the klipper people.

Unfortunately the ADXL345 doesn't provide a fast means of reading data without introducing artefacts in the data. Andy has verified that these artefacts are present when using Klipper firmware too. So it is not something that we wish to support.

oliof

@dc42 I understand but its still a bummer. @gloomyandy do you have any pretty pictures comparing ADXL with LIS where one could see those artefacts?

Diamondback

Does anyone else have issues with loops? It appears to me that this is not working at all:

while iterations < 4
    echo iterations

RRF spawns lots of error messages likes this:

Error: Bad command: hile iterations < 4
0
Error: Bad command: hile iterations < 4
0
Error: Bad command: hile iterations < 4
0
Error: Bad command: hile iterations < 4
0
Error: Bad command: hile iterations < 4
0
Error: Bad command: hile iterations < 4
0
Error: Bad command: hile iterations < 4
0
Error: Bad command: hile iterations < 4
0
Error: Bad command: hile iterations < 4

(Note that this is from a a single macro execution of above code, nothing else)

And DWC keeps crashing and/or disconnecting after this, only cutting power solves the issue (until I try to execute it again)

OwenD

@Diamondback
No issues with that macro on duet2 standalone

jay_s_uk

@Diamondback looks like it's dropping the w
SBC or standalone?

Diamondback

@jay_s_uk 6HC standalone

Diamondback

Ok, so in 3.5b1+ things work fine.

M98 P"0:/macros/TEST"
0
1
2
3

Since I have a bunch of different builds between b1 and b2, will now trying to figure out where thing broke.

Diamondback

Ok, @dc42 it looks like this happened at some point after you implemented the setting of individual array elements.
The initial test that you provided to me (3.5beta1+ (2023-01-26 14:16:10)) works correctly, however, another test version (with the same dropbox name for some reason) that you provided to me later as part of the Z/extruder issues (3.5beta1+ (2023-01-30 09:10:34)) has the issue already.
So I guess something between these two dates causes it.

dc42

~~@Diamondback please attach that file to a post, I think there jmy be something odd about it.~~

Scratch that, I've managed to reproduce a similar issue. It's connected with using CRLF as the line ending.

dc42

@Diamondback please try the new RRF binary at https://www.dropbox.com/sh/tbxi2wz9olqe5cl/AAA1gvCp05XS7G1t0qxAV3yQa?dl=0.

Diamondback

@dc42 This seems to work now, thanks a lot!

Ghazi

I remember that @joergs5 was working on a robot kinematic K13. Is it available in the 3.5beta version?

DIY-O-Sphere

@dc42
Is there any news on restoring the old error handling in the case of a heater fault ?

JoergS5

@Ghazi I'm sorry, development will take longer, as I changed the internal algorithms. So it will not be included in 3.5.

The original method was to iterate inverse kinematics solutions. But a few % of the solutions didn't iterate correctly, i.e. the solution will fail, ruining the print. The solution now is to calculate inverse kinematics for all possible solutions and will give an answer in every situation. But this change will take a while.

Marcossf

We tested this 3.5 beta 2 in our 6XD + several 1LCs machine in SBC mode, and it gives constant SPI reseting.

Going back to 3.4.5 stable version revert the normal behaviour of the printer.

All firmware on the boards in the beta 2 are been updated, just in case it needs to be same version than mainboard.

dc42

@DIY-O-Sphere said in Pre-release 3.5 beta 2 now available:

@dc42
Is there any news on restoring the old error handling in the case of a heater fault ?

What aspect of the old error handling is it that you want, that can't be achieved using the event system?