RepRapFirmware 3.01-RC5 available

Dr_Ju_Ju

Has anything changed in the heating routines ? as since I've updated to RC5 my hot-end heater keeps throwing this error:

"Error: Heating fault on heater 1, temperature rising much more slowly than the expected 1.7°C/sec"

which I've never had on the previous RC's & RRF2x. nothing has changed on the hardware side & I've even power cycled, in case it was just an anomaly....

M115
FIRMWARE_NAME: RepRapFirmware for Duet 2 WiFi/Ethernet FIRMWARE_VERSION: 3.01-RC5 ELECTRONICS: Duet Ethernet 1.02 or later FIRMWARE_DATE: 2020-03-27b3

M122
=== Diagnostics ===
RepRapFirmware for Duet 2 WiFi/Ethernet version 3.01-RC5 running on Duet Ethernet 1.02 or later
Board ID: 08DGM-95BNL-MGPSJ-6J1F2-3SD6L-9JZHX
Used output buffers: 1 of 24 (10 max)
=== RTOS ===
Static ram: 28052
Dynamic ram: 93204 of which 44 recycled
Exception stack ram used: 256
Never used ram: 9516
Tasks: NETWORK(ready,748) HEAT(blocked,1244) MAIN(running,1844) IDLE(ready,76)
Owned mutexes:
=== Platform ===
Last reset 00:00:55 ago, cause: software
Last software reset at 2020-03-31 11:27, reason: User, spinning module GCodes, available RAM 9516 bytes (slot 2)
Software reset code 0x0003 HFSR 0x00000000 CFSR 0x00000000 ICSR 0x0441f000 BFAR 0xe000ed38 SP 0xffffffff Task 0x4e49414d
Error status: 0
Free file entries: 10
SD card 0 detected, interface speed: 20.0MBytes/sec
SD card longest block write time: 0.0ms, max retries 0
MCU temperature: min 29.9, current 31.2, max 31.6
Supply voltage: min 24.2, current 24.4, max 24.5, under voltage events: 0, over voltage events: 0, power good: yes
Driver 0: standstill, SG min/max not available
Driver 1: standstill, SG min/max not available
Driver 2: standstill, SG min/max not available
Driver 3: standstill, SG min/max not available
Driver 4: standstill, SG min/max not available
Date/time: 1970-01-01 00:00:00
Cache data hit count 108426845
Slowest loop: 6.93ms; fastest: 0.11ms
I2C nak errors 0, send timeouts 0, receive timeouts 0, finishTimeouts 0, resets 0
=== Move ===
Hiccups: 0(0), FreeDm: 169, MinFreeDm: 169, 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 CDDA state: -1
=== AuxDDARing ===
Scheduled moves: 0, completed moves: 0, StepErrors: 0, LaErrors: 0, Underruns: 0, 0 CDDA state: -1
=== Heat ===
Bed heaters = 0 -1 -1 -1, chamberHeaters = -1 -1 -1 -1
Heater 0 is on, I-accum = 0.0
Heater 1 is on, I-accum = 0.0
=== GCodes ===
Segments left: 0
Movement lock held by null
HTTP is idle 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
Daemon is idle in state(s) 0
Autopause is idle in state(s) 0
Code queue is empty.
=== Network ===
Slowest loop: 10.03ms; fastest: 0.02ms
Responder states: HTTP(0) HTTP(0) HTTP(0) HTTP(0) FTP(0) Telnet(0)
HTTP sessions: 2 of 8
Interface state active, link 100Mbps full duplex

dc42

No, nothing has changed since the previous 3.01 RCs. Is the hot end heating up at all?

Dr_Ju_Ju

Yes, its heating that's why I was surprised....but fyi, I've just run an M303\M500 sequence and that at least lets me get to the working temp of 235 for my Petg...

jbarros

Hi,

I'm having the same issue on 3.01-RC5:
30/03/2020, 23:50:03 Cancelled printing file 0:/gcodes/20mm_calibration_cube.gcode, print time was 0h 36m
Warning: Tool 0 was not driven because its heater temperatures were not high enough or it has a heater fault
30/03/2020, 23:48:35 Printing paused at X34.9 Y44.1 Z8.1
30/03/2020, 23:48:35 Warning: Tool 0 was not driven because its heater temperatures were not high enough or it has a heater fault
30/03/2020, 23:48:32 Error: Temperature reading fault on heater 1: short-circuit in sensorResume state saved
30/03/2020, 23:48:31 Warning: Tool 0 was not driven because its heater temperatures were not high enough or it has a heater fault
30/03/2020, 23:48:27 Warning: Tool 0 was not driven because its heater temperatures were not high enough or it has a heater fault
30/03/2020, 23:48:23 Warning: Tool 0 was not driven because its heater temperatures were not high enough or it has a heater fault
30/03/2020, 23:48:18 Warning: Tool 0 was not driven because its heater temperatures were not high enough or it has a heater fault
30/03/2020, 23:48:15 Warning: Tool 0 was not driven because its heater temperatures were not high enough or it has a heater fault
30/03/2020, 23:48:11 Warning: Tool 0 was not driven because its heater temperatures were not high enough or it has a heater fault

