Pre-release 3.5 beta 2 now available

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?

DIY-O-Sphere

@Diamondback
https://forum.duet3d.com/topic/28636/is-there-a-work-around-to-restore-the-old-heater-fault-handling

Diamondback

@DIY-O-Sphere What do you want to say with that?
I'd simply write a piece of code for daemon that checks if a heater has been in fault state for some time and if it does, turn off the power supply.
Even if I don't really see why you'd want to do that, you clearly appear have a use case for it and it it's easy enough to add?

chrishamm

@Marcossf Please can you share your config and/or the M122 output after a SPI reset.

Marcossf

Hi @chrishamm

Our config file is not going to clarify anything for you as it makes calls to several other files that it loads from where there are hundreds of variables.

We would have to figure out a way to get an M122 out because when it connects and disconnects it does it often, with no time to see what is going on. I think we have a console log where we can see it, but it never connects stable, not even once. I'll look for it.

With version 3.4.5 it works perfectly.
Sorry I can't give you more clues.

gloomyandy

@Marcossf You should be able to connect via USB to get the M122 output.

T3P3Tony

@Marcossf you can also share a zip of the /sys directory and and other macro directories. If that's sensitive information then we can arrange to get it another way

gman10192

This post is deleted!