RepRapFirmware 3.2beta3.2 released

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

chas2706

@jay_s_uk said in RepRapFirmware 3.2beta3.2 released:

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

Nice one. I guess I need to go to specsavers!

dc42

@DaBit said in RepRapFirmware 3.2beta3.2 released:

@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.

I'm sorry, I was reading your post on a smartphone and I omitted to scroll down enough.

Are you definitely using the M307 parameters that were reported by auto tuning, and not overriding them with M301? Send M307 H1 to check. Your tuning results show a big difference with the fan on, so I would expect the feedforward to make a difference.

appjaws

I have just noticed that my hotend overshoots by 10 degrees on first heating and then falls back and maintains a very stable value.
Under the old system you could adjust the A parameter to compensate.
In the M303 line I used P1.0, should I have reduced this? if so what could be a sensible value?

dc42

@oliof said in RepRapFirmware 3.2beta3.2 released:

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

Using pre-release and v0.6 boards should make no difference, if they are running up to date firmware. There have been no changes to the CAN hardware between revisions.