RepRapFirmware 3.2beta3.2 released

Adrian52

Extruder tuning worked fine for me too - rock solid line during first print. Bed tuning did 30 cycles, but seems to be working fine. This is a fairly low powered bed tuning to 60deg - each 5deg cycle took about 3.5min. This is with a stand alone 1.01 Duet2wifi.

gloomyandy

This post is deleted!

Stephen6309

What's saved in config-override.g with M500:
M307 H0 A424.4 C543.6 D5.5 S1.0 V24.1 B0

What the M303 H0 S90 came up with:
M307 H0 R0.781 C543.6 D5.54 S1.00 V24.1

Is the M500 supposed to change the M307?

dc42

@Stephen6309 said in RepRapFirmware 3.2beta3.2 released:

What's saved in config-override.g with M500:
M307 H0 A424.4 C543.6 D5.5 S1.0 V24.1 B0

What the M303 H0 S90 came up with:
M307 H0 R0.781 C543.6 D5.54 S1.00 V24.1

Is the M500 supposed to change the M307?

Yes, M500 is supposed to rewrite config-override.g including the new model parameters. I can't see anything wrong with the code, so I will try to reproduce your observation.

Marco Bona

@dc42, @chrishamm, after updating to the latest release i am having assertion problems again.
I publish the report. Let me know if you need more information or if I need to check

m122
=== Diagnostics ===
RepRapFirmware for Duet 3 MB6HC version 3.2-beta3.2 running on Duet 3 MB6HC v0.6 or 1.0 (SBC mode)
Board ID: 08DJM-956L2-G43S4-6JKF0-3S86T-9A5YD
Used output buffers: 1 of 40 (22 max)
=== RTOS ===
Static ram: 122236
Dynamic ram: 140444 of which 24 recycled
Never used RAM 129488, free system stack 170 words
Tasks: Linux(ready,75) HEAT(blocked,275) CanReceiv(blocked,878) CanSender(blocked,371) CanClock(blocked,352) TMC(blocked,51) MAIN(running,1159) IDLE(ready,19)
Owned mutexes: HTTP(MAIN)
=== Platform ===
Last reset 01:15:05 ago, cause: software
Last software reset at 2020-11-15 10:23, reason: AssertionFailed, GCodes spinning, available RAM 128744, slot 0
Software reset code 0x4123 HFSR 0x00000000 CFSR 0x00000000 ICSR 0x0040080f BFAR 0x00000000 SP 0x2045fea4 Task MAIN
Stack: 00000193 00488688 00469673 00000001 2043ff1d 2043fe50 2043eab0 2043fb80 20438118 00000001 20438090 204381b4 204381b0 00000003 0046ea21 00000003 00433a0b 00000001 20420b20 20437970 20420b20 2042ac70 040023b6 204375b0 00000002 2042ab10 000249f0
Error status: 0x00
MCU temperature: min 23.3, current 23.4, max 24.5
Supply voltage: min 24.1, current 24.1, max 24.2, under voltage events: 0, over voltage events: 0, power good: yes
12V rail voltage: min 12.0, current 12.1, max 12.1, under voltage events: 0
Driver 0: position 0, standstill, reads 21669, writes 19 timeouts 0, SG min/max 0/0
Driver 1: position 0, standstill, reads 21670, writes 19 timeouts 0, SG min/max 0/0
Driver 2: position 0, standstill, reads 21673, writes 17 timeouts 0, SG min/max 0/0
Driver 3: position 0, standstill, reads 21673, writes 18 timeouts 0, SG min/max 0/0
Driver 4: position 0, standstill, reads 21674, writes 17 timeouts 0, SG min/max 0/0
Driver 5: position 0, standstill, reads 21675, writes 17 timeouts 0, SG min/max 0/0
Date/time: 2020-11-15 11:38:49
Slowest loop: 6.98ms; fastest: 0.15ms
=== Storage ===
Free file entries: 10
SD card 0 not detected, interface speed: 37.5MBytes/sec
SD card longest read time 0.0ms, write time 0.0ms, max retries 0
=== Move ===
Hiccups: 0(0), FreeDm: 375, MinFreeDm: 375, MaxWait: 0ms
Bed compensation in use: none, comp offset 0.000
=== MainDDARing ===
Scheduled moves 0, completed moves 0, StepErrors 0, LaErrors 0, Underruns [0, 0, 0], CDDA state -1
=== AuxDDARing ===
Scheduled moves 0, completed moves 0, StepErrors 0, LaErrors 0, Underruns [0, 0, 0], CDDA state -1
=== Heat ===
Bed heaters = 0 -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 -1, chamberHeaters = 3 -1 -1 -1
Heater 1 is on, I-accum = 0.0
=== GCodes ===
Segments left: 0
Movement lock held by null
HTTP* is doing "M122" in state(s) 0
Telnet is idle in state(s) 0
File* is idle in state(s) 0
USB is idle in state(s) 0
Aux is idle in state(s) 0
Trigger* is idle in state(s) 0
Queue is idle in state(s) 0
LCD is idle in state(s) 0
SBC is idle in state(s) 0
Daemon* is doing "G4 S60" in state(s) 0 0, running macro
Aux2 is idle in state(s) 0
Autopause is idle in state(s) 0
Code queue is empty.
=== CAN ===
Messages sent 18038, send timeouts 18038, longest wait 3ms for type 6039, free CAN buffers 47
=== SBC interface ===
State: 0, failed transfers: 0
Last transfer: 21ms ago
RX/TX seq numbers: 9476/13409
SPI underruns 0, overruns 0
Number of disconnects: 0, IAP RAM available 0x20a30
Buffer RX/TX: 0/0-0
=== Duet Control Server ===
Duet Control Server v3.2.0-beta3
Daemon:
Buffered code: G4 S60 ; delay running again or next command for at least 60 seconds
==> 32 bytes
Executing macro daemon.g, started by system
> Next stack level
Code buffer space: 4096
Configured SPI speed: 8000000 Hz
Full transfers per second: 31.79

