RepRapFirmware 3.01-RC5 available

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

dc42

@Pumlux said in RepRapFirmware 3.01-RC5 available:

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)

That will be because you have your M558 command set up to turn heaters off during bed probing (B1 parameter).

You could avoid it by probing twice. First send M558 B0 to enable heating during probing; then do a G30 command; then raise Z a little; then send M558 B1 to disable heaters during probing (assuming that you need to in order to get accurate results); then do another G30.