RepRapFirmware 3.2beta3.2 released

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

[droftarts]

@chas2706 said in RepRapFirmware 3.2beta3.2 released:

Also, where have my plugins gone?

The ones under Settings > General > Plugins are the built-in plugins. The ones under Settings > Machine-Specific > Plugins are third-party plugins that you have uploaded, eg Sindarius's Gcode viewer https://github.com/Sindarius/DWC_GCodeViewer_Plugin/releases

Ian

[chas2706]

@droftarts said in RepRapFirmware 3.2beta3.2 released:

The ones under Settings > General > Plugins are the built-in plugins. The ones under Settings > Machine-Specific > Plugins are third-party plugins that you have uploaded, eg Sindarius's Gcode viewer http

Thanks for the info. I was wondering what the difference is.

[droftarts]

@chas2706 I've just finished writing the documentation that covers this!
https://duet3d.dozuki.com/Wiki/Duet_Web_Control_v2_and_v3_(DWC)_Manual#Section_Plugins_tab_built_in
https://duet3d.dozuki.com/Wiki/Duet_Web_Control_v2_and_v3_(DWC)_Manual#Section_Plugins_tab_third_party

Ian

[chas2706]

@droftarts said in RepRapFirmware 3.2beta3.2 released:

I've just finished writing the documentation that covers this!

Brilliant, many thanks!