Marco Bona

@dc42, @chrishamm, I checked, it seems that problem is due to restart of printing after a stall. For the moment I have tried increasing S value in M915 to see if it repeats again.

appjaws

@dc42 just to let you know, the new auto tune works well on my coreXYUV Duet 2 machine with RRF 3.2beta3.2
Thank you for all your hard work.

dc42

@Marco-Bona said in RepRapFirmware 3.2beta3.2 released:

@dc42, @chrishamm, I checked, it seems that problem is due to restart of printing after a stall. For the moment I have tried increasing S value in M915 to see if it repeats again.

Thanks for the update. How did you have the stall detection configured when you had the problem?

Marco Bona

@dc42, the code was this:

M915 X Y T20000 S12 H128 F1 R3

In all honesty I never understood how to calibrate it correctly but with this values it gave good results.
I simply increased the S value from 12 to 15. I can't tell you if the same assertion problem also occurs after resuming a print from a pause.
If you need feedback I can give it a try.

whopping pochard

@dc42 said in RepRapFirmware 3.2beta3.2 released:

Thanks for the feedback!

Thanks for the feedforward HEYOOOOO

DaBit

Duet2Wifi, copper E3D v6 heaterblock with 50W cartridge and PT100 heater 1, aluminium E3D v6 block / 50W heater / thermistor on heater 2, 300x300x10mm aluminium bed with 600W silicone heater on heater 0.

Auto tuning heater 1 using target temperature 250.0°C and PWM 1.00 - do not leave printer unattended
16-11-2020 09:35:27	M303 H1 S250
16-11-2020 09:39:11	Auto tune starting phase 3, fan off
16-11-2020 09:42:18	Auto tuning heater 1 completed after 5 cycles in 411 seconds. This heater needs the following M307 command:
 M307 H1 R2.029 C335.3 D5.90 S1.00 V23.8
Edit the M307 H1 command in config.g to match this.

