RepRapFirmware 3.01beta1 released

Danal

@garyd9 said in RepRapFirmware 3.01beta1 released:

if {abs(move.calibrationDeviation.deviation - move.initialDeviation.deviation) < 0.002}

I get no error with the format above. Running:

Firmware: RepRapFirmware for Duet 3 MB6HC v0.6 or 1.0 3.01-beta1+1 (2020-01-17b3)

garyd9

@Danal said in RepRapFirmware 3.01beta1 released:

@garyd9 said in RepRapFirmware 3.01beta1 released:

if {abs(move.calibrationDeviation.deviation - move.initialDeviation.deviation) < 0.002}

I get no error with the format above. Running:

Firmware: RepRapFirmware for Duet 3 MB6HC v0.6 or 1.0 3.01-beta1+1 (2020-01-17b3)

Odd. I'm also running "3.01-beta1+1 (2020-01-17b3)". Perhaps because I'm running it on a Duet2 (duet wifi)?

I'll try again in 5-6 hours (if I'm still awake) when my current print finishes...

I will say that I'm starting to wonder if I should "upgrade" to a duet3. While I really don't need the extra ports or capabilities, the newer versions of RRF3 seem to bog down the older boards. I started to get hiccups on my delta at even only 150mm/sec movements now.

Danal

Yeah, and I'm running a Pi. It is very unclear to me how much gcode is processed on the DSF on the Pi vs actually being passed to the Duet.

dc42

@Danal said in RepRapFirmware 3.01beta1 released:

Yeah, and I'm running a Pi. It is very unclear to me how much gcode is processed on the DSF on the Pi vs actually being passed to the Duet.

GCodes commands are pre-parsed on the Pi, but most of them are just passed in the parsed state to the Duet. A few such as M98 and M32 are processed partly on the Pi.

I am currently looking at the why RRF3 has hiccups at lower step rates than RRF2.

garyd9

@Danal said in RepRapFirmware 3.01beta1 released:

@garyd9 said in RepRapFirmware 3.01beta1 released:

if {abs(move.calibrationDeviation.deviation - move.initialDeviation.deviation) < 0.002}

I get no error with the format above. Running:
Firmware: RepRapFirmware for Duet 3 MB6HC v0.6 or 1.0 3.01-beta1+1 (2020-01-17b3)

I've confirmed that I DO get an error similar to "Error: in file macro, line 22 column 90: expected ')'" with the same statement (followed by a newline, tab, and 'break' statement':

if{abs(move.calibrationDeviation.deviation - move.initialDeviation.deviation) < 0.002}

I'm using a Duet Wifi 1.04 with firmware "RepRapFirmware for Duet 2 WiFi/Ethernet 3.01-beta1+1 (2020-01-17b3)" (No SBC option exists.) I wonder if the same problem exists for non-SBC Duet3 users.

kraegar

I couldn't get abs to work either, so just nested the if statements. Ugly, but I figured it was something I was doing wrong. Also testing on a duet2.

dc42

@garyd9 said in RepRapFirmware 3.01beta1 released:

abs(move.calibrationDeviation.deviation - move.initialDeviation.deviation)

I confirm there is a problem with functions. Looking into it now.

appjaws

When I am running my macro " Conditional auto bed levelling using 3 Z motors" an error message is displayed during execution, "RESPONSE TOO LONG SEE CONSOLE".
Nothing is reported in the console log and the macro continues anyway.
Just thought you should know.

; Conditional auto bed levelling using 3 Z motors

M561 ; clear any existing bed transforms

if heat.heaters[0].current <60
M291 P"Preheating to bed to 65 and nozzle to 195 for accurate probing"
M140 S60 ; Set bed temperature to 60
M116 ; waiting for bed to reach temperature
if heat.heaters[0].current <65 || heat.heaters[1].current <190
M140 S65 ; Set bed temperature to 65
G10 S195 ; Set current tool temperature to 195C
M116 ; waiting for bed and nozzle to reach temperature

; If the printer hasn't been homed, home it
if !move.axes[0].homed || !move.axes[1].homed || !move.axes[2].homed
G28

G1 Z7.5

;Run an initial 3-point Probe

M291 P"auto bed levelling using 3 Z motors started"

M98 P"0:/macros/Conditional/bedlevel.g"

while true
if iterations = 5
abort "Too many auto calibration attempts"
echo "iterations = ", iterations
if move.initialDeviation.deviation < 0.01
if move.calibrationDeviation.deviation < move.initialDeviation.deviation + 0.005
if move.calibrationDeviation.deviation > move.initialDeviation.deviation - 0.005
break
echo "Repeating calibration because initial deviation (" ^ move.initialDeviation.deviation ^ "mm) must be < 0.01"
echo "and (" ^ move.calibrationDeviation.deviation ^ "mm) must be within 0.005 of initialDeviation"

M98 P"0:/macros/Conditional/bedlevel.g"

echo "Auto calibration successful, deviation", move.calibrationDeviation.deviation ^ "mm"
echo "Auto calibration successful, initialDeviation", move.initialDeviation.deviation ^ "mm"

M140 S0 ; Set bed temperature to 0C
G10 S0 ; Set current tool temperature to 0C
G1 X150 Y100; Move to bed centre
G30; reset Z0

G1 X50 Y230 F24000 ; move the head to park
M291 P"auto bed levelling using 3 Z motors completed"

DaBit

Probably kicking in an open door, but just in case it might help: M409 or the rr_model HTTP returns a quite empty object on firmware 3.01-beta2+1 (2020-01-24b1) on Duet2:

{"key":"","flags":"","result":{"boards":[{}],"fans":[{},{}],"heat":{},"job":{},"move":{},"network":{},"sensors":{},"state":{},"tools":[{},{}]}}

Accessing the OM from Gcode works; 'echo boards[0].firmwareFileName' returns 'Duet2CombinedFirmware.bin'
No problem, beta firmware etcetera. I justed wanted to check if I could access tool setpoint temperatures.

dc42

@DaBit said in RepRapFirmware 3.01beta1 released:

Probably kicking in an open door, but just in case it might help: M409 or the rr_model HTTP returns a quite empty object on firmware 3.01-beta2+1 (2020-01-24b1) on Duet2:
{"key":"","flags":"","result":{"boards":[{}],"fans":[{},{}],"heat":{},"job":{},"move":{},"network":{},"sensors":{},"state":{},"tools":[{},{}]}}
Accessing the OM from Gcode works; 'echo boards[0].firmwareFileName' returns 'Duet2CombinedFirmware.bin'
No problem, beta firmware etcetera. I justed wanted to check if I could access tool setpoint temperatures.

Read the upgrade notes.

DaBit

Oops, sorry for that.