[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 see the same thing. Added to my list for investigation.

[DaBit]

@dc42 said in RepRapFirmware 3.2beta3.2 released:

Are you definitely using the M307 parameters that were reported by auto tuning, and not overriding them with M301?

18-11-2020 20:31:33	M307 H1
Heater 1 model: heating rate 1.941, cooling time constant 335.4/173.7, dead time 6.34, max PWM 1.00, calibration voltage 23.8, mode PID
Computed PID parameters: setpoint change: P14.5, I0.315, D64.4, load change: P14.5, I0.819, D64.4

This is after a restart of the board. Looks like the tuning parameters are set correctly.

Your tuning results show a bog difference with the fan on, so I would expect the feedforward to make a difference.

No silicone sock and a sudden tornado is quite worst case. That tornado also helps tremendously to speed up the toolchange with the Chimera so I am happy with it; I cool down and wipe the inactive nozzle until the plastic has frozen, otherwise getting anything close to acceptable results using a Chimera is close to impossible.

Under those circumstances I don't think the -6C drop is a bad result at all. There is lag between heater and sensor, and there is only so much a 50W cartridge can do. Compared to RRF3.1 the new feedforward does not help, but it seems not to hurt either.

I assume 'feedforward' is setpoint feedforward? Do you use a curve to adjust for ambient-hotend temperature differential and/or scale the feedforward with fan percentage? Maybe feed a portion of the fan percentage into the D term of the PID to provide a temporary boost/drop in heater power?

[DaBit]

Not sure where to post it, but I have a file that won't print and I haven't seen the behaviour before 3.2beta3.2 so it might be beta-related.

Printer stalls early in the print (as in: no movement at all), and stays there indefinitely until the board is reset (cancel print does not work, emergency stop does).
When the board is reset and the print restarted, the same happens again but in a slightly different location.

M122 output:

=== Diagnostics ===
RepRapFirmware for Duet 2 WiFi/Ethernet version 3.2-beta3.2 running on Duet WiFi 1.02 or later
Board ID: 08DGM-917DA-G4MSJ-6JKF8-3SJ6T-T8RZ8
Used output buffers: 3 of 24 (24 max)
=== RTOS ===
Static ram: 24108
Dynamic ram: 101684 of which 60 recycled
Never used RAM 4196, free system stack 118 words
Tasks: NETWORK(ready,182) HEAT(blocked,308) MAIN(running,475) IDLE(ready,20)
Owned mutexes:
=== Platform ===
Last reset 00:05:03 ago, cause: software
Last software reset at 2020-11-26 00:09, reason: User, GCodes spinning, available RAM 4196, slot 0
Software reset code 0x0003 HFSR 0x00000000 CFSR 0x00000000 ICSR 0x0041f000 BFAR 0xe000ed38 SP 0xffffffff Task MAIN
Error status: 0x00
MCU temperature: min 38.0, current 38.4, max 40.2
Supply voltage: min 0.4, current 23.8, max 24.2, under voltage events: 0, over voltage events: 0, power good: yes
Driver 0: position 25577, standstill, SG min/max 0/546
Driver 1: position -6991, standstill, SG min/max 0/567
Driver 2: position 260, standstill, SG min/max 0/116
Driver 3: position 0, standstill, SG min/max 0/1023
Driver 4: position 0, standstill, SG min/max not available
Driver 5: position 0
Driver 6: position 0
Driver 7: position 0
Driver 8: position 0
Driver 9: position 0
Driver 10: position 0
Driver 11: position 0
Date/time: 2020-11-26 00:14:55
Cache data hit count 521485427
Slowest loop: 213.31ms; fastest: 0.12ms
I2C nak errors 0, send timeouts 0, receive timeouts 0, finishTimeouts 0, resets 0
=== Storage ===
Free file entries: 9
SD card 0 detected, interface speed: 20.0MBytes/sec
SD card longest read time 3.1ms, write time 0.0ms, max retries 0
=== Move ===
Hiccups: 153966(0), FreeDm: 121, MinFreeDm: 101, MaxWait: 144319ms
Bed compensation in use: mesh, comp offset 0.000
=== MainDDARing ===
Scheduled moves 3529, completed moves 3489, StepErrors 0, LaErrors 0, Underruns [0, 0, 0], CDDA state 3
=== 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, chamberHeaters = -1 -1 -1 -1
Heater 0 is on, I-accum = 0.1
Heater 1 is on, I-accum = 0.3
=== GCodes ===
Segments left: 1
Movement lock held by null
HTTP is idle in state(s) 0
Telnet is idle in state(s) 0
File is doing "G1 X114.269 Y202.499 E3.444310" 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
Daemon is idle in state(s) 0
Autopause is idle in state(s) 0
Code queue is empty.
=== Network ===
Slowest loop: 211.63ms; fastest: 0.00ms
Responder states: HTTP(0) HTTP(0) HTTP(0) HTTP(0) FTP(0) Telnet(0), 0 sessions
HTTP sessions: 3 of 8
- WiFi -
Network state is active
WiFi module is connected to access point 
Failed messages: pending 0, notready 0, noresp 0
WiFi firmware version 1.24[stackable_OD5.5_ID3.2_H3_bush_firstlayer.gcode](/assets/uploads/files/1606347019576-stackable_od5.5_id3.2_h3_bush_firstlayer.gcode) 
WiFi MAC address ec:fa:bc:25:33:45
WiFi Vcc 3.34, reset reason Turned on by main processor
WiFi flash size 4194304, free heap 25184
WiFi IP address 192.168.0.42
WiFi signal strength -60dBm, reconnections 0, sleep mode modem
Clock register 00002002
Socket states: 0 0 0 0 0 0 0 0

Looking at the code it is not quite what I expected (absolute E-coordinates, and many very small moves). Those are user error and easily fixed, but the Duet should not hang on it either?

I am not very concerned, other prints run fine so it is probably a matter of re-slicing with correct settings, but I thought it might be useful to someone.

[dc42]

Please test that file again with beta 4 when it comes out (probably tomorrow). If the problem persists, post the file where I can retrieve it.

[DaBit]

OK, will do.

This morning I did reslice with my usual settings (relative extrusions, usage of G10, cap on resolution), print is currently at 12.5% and progressing fine, hiccups counter stays at 0.
My gut feeling says that the huge amount of short segments in the original code is what causes the issues.

In advance; the G-code file can be found here: https://www.icecoldcomputing.com/directlink/stackable_OD5.5_ID3.2_H3_bush.zip

[dc42]

@DaBit, 3.2beta4 for Duet WiFi is released now.