Auto tuning heater 0 using target temperature 70.0°C and PWM 1.00 - do not leave printer unattended
16-11-2020 09:43:41	M303 H0 S70
16-11-2020 09:43:46	Auto tune starting phase 1, heater on
16-11-2020 09:48:42	Auto tune starting phase 2, heater settling
16-11-2020 10:09:03	Auto tune starting phase 3, fan off
16-11-2020 10:45:51	Auto tuning heater 0 completed after 5 cycles in 3728 seconds. This heater needs the following M307 command:
 M307 H0 R0.176 C2246.3 D40.12 S1.00 V24.0
Edit the M307 H0 command in config.g to match this.

Auto tuning heater 2 using target temperature 220.0°C and PWM 1.00 - do not leave printer unattended
16-11-2020 12:10:43	M303 H2 S220
16-11-2020 12:10:48	Auto tune starting phase 1, heater on
16-11-2020 12:12:13	Auto tune starting phase 2, heater settling
16-11-2020 12:14:00	Auto tune starting phase 3, fan off
16-11-2020 12:17:12	Auto tuning heater 2 completed after 5 cycles in 388 seconds. This heater needs the following M307 command:
 M307 H2 R2.328 C287.2 D6.31 S1.00 V23.8
Edit the M307 H2 command in config.g to match this.

Especially the bed took quite a while, but that's a lot of thermal mass.

I am not noticing much better PID behaviour when the print cooling fan is suddenly turned on from 0% to 100%; without silicone sock the hotend temperature drops ~6 degrees C and recovers fairly slowly. 100%->0% gives a 5-6 degree C overshoot. RRF3.1.2 behaves about the same under that condition.

gloomyandy

@DaBit Try using the tool number rather than the heater number so:
M303 T0 S250
assuming H1 is the heater for T0. If you do this then the tuning will run an extra cycle with the cooling fan for tool 0 active and you will get some extra params which may help with your temperature drop.

DaBit

Thanks for the hint, 'old' habits I guess..

Makes not much difference though. Recovery from fan torturing is slightly faster, temperature deviation stays approximately the same with -6.5C /+5C.

16-11-2020 20:15:57	M303 T0 S250
Auto tuning heater 1 using target temperature 250.0°C and PWM 1.00 - do not leave printer unattended
16-11-2020 20:16:02	Auto tune starting phase 1, heater on
16-11-2020 20:17:57	Auto tune starting phase 2, heater settling
16-11-2020 20:19:39	Auto tune starting phase 3, fan off
16-11-2020 20:22:48	Auto tune starting phase 3, fan on
16-11-2020 20:26:13	Auto tuning heater 1 completed after 10 cycles in 615 seconds. This heater needs the following M307 command:
 M307 H1 R1.941 C335.4:173.7 D6.34 S1.00 V23.8
Edit the M307 H1 command in config.g to match this.

Cooling fan turn-on / turn-off event, no silicone sock:

alt text

Of course, I could improve a lot on this by making fan airflow more directional towards the print, but there is no print-quality reason to do so. Better save those lessons learned and time to resolve them for printer #2. There are more things that did not work out as expected and need improvement, such as the E3D Chimera.

I normally use silicone socks around the heater block, especially when printing small items, although at 250-270C hotend their lifespan is a bit limited.

Is there a reason why we don't have a derivative term in the controller? Or is that derived internally from the R/A, C and D parameters? The D usually works fine dampening an otherwise too agressive P and reacting to fast environmental changes.

oliof

Is it normal that while the printer is idle the toolboard reports about 10 lost messages per second?

