RepRapFirmware 3.2beta3.2 released
-
@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
-
@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.
-
@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_partyIan
-
@droftarts said in RepRapFirmware 3.2beta3.2 released:
I've just finished writing the documentation that covers this!
Brilliant, many thanks!
-
@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.
-
@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?
-
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.
-
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.
-
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
-
@DaBit, 3.2beta4 for Duet WiFi is released now.
-
from the changelog.
Efficiency improvements to TMC2208/2209 drivers for both main and tool boards
Which board uses the TMC2208? did you mean TMC2224?
-
@Veti said in RepRapFirmware 3.2beta3.2 released:
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).
-
@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)
-
You've posted the print file, but I need your config.g file too.
-
@dc42 : Here is the entire bundle, directly downloaded from the printer:
https://www.icecoldcomputing.com/directlink/DaBit3D_config_26nov2020.zip
-
Thanks, that's on my list to look into.
-
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. -
Absolutely right, it should not hang.
-
I believe this is now fixed in the new RRF 3.2bete4+3 binaries at https://www.dropbox.com/sh/tehhdvunh0pgr7q/AADgJ4Qj7W18MYaRRNNDdhpwa?dl=0.
-
not fixed or 'now fixed'?
I will give it a try, will report back...