Software package 3.3beta3 released

PaulHew

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

P.

Luke'sLaboratory

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.

dc42

@tristanryerparke said in Software package 3.3beta3 released:

Are macro parameters supported on Duet3+SBC?

They should be, but I haven't tested them myself in SBC mode.

Luke'sLaboratory

@dc42

Fantastic, can't wait to get back to toolchanging

64bit

work faster.... lol

I started using RRF on a Fusion3 machine that we have in my office and I loved it. So much so that I bought a pair of D2Wifi boards for my two hobby printers. I installed one, and its been on 2.03 for the longest time, recently updated to 2.05.1
My other machine was converted to Klipper. I love me some input shapers.
I now have the D2Wifi boards in both of my machines and i am ABOUT to make the jump over to Klipper on both. If input shaper comes to RRF soon, I might not make that switch!

tristanryerparke

@dc42 I did a quick test and am getting this error on duet3 + pi4
Running 3.3beta on rrf, dsf and dwc.

Macro testparam.g:

echo param.A
echo param.B
echo param.C

Running this command:

M98 P"0:/macros/testparam.g" A1 B"test" C32.7

Gives this error:

Error: Failed to evaluate "param.A": unknown parameter 'A' of testparam.g

Am I doing something wrong?
I tried to follow the example here in which A and B seemed to work:
https://forum.duet3d.com/topic/22731/param-p-doesn-t-return-macro-name
Thanks,
T

dc42

@tristanryerparke, I'll ask @chrishamm to look into this.

ctilley79

Height map disappears in DWC with attached SBC. If you go to the height map tab in DWC and refresh the browser. The height map will not reload in the 3D viewport with error "height map not available". In order to get it back, you have to go to the system tab, edit hieghtmap.csv and then navigate back to the height map.

In addition to this error, I've had a couple instances where commands completely halt the 6HC main board. I'm not sure if the process is dying on the SBC or whether the board is panicking and indeed shutting off.

sebkritikel

@dc42 ~~Alright, what am I doing wrong? Likely something simple~~

Duet2 Wifi +Duex5
Duet Web Control 3.3.0-b3
RepRapFirmware for Duet 2 WiFi/Ethernet 3.3beta3 (2021-04-22)

~~Wiring diagram (tried some variations of this, including using duex.cs5, duex.cs6). Green LED on each of the boards tested.~~

M955 P0 C"spi.cs3+spi.cs4"
Error: M955: Accelerometer not found on specified port

Update - I'm quite confident the cable assembly was good, but likely was too long (~11ft). Trimmed 4ft off the Duet side, re-terminated and now we're good to go.

Topher

@dc42 Will there be proper speaker support using M300 for the duet 2 at any point down the road? Currently with the speaker output on the expansion header, M300 can only trigger on and off and a duration of the pulse to the speaker pin, no oscillation.

joeko

the mcu temperture is 10 degrees above room temperture.
do i have to do a pid tuning like in the wiki and if so how ?

dc42

@joeko said in Software package 3.3beta3 released:

the mcu temperture is 10 degrees above room temperture.
do i have to do a pid tuning like in the wiki and if so how ?

There are instructions for calibrating the MCU temperature reading at https://duet3d.dozuki.com/Wiki/Calibrating_the_CPU_temperature.

joeko

@dc42 said in Software package 3.3beta3 released:

@joeko said in Software package 3.3beta3 released:

the mcu temperture is 10 degrees above room temperture.
do i have to do a pid tuning like in the wiki and if so how ?

There are instructions for calibrating the MCU temperature reading at https://duet3d.dozuki.com/Wiki/Calibrating_the_CPU_temperature

yes i know but when i send Send command M912 P0 STr or Tc i get the error message that i have to set the sensor number.

joeko

@dc42 said in Software package 3.3beta3 released:

@joeko said in Software package 3.3beta3 released:

the mcu temperture is 10 degrees above room temperture.
do i have to do a pid tuning like in the wiki and if so how ?

There are instructions for calibrating the MCU temperature reading at https://duet3d.dozuki.com/Wiki/Calibrating_the_CPU_temperature.

sorry, i got it.
this set the correction and now it is ok
thx

deckingman

I am once again unable to print anything since upgrading from 3.3. beta2 to 3.3. beta 3. This macro (which is called from my gcode files) causes the board to reset as soon as the hot end and bed reach their set temperatures (immediately after the M116). PrePrintPLAUVAB.g The reset loses the network connection temporarily, turns off all the heaters, and causes the axes to lose their homing status. Just what I need before starting a print (not).

EDIT. Reverted back to 3.3. beta2 and all is well again. So it's definitely caused by 3.3. beta 3 (either the firmware or DWC version).

deckingman

Update on this. It seems to be consistent whenever I try beta 3. M122 reports a software reset as soon as macro finishes heating and the M116 completes. Reason: HardFault and a load of codes and with "bad marker". DC has been provided with more details via a different channel to these forums.

Loris

Hi all, i have a strange behaviour using rrf 3.3b3.
I printed a file already in my SD (when i use 3.3b1).
This file is a simple testing cube sliced in simplify3d having 1 perimeter only.
Printed with 3.3b1 is perfect.
Printed with 3.3b3 seems that first layers are smaller than normal.
I also confirm that the probe z-offset with 3.3b3 seems different, it print al little far away from bed, 3.3b1 perfect.
Same config.g and same configuration.
I only changed the firmware.
To do a test, i rollback to 3.3b1 and it prints perfectly the same file.
Here a picture about the print with 3.3b3

matt3o

@loris could it be a temperature issue? have you tried to re-run the pid calibration?