root@vcore-pro:~# echo "M122 B10" | /opt/dsf/bin/CodeConsole
[output elided]
root@vcore-pro:~# sleep 60
root@vcore-pro:~# echo "M122 B10" | /opt/dsf/bin/CodeConsole
Connected!
Diagnostics for board 10:
Duet TOOL1LC firmware version 3.2-beta3.2 (2020-11-13)
Bootloader ID: SAMC21 bootloader version 2.1 (2020-11-03b2)
Never used RAM 4200, free system stack 96 words
HEAT 43 CanAsync 88 CanRecv 82 TMC 53 MAIN 317 AIN 64
Last reset 09:39:47 ago, cause: power up
Last software reset data not available
Driver 0: position 0, 1660.0 steps/mm,  standstill, SG min/max 0/0, read errors 0, write errors 0, ifcount 12, reads 32612, writes 0, timeouts 0, DMA errors 0, failedOp 0xff
Moves scheduled 0, completed 0, in progress 0, hiccups 0
No step interrupt scheduled
VIN: 23.8V
MCU temperature: min 25.8C, current 33.2C, max 33.3C
Ticks since heat task active 201, ADC conversions started 34649116, completed 34649115, timed out 0
Last sensors broadcast 0x00000002 found 1 204 ticks ago, loop time 0
Free CAN buffers: 36, messages lost 595, duplicates 0, oos 0, busOff 0

Duet 3 in SBC mode running 3.2beta3.2 as the host system. The LEDs blink in sync (and obviously CAN transfers do work).

dc42

@DaBit said in RepRapFirmware 3.2beta3.2 released:

I am not noticing much better PID behaviour when the print cooling fan is suddenly turned on from 0% to 100%; without silicone sock the hotend temperature drops ~6 degrees C and recovers fairly slowly. 100%->0% gives a 5-6 degree C overshoot. RRF3.1.2 behaves about the same under that condition.

That's because you didn't use a T parameter in the M303 command to tune heater 1, so it didn't run tuning with the fan off and then on.

dc42

@oliof said in RepRapFirmware 3.2beta3.2 released:

Is it normal that while the printer is idle the toolboard reports about 10 lost messages per second?

root@vcore-pro:~# echo "M122 B10" | /opt/dsf/bin/CodeConsole
[output elided]
root@vcore-pro:~# sleep 60
root@vcore-pro:~# echo "M122 B10" | /opt/dsf/bin/CodeConsole
Connected!
Diagnostics for board 10:
Duet TOOL1LC firmware version 3.2-beta3.2 (2020-11-13)
Bootloader ID: SAMC21 bootloader version 2.1 (2020-11-03b2)
Never used RAM 4200, free system stack 96 words
HEAT 43 CanAsync 88 CanRecv 82 TMC 53 MAIN 317 AIN 64
Last reset 09:39:47 ago, cause: power up
Last software reset data not available
Driver 0: position 0, 1660.0 steps/mm,  standstill, SG min/max 0/0, read errors 0, write errors 0, ifcount 12, reads 32612, writes 0, timeouts 0, DMA errors 0, failedOp 0xff
Moves scheduled 0, completed 0, in progress 0, hiccups 0
No step interrupt scheduled
VIN: 23.8V
MCU temperature: min 25.8C, current 33.2C, max 33.3C
Ticks since heat task active 201, ADC conversions started 34649116, completed 34649115, timed out 0
Last sensors broadcast 0x00000002 found 1 204 ticks ago, loop time 0
Free CAN buffers: 36, messages lost 595, duplicates 0, oos 0, busOff 0

Duet 3 in SBC mode running 3.2beta3.2 as the host system. The LEDs blink in sync (and obviously CAN transfers do work).

I don't think that's normal. I will see what my toolchanger reports later today.

DaBit

@dc42 said in RepRapFirmware 3.2beta3.2 released:

That's because you didn't use a T parameter in the M303 command to tune heater 1, so it didn't run tuning with the fan off and then on.

It did. I used M303 T0 S250 to start the tuning.
At 20:19 it started phase 3 with fan off, at 20:22 with fan on. DWC also confirmed the fan being on at 100% (I admit: I was not physically next to the printer, so I did not verify if the fan was actually blowing air, but I thrust the software enough for that), the tuning ran for 10 cycles instead of 5, and the C values for fan on/off in the resulting M307 are quite different.

oliof

@dc42 suffice to say I have a prerelease 1LC board (with updated bootloader) and a Duet3 rev0.6 board.

chas2706

I still get the odd report that transfer data pin not ready. SBC has own 6amp PSU and connected via genuine ribbon cable.

Also, where have my plugins gone?

jay_s_uk

@chas2706 that's machine specific plugins. The ones you want are under the general tab