RepRapFirmware 3.01-RC5 available

dc42

@SIam said in RepRapFirmware 3.01-RC5 available:

Is it possible that there is a problem with the print time calculation ?

I think I've seen this happen once too. Let me know if it happens again.

dc42

I've just added version 3.01-RC5 firmware binaries for Duet 3 tool boards and expansion board to this release.

SIam

@dc42

i have printet now the same thing (a little bit faster) and have this result

29.3.2020, 12:09:45: Datei covid19_headband_rc3(6).gcode erfolgreich nach 13s hochgeladen
29.3.2020, 12:09:46: M32 "0:/gcodes/covid19_headband_rc3(6).gcode": File 0:/gcodes/covid19_headband_rc3(6).gcode selected for printing
29.3.2020, 12:20:46: : Leadscrew adjustments made: -0.076 -0.079 -0.066, points used 3, (mean, deviation) before (-0.073, 0.005) after (-0.000, 0.000)
Auto kalibrierung erfolgreich, Abweichung von:  0.005mm
Happy Printing
29.3.2020, 13:54:23: : Finished printing file 0:/gcodes/covid19_headband_rc3(6).gcode, print time was 22h 12m

This print is ca. 13 hours later as the first one (the printer was not switched off), if i calculate the first print time response from duet 9h 11m + 13 hours then the result is 22h 11 so i think the start time of a print will not set the printing time to zero.

dc42

I confirm the problem with incorrect print time. It will report the time since the Duet was last powered up or reset.

TC

I am not sure if this is a new issue but can you checck the multiplication operator. It seems not to work at all

dc42

@TC said in RepRapFirmware 3.01-RC5 available:

I am not sure if this is a new issue but can you checck the multiplication operator. It seems not to work at all

It works if you enclose the expression in { } but not otherwise. That's because * normally introduces an end-of-line checksum.

TC

Ah ok. Maybe that is also something that could be mentioned in the documentation

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.