RepRapFirmware 3.01-beta 3 released

dc42

Those M307 commands for non-existent heaters are probably in config-override.g and were put there by RRF2. You can delete them.

zerspaner_gerd

I am currently looking for the endstop inputs of E0 (e0stop) and E1 (e1stop)
M409 K"sensors.endstops" F"v" shows only three

dc42

@zerspaner_gerd said in RepRapFirmware 3.01-beta 3 released:

I am currently looking for the endstop inputs of E0 (e0stop) and E1 (e1stop)
M409 K"sensors.endstops" F"v" shows only three

The sensors.endstops variable only reports inputs configured as endstops. I need to add a separate section for other inputs.

Possible temporary workaround: create two additional axes e.g. U and V, and hide them using the M584 P parameter. Then you can assign those two endstop inputs to those axes using M574, and then they should be visible in sensors.endstops.

zerspaner_gerd

Thank you

@dc42 said in RepRapFirmware 3.01-beta 3 released:

and hide them using the M584 P parameter.

The axes must be visible so that one can see the end stop.
But I can continue to play with it

dc42

I'll change it in the next build to include endstops for invisible axes.

zerspaner_gerd

Somehow I came across strange things, here are my examples
Trigger 2 is triggered permanently
Trigger 1 is confirmed with a finger

Loop does not work:

G28 X Y
G0 X10 Y200 F1000
M400
M18 X Y
M400 

while sensors.endstops[2].triggered	; == false
	;echo "sensor wakü", sensors.endstops[2].triggered
	; M291 P"TEST1234" R"TEST" S2
	if sensors.endstops[1].triggered
		abort "TEST abort"


echo "ENDE"

The loop works with the following code:

G28 X Y
G0 X10 Y200 F1000
M400
M18 X Y
M400 

while sensors.endstops[2].triggered	; == false
	;echo "sensor wakü", sensors.endstops[2].triggered
	; M291 P"TEST1234" R"TEST" S2
	if sensors.endstops[1].triggered
		abort "TEST abort"
M400

echo "ENDE"

But the abort function does not work, the printing is not canceled
With this code the abort function works

G28 X Y
G0 X10 Y200 F1000
M400
M18 X Y
M400 

while sensors.endstops[2].triggered	; == false
	;echo "sensor wakü", sensors.endstops[2].triggered
	; M291 P"TEST1234" R"TEST" S2
	if sensors.endstops[1].triggered
		break
M400

if sensors.endstops[1].triggered
	abort "TEST abort"

The abort function only seems to work if it is at the very end of the file.
(Also works in a macro as soon as it is at the end of the macro)

Could someone test this on their Duet?

dc42

I have tested this slightly modified version on my Duet WiFi powered delta running 3.01beta3:

G28
G1 Z350 F6000
M400 

while !sensors.endstops[0].triggered	; == false
	;echo "sensor wakü", sensors.endstops[2].triggered
	; M291 P"TEST1234" R"TEST" S2
	if sensors.endstops[1].triggered
		abort "TEST abort"
M400

echo "ENDE"

I invoke it from within a print file, and it works as it should. It homes the printer, goes down, then waits for me to trigger the X endstop. If I am not holding the Y endstop down when i do that, it carries on printing and echoes ENDE. If I am holding down the y endstop at that time, it aborts the print and echoes TEST abort.

zerspaner_gerd

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.
abort test abort.jpg

With "abort" at the end of the file, the printing movements are stopped, but the printer status remains "Printing/Processing"
abort if test abort ergebnis_LI.jpg

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.)

zerspaner_gerd

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

dc42

Please check whether you still have these 2 issues using the new binary at https://www.dropbox.com/sh/3azy1njy3ayjsbp/AACquxr2m00eV568RZg5QG5wa?dl=0.

oliof

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.g

System 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

dc42

@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.g

That's a known DSF issue, affecting Duet 3 + RPi users.

oliof

And interestingly enough, moving the fan from out4 to out7 made thermostatic control work.

zerspaner_gerd

@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

dc42

@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.

dc42

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.

DaBit

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'

dc42

I have fixed 'continue' in 3.01-RC1 too.

dc42

Now that RRF 3.01-RC1 is released, I am locking this thread.