RepRapFirmware 3.01beta1 released

garyd9

@dc42
With the build from your dropbox...

Error: in file macro, line 18 column 12: unknown value abs

The line in question:

if abs(move.calibrationDeviation.deviation - move.initialDeviation.deviation) < 0.02

dc42

@garyd9, try enclosing the whole expression in { } so that the round brackets are not treated as enclosing comments.

The deviation value is RMS so it is always positive, unlike the mean.

dc42

I've just put 3.01-beta1+1 (2020-01-17b3) binaries at https://www.dropbox.com/sh/3azy1njy3ayjsbp/AACquxr2m00eV568RZg5QG5wa?dl=0. These support additional OM variables, including extruder parameters such as pressure advance.

The format for driver IDs may change in future beta releases. I am currently returning strings such as "3.1" for driver 1 on board 3; but I may change this to return 301 in this case, i.e. 100*board_id + driver_number. Whichever I choose, I will allow the format returned by the OM variable to be used in M584, M569 etc.

Danal

@dc42 said in RepRapFirmware 3.01beta1 released:

but I may change this

If you are taking votes/opinions, overall compatibility with the pin labeling nomenclature seems desirable.

garyd9

@dc42 said in RepRapFirmware 3.01beta1 released:

@garyd9, try enclosing the whole expression in { } so that the round brackets are not treated as enclosing comments.

The deviation value is RMS so it is always positive, unlike the mean.

About being positive, that's true, but the difference between means might be negative, so I want to get the absolute value of the difference...

As for using curly braces, I'm not having much luck with that. Perhaps because I'm not quite sure where, exactly, the curly braces should be. Here's some of the things I tried, followed by the resulting error:

if {abs(move.calibrationDeviation.deviation - move.initialDeviation.deviation) < 0.002}
Error: in file macro, line 16 column 91: expected ')'

if abs{(move.calibrationDeviation.deviation - move.initialDeviation.deviation)} < 0.002
Error: in file macro, line 16 column 11: unknown value abs

if abs{move.calibrationDeviation.deviation - move.initialDeviation.deviation} < 0.002
Error: in file macro, line 16 column 11: unknown value abs

if abs({move.calibrationDeviation.deviation - move.initialDeviation.deviation}) < 0.002
Error: in file macro, line 16 column 12: unknown value abs

{if abs(move.calibrationDeviation.deviation - move.initialDeviation.deviation) < 0.002}
Error: Bad command: {if abs(move.calibrationDeviation.deviation - move.initialDeviation.deviation) < 0.002}

To be absolutely clear, my intention is to get the absolute value of the difference of the two deviations, and compare that to 0.002

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.