I'm using a PT100 with an official Duet PT100 temperature sensor board
My sensors config:
; Heaters
M308 S0 P"bedtemp" Y"thermistor" T100000 B4138 ; configure sensor 0 as thermistor on pin bedtemp
M950 H0 C"bedheat" T0 ; create bed heater output on bedheat and map it to sensor 0
M143 H0 S120 ; set temperature limit for heater 0 to 120C
M307 H0 B1 S1.00 ; enable bang-bang mode for the bed heater and set PWM limit
M140 H0 ; map heated bed to heater 0
M308 S1 P"spi.cs1" Y"rtd-max31865" ; configure sensor 1 as thermocouple via CS pin spi.cs1
M950 H1 C"e0heat" T1 ; create nozzle heater output on e0heat and map it to sensor 1
M143 H1 S280 ; set temperature limit for heater 1 to 280C
M307 H1 B0 S1.00 ; disable bang-bang mode for heater and set PWM limit

I happened the 3 times I tried to print.
Since I just finished building this printer I was afraid I had some cable, plug, sensor, board issue but was unable to reproduce any errors by flexing the cables.

Edit: the temperature reading I got was 2000, the same I get on open circuit

tobias_munich

@jbarros have you tuned your heaters?
https://duet3d.dozuki.com/Wiki/Tuning_the_heater_temperature_control

jbarros

@tobias_munich
indeed I have:

; config-override.g file generated in response to M500 at 2020-03-30 01:58
; This is a system-generated file - do not edit
; Heater model parameters
M307 H0 A154.3 C287.0 D3.0 S1.00 V24.3 B0
M307 H1 A467.5 C123.2 D5.5 S1.00 V24.2 B0

dc42

I think either you have a genuine a short circuit, or you have very severe interference on the PT100 leads. Please post a photo of the top of your daughter board so that I can see whether it is the latest version with extra filter capacitors.

jbarros

@dc42

Mine is v0.4

I have 2 AWG24 UTP cables running to my hotend
The cable with the PT100 wires also serves 2 fans. Does that fit your "severe interference" suspicion?

dc42

Usually it's only adjacent stepper motor wiring that causes enough interference to be problematic, and only on boards without the extra filter capacitors.

zorro_66

I'm trying to upgrade the firmware on my maestro card but am getting the following error

M997 S0
Error: M997: In-application programming binary "DuetMaestroIAP.bin" not found

DIY-O-Sphere

@zorro_66
From witch version. If you are on RRF 2 you must upgrade to 3. 0 first.

zorro_66

i´m on Firmware: RepRapFirmware for Duet 2 Maestro 3.01-RC4 (2020-03-16b1)

dc42

Download DuetMaestroIAP.bin from the 3.0 release and upload it to /sys on your Duet.

zorro_66

Worked perfectly thanks ...

bberger

Is there any documentation on how the object cancellation works?

I know that there isn't any interface for DWC (yet), but I might just patch that in if I get some spare time and an endpoint documentation.

droftarts

@bberger See https://duet3d.dozuki.com/Wiki/Gcode?revisionid=HEAD#Section_M486_Object_cancellation
and @dc42 's thread here: https://forum.duet3d.com/topic/15119/cancel-individual-objects-on-the-build-plate
No other documentation as yet. I believe that PrusaSlicer can generate appropriate tags, but haven't tested it yet.
@chrishamm was talking about adding it to DWC, but has other priorities at the moment, so I'm sure would be happy if someone else wanted to help out!

Ian

dc42

@droftarts said in RepRapFirmware 3.01-RC5 available:

@bberger See https://duet3d.dozuki.com/Wiki/Gcode?revisionid=HEAD#Section_M486_Object_cancellation
and @dc42 's thread here: https://forum.duet3d.com/topic/15119/cancel-individual-objects-on-the-build-plate
No other documentation as yet. I believe that PrusaSlicer can generate appropriate tags, but haven't tested it yet.
@chrishamm was talking about adding it to DWC, but has other priorities at the moment, so I'm sure would be happy if someone else wanted to help out!

To expand on this:

The "Label objects" option in PrusaSlicer will generate object labels in the GCode file that RRF 3.01-RC5 and -RC6 understand.
The list of known objects on the build plate and their XY limits is already included in the object model (send M409 K"job.build.objects" to retrieve it) so that future versions of DWC will be able to offer an interface to select an object to be cancelled.
Meanwhile, the M486 command can be used to cancel an object.

bberger

Thank you guys for your quick reply! Let's see if I can hack something together shortly.

The switch to Vue and Vuetify greatly helps in my case. Thank you for going down that road!

jbarros

@dc42
Mine being a v0.4 and from reading other threads about this issue does not have the extra filter capacitors.
2 UTP cables for fans and sensors, extruder heater AND extruder stepper cable all running at least 1m alongside each other might explain my issues.
Waiting for proper cables from China, I used a temporary shielded cable just for this sensor.

I'm happy to report the issue has not happened again

Pumlux

Bug or feature ?

Temperture is dopping during a long time consuming move / home all .

I'm running a Duet Wifi 1.01 board and ugraded some weeks ago to RRF3.
I noticed that the heater seems to be not heating if a time consuming move is made.

In detail :
I heat up the bed to 50 degrees and the extruder to 200 degrees and than I do homing all.
During the move to home all axes the heater seems to be not heating, the time for homing was aprox. 2 min 30 sec and the extruder temperature drops from 200 to ~140 degrees. (see screenshot below ) when all the moves for homing are completed the temperature is rasing again to targeted 200 degrees.
(I see this temperture drop on the long time z-axis movement, not sure about the x and y axis)

In addtition, If the duet is heating up to the target temperature e.g. from 20 degrees to 200 degrees, I can not do printhead moves until temperture is reached (not always, I don't know what makes the difference here) .

It looks like moves and heating can not be done in parallel, not sure if this behavior comes from the duet firmware or from the web firmware.

I just noticed it on RRF 3.01 RC4 and RC5.

Duet RRF3 Temperture heating.jpg