Software package 3.3beta3 released

janusofdoors

Can you elaborate on why the accelerometer support is for standalone mode only?

Luke'sLaboratory

@vishiano
SBC's add an extra layer of "fun" which is why they test it out initially on standalone units.

OwenD

@dc42
From the change log
Previously, when daemon.g was not found or after it had finished running, RRF paused for 1 second before trying to open it again. That time has been increased to 10 seconds to reduce the load on the SD card. If you need a daemon to execute more often than once every 10 seconds, use a loop inside the daemon.g file.

Can you expand on what problems were being experienced using the 1 second timing?
Whilst it is simple to run a loop within daemon.g it would be counter productive if the consequences are dire.
Also does the 10 second count begin when daemon.g starts or finishes?
Running a loop only makes sense if the former applies.
Presumably, in either circumstance, daemon.g can only be run once. i.e. if it's open, then it's skipped until the next cycle.
I have nothing currently in use that would suffer drastically from a 10 second cycle, but others may have.

dc42

@owend said in Software package 3.3beta3 released:

Can you expand on what problems were being experienced using the 1 second timing?
Whilst it is simple to run a loop within daemon.g it would be counter productive if the consequences are dire.
Also does the 10 second count begin when daemon.g starts or finishes?
Running a loop only makes sense if the former applies.
Presumably, in either circumstance, daemon.g can only be run once. i.e. if it's open, then it's skipped until the next cycle.
I have nothing currently in use that would suffer drastically from a 10 second cycle, but others may have.

We had some evidence suggesting that the overhead of opening (or trying to open) the daemon.g file every second might be causing print slowdown and quality issues when printing a long sequence of very short moves, because of contention for the SD card. Increasing the delay to 10 seconds reduces this overhead by 90%.

The first time that RRF tries to open daemon.g, the delay before trying to open it is one second as before so that daemon.g starts up quickly if it exists. Subsequent times (after failing to open daemon.g, or daemon.g finishing executing), the delay is ten seconds.

I have it in mind to add a new M-code to start/stop execution of daemon.g instead.

o_lampe

@owend said in Software package 3.3beta3 released:

to reduce the load on the SD card

Why don't we load daemon.g into memory and start it from there? That way the SD-card would only read once.
In earlier posts, @dc42 mentioned there's plenty of RAM available on all Duet boards....

dc42

@o_lampe said in Software package 3.3beta3 released:

In earlier posts, @dc42 mentioned there's plenty of RAM available on all Duet boards....

There is plenty of RAM available on the MB6HC and a reasonable margin on the Duet 3 Mini. RAM is already tight on Duet 2.

oc_geek

@dc42 i've updated to this rel (printer was off for long time) and i started to receive a rain of warnings and motors making clicking noises continuosly... powered off and powered on ...for the moment those seem gone.... what is that ??! everything is cool and at ambient temp....

Argo

@oc_geek

How long was it off? I mean from which firmware did you upgrade to 3.3 beta 3?

oc_geek

@argo was not asking you... 3H+ and update was from 3.3Beta2+

dc42

@oc_geek, @Argo asked the right questions and saved me having to ask them.

I suspect you had a bad connection in the ribbon cable between the Duet and DueX.

oc_geek

@dc42 Duex ? Ribbon cable ? LOL

I'm on a Mini 5+ / 2+ ....
Actually the Third one as i had to replace them multiple times due to SD card soldering issues....

I'm saying i had no issue before....I install the fw after printer is completely cold at warm temperature
and those (nonsense) alarms came up..
and the steppers started clicking endless like everyting is going to break apart..

Take it or leave it...

TBH i really have enough of the attitudes of yours of all the time i ave spent around this hw and i pretend answers from yourself
not from experts popping up from nowere pretending to become Duet developers overnight (sorry no offence Argo...) i'm really fed up at this point

out

dc42

@oc_geek, please remain calm and polite, that's a condition of using this forum.

You didn't say which board you were using in your original post, so I made the incorrect assumption that it was a Due + DueX as it had more than 5 stepper drivers.

If that error only occurred immediately after you upgraded, and was cleared by powering off and on again, then it probably means that the TMC2209 drivers didn't immediately adapt to the change in baud rate between firmware 3.3beta2 and 3.3beta3.

oc_geek

@dc42 ...it's becoming harder to...

I had posted numerous times in the other thread about layers shifts and mesh issues so i assumed you remembered the config i had, but i understand you deal with 100s issues at day...so sorry if my post was not sharp clear from start

Ok understand the explanation now
My intention was to just report factual and that the steppers really click bad and don't stop doing that...
Swtcing off - on appears to solve the issue.
Perhaps it may be worth to mention somewhere...as someone may think things are breaking apart (as i did...)

dc42

@oc_geek, I'll mention it in the release notes in case anyone else experiences it. Thanks for your report.

PaulHew

@dc42 said in Software package 3.3beta3 released:

Users of Duet + SBC can upgrade from the unstable package server.

Being totally new to using a SBC + Duet3, are these the correct commands to run to install this firmware?

If you wish to use the latest unstable DSF components, you can run the following commands instead:

wget -q https://pkg.duet3d.com/duet3d.gpg
wget -q https://pkg.duet3d.com/duet3d-unstable.list
sudo mv duet3d.gpg /etc/apt/trusted.gpg.d/
sudo mv duet3d-unstable.list /etc/apt/sources.list.d/duet3d-unstable.list
sudo chown root:root /etc/apt/trusted.gpg.d/duet3d.gpg
sudo chown root:root /etc/apt/sources.list.d/duet3d-unstable.list

TIA Paul.

jay_s_uk

@paulhew yes, then sudo apt update && sudo apt upgrade

PaulHew

@jay_s_uk Thank you.
Need a button in DWC somewhere so it can be done!

P.

Luke'sLaboratory

@dc42

We had some evidence suggesting that the overhead of opening (or trying to open) the daemon.g file every second might be causing print slowdown and quality issues when printing a long sequence of very short moves, because of contention for the SD card. Increasing the delay to 10 seconds reduces this overhead by 90%.

That's some interesting context

I hate to re-ask, but were those issues also related to the notes: "A separate task is now used to finalize moves for execution" where those short, small moves were causing issues?

My first print on 3.3beta3 didn't have the issues that have been plaguing me for a long while on my 6hc +3hc setup, So i was wondering what all went into the fix beyond the CAN sync issues from a few threads earlier

tristanryerparke

Thanks for all this great work guys, variables are already changing the game.
Are macro parameters supported on Duet3+SBC?
T

dc42

@luke-slaboratory said in Software package 3.3beta3 released:

I hate to re-ask, but were those issues also related to the notes: "A separate task is now used to finalize moves for execution" where those short, small moves were causing issues?

I made that change to facilitate additional functionality that needed to be incorporated into the Move subsystem, to remove some of the limitations in firmware 3.2 when using CAN-connected boards. I don't have any evidence that it fixed any issues, except that on the Duet 3 Mini it worked around another issue.

My first print on 3.3beta3 didn't have the issues that have been plaguing me for a long while on my 6hc +3hc setup, So i was wondering what all went into the fix beyond the CAN sync issues from a few threads earlier.

There have been several improvements and fixes to CAN traffic management in the 3.3beta series, including one between beta 2 and beta 3.