RepRapFirmware 3.2beta3.2 released

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.

Veti

@dc42

from the changelog.

Efficiency improvements to TMC2208/2209 drivers for both main and tool boards

Which board uses the TMC2208? did you mean TMC2224?

dc42

@Veti said in RepRapFirmware 3.2beta3.2 released:

@dc42

from the changelog.

Efficiency improvements to TMC2208/2209 drivers for both main and tool boards

Which board uses the TMC2208? did you mean TMC2224?

Yes, I did. I think of the TMC2224 as a 2208 (it's the same with a different pinout).

DaBit

@dc42 said in RepRapFirmware 3.2beta3.2 released:

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

Makes no difference. Skirt goes well, once the printing of the circles starts the Duet hangs (cancel print does not work, emergency stop does, changing temperatures in DWC does too)

Screenshot 2020-11-26 191833.png

dc42

You've posted the print file, but I need your config.g file too.

DaBit

@dc42 : Here is the entire bundle, directly downloaded from the printer:

https://www.icecoldcomputing.com/directlink/DaBit3D_config_26nov2020.zip

dc42

Thanks, that's on my list to look into.

DaBit

It is not an issue for me. I suspect the large amount of short segments simply choking the Duet. When using gcode with sane segment length the Duet hums along fine.
But still, it should slow down to a crawl, but not hang.

dc42

Absolutely right, it should not hang.

dc42

I believe this is now fixed in the new RRF 3.2bete4+3 binaries at https://www.dropbox.com/sh/tehhdvunh0pgr7q/AADgJ4Qj7W18MYaRRNNDdhpwa?dl=0.