Pre-release 3.5 beta 2 now available

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?

dc42

@Marcossf thanks for your report. I've asked @chrishamm to look into this.

For now the 3.5beta builds of expansion boards are compatible with RRF 3.4 on the main board, and vice versa. This will change in a future beta release.

DIY-O-Sphere

@dc42
This topic is really getting annoying.
I expect the firmware to shut down the system as announced here.

"Currently, RRF does not attempt to turn off power to the whole machine in the case of machines with firmware controlled power supplies if the user does not respond to the heater fault. We plan to reinstate this or a similar function in release 3.5"

Diamondback

@DIY-O-Sphere This sounds easy enough to handle yourself with the use of daemon.g?