RepRapFirmware 3.01-beta 3 released
-
It's different with me, Duet2 Wiffi. This time also called from a print file.
Your mentioned variant does not happen to me, printing is successfully completed. The macro file is only canceled.
With "abort" at the end of the file, the printing movements are stopped, but the printer status remains "Printing/Processing"
Sometimes only an emergency stop helps, sometimes I can use "Pause Print" and then "Cancel Print" to escape the "Printing/Processing" status
Signature is up to date (firmware version, etc.)
-
The tool status (
tools[0].state
) appears to no longer be updated to off.
When starting, off is displayed, but once active, off is no longer displayed.
Only with me or can someone reproduce that -
Please check whether you still have these 2 issues using the new binary at https://www.dropbox.com/sh/3azy1njy3ayjsbp/AACquxr2m00eV568RZg5QG5wa?dl=0.
-
Hi,
I just tried PID tuning my hotend and while M307 H1 shows a result, M500 does not save a valid line to config-override.gSystem info:
2/6/2020, 10:42:50 PM M115 FIRMWARE_NAME: RepRapFirmware for Duet 3 MB6HC v0.6 or 1.0 FIRMWARE_VERSION: 3.01-beta3 ELECTRONICS: Duet 3 MB6HC FIRMWARE_DATE: 2020-01-29b1
command run to do the PID tuning
M303 H1 S260
Log entries on the console
2/6/2020, 10:28:13 PM Auto tuning heater 1 using target temperature 260.0°C and PWM 1.00 - do not leave printer unattended 2/6/2020, 10:28:19 PM Auto tune phase 1, heater on 2/6/2020, 10:30:43 PM Auto tune phase 2, heater off 2/6/2020, 10:30:49 PM Auto tune phase 3, peak temperature was 265.0 2/6/2020, 10:34:31 PM Auto tune heater 1 completed in 378 sec Use M307 H1 to see the result, or M500 to save the result in config-override.g 2/6/2020, 10:35:57 PM M307 H1 Heater 1 model: gain 545.6, time constant 241.1, dead time 4.6, max PWM 1.00, calibration voltage 24.1, mode PID Computed PID parameters for setpoint change: P17.0, I0.510, D55.2 Computed PID parameters for load change: P17.0, I1.201, D55.2 2/6/2020, 10:36:07 PM M500
contents of config-override.g
; config-override.g file generated in response to M500 at 2020-02-06 22:36 ; Heater model parameters M307 H0 A C D S V B0 M307 H1 A C D S V B0 ; Workplace coordinates
I also noted that the thermostatic hotend cooling fan runs always, here is the configuration for heaters and fans as by the reprap configurator:
; Heaters M308 S0 P"temp0" Y"thermistor" T100000 B4138 ; configure sensor 0 as thermistor on pin temp0 M950 H0 C"out0" T0 ; create bed heater output on out0 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"temp1" Y"thermistor" T100000 B4138 ; configure sensor 1 as thermistor on pin temp1 M950 H1 C"out1" T1 ; create nozzle heater output on out1 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 ; Fans M950 F0 C"out3" Q500 ; create fan 0 on pin out3 and set its frequency M106 P0 S0 H-1 ; set fan 0 value. Thermostatic control is turned off M950 F1 C"out4" Q500 ; create fan 1 on pin out4 and set its frequency M106 P1 S1 H1 T45 ; set fan 1 value. Thermostatic control is turned on M950 F2 C"out5" Q500 ; create fan 2 on pin out5 and set its frequency M106 P2 S1 H-1 ; set fan 2 value. Thermostatic control is turned off
-
@oliof said in RepRapFirmware 3.01-beta 3 released:
Hi,
I just tried PID tuning my hotend and while M307 H1 shows a result, M500 does not save a valid line to config-override.gThat's a known DSF issue, affecting Duet 3 + RPi users.
-
And interestingly enough, moving the fan from out4 to out7 made thermostatic control work.
-
@dc42 said in RepRapFirmware 3.01-beta 3 released:
Please check whether you still have these 2 issues using the new binary at https://www.dropbox.com/sh/3azy1njy3ayjsbp/AACquxr2m00eV568RZg5QG5wa?dl=0.
-
All endstop inputs are visible, including the hidden ones
-
"abort / while" I could not find any change
Print movements are stopped, but the printer status remains printing
And "while" only works as expected with M400 -
Status tool is not yet correct
After once on active/standby
-
-
@zerspaner_gerd, I can reproduce that issue now, although it's slightly different: the status is still Printing, but there is no abort message on the console. I will look into it.
-
This issue ('abort' command left status as 'printing') is fixed in release 3.01RC1, which I hope to make available later today.
Tool states and heater states are distinct. In particular, a tool may be in Standby but its heaters may have been turned off.
-
Is if ... continue already implemented?
I am toying around a little with the conditional code:while iterations < 10 echo "Curent tool temp " ^ heat.sensors[tools[state.currentTool].heaters[0]].lastReading M98 P"wipe.g" G4 S5 if heat.sensors[tools[state.currentTool].heaters[0]].lastReading < {tools[state.currentTool].active[0]-2.0} continue if heat.sensors[tools[1].heaters[0]].lastReading > {heat.coldExtrudeTemperature < tools[1].standby[0] ? tools[1].standby[0] : heat.coldExtrudeTemperature} continue break
And it seems I need to split all the conditions a little, otherwise the while() condition becomes very long. 'continue' and 'break' would work, but I am getting an 'Error: Bad command: continue'
-
I have fixed 'continue' in 3.01-RC1 too.
-
Now that RRF 3.01-RC1 is released, I am locking this thread.