RepRapFirmware 3.01-RC1 released

dc42 · 8 Feb 2020, 17:16

You can find it at https://github.com/dc42/RepRapFirmware/releases/tag/3.01-RC1 and the upgrade notes at https://github.com/dc42/RepRapFirmware/blob/v3-dev/WHATS_NEW_RRF3.md.

chas2706 · 8 Feb 2020, 21:04

@dc42 Does this apply to Duet3 + SBC because when I do apt-get update, apt-get upgrade it does not upgrade to 3.01-RC1.

gtj0 · 8 Feb 2020, 23:14

@dc42 I think the change to set the axes unhomed on ATX power off got reverted.

M115
FIRMWARE_NAME: RepRapFirmware for Duet 3 MB6HC v0.6 or 1.0 FIRMWARE_VERSION: 3.01-RC1 ELECTRONICS: Duet 3 MB6HC FIRMWARE_DATE: 2020-02-08b1

 M408 S2
{
   "coords" : {
      "axesHomed" : [
         1,
         1,
         1
      ],
      "extr" : [
         0
      ],
      "machine" : [
         0,
         0,
         4.9
      ],
      "wpl" : 1,
      "xyz" : [
         0,
         0,
         4.9
      ]
   },
   "currentTool" : -1,
   "params" : {
      "atxPower" : 0,
      "babystep" : 0,
      "extrFactors" : [
         100
      ],
   <snip>
}

dc42 · 9 Feb 2020, 10:27

@gtj0 said in RepRapFirmware 3.01-RC1 released:

@dc42 I think the change to set the axes unhomed on ATX power off got reverted.

M115
FIRMWARE_NAME: RepRapFirmware for Duet 3 MB6HC v0.6 or 1.0 FIRMWARE_VERSION: 3.01-RC1 ELECTRONICS: Duet 3 MB6HC FIRMWARE_DATE: 2020-02-08b1

I've just tested it, and it's working for me. To be clear, it's the loss of VIN voltage (to below about 9.5V) that sets the axes to not homed.

chas2706 · 9 Feb 2020, 11:32

@dc42

@dc42 Does this apply to Duet3 + SBC because when I do apt-get update, apt-get upgrade it does not upgrade to 3.01-RC1.

This is what I get from M115:

M115
FIRMWARE_NAME: RepRapFirmware for Duet 3 MB6HC v0.6 or 1.0 FIRMWARE_VERSION: 3.0 ELECTRONICS: Duet 3 MB6HC FIRMWARE_DATE: 2020-01-03b3

dc42 · 9 Feb 2020, 11:53

For Duet 3 with SBC, for now you will have to update RRF manually by uploading the firmware binary on the System page of DWC. Make sure you are running the correct version of DSF, 1.2.4.0 or a more recent update.

appjaws · 9 Feb 2020, 11:59

I have loaded firmware 3.01-RC1 and have encountered the following error.
Error: in file macro, line 31 column 39: expected numeric operand.

This macro worked with firmware 3.01-Beta3.
I changed the Object model variables move.initialDeviation and move.calibrationDeviation to move.calibration.initial and move.calibration.final.
It appears that move.calibration.initial and move.calibration.final is not working.
The column 39 is at the end of the line.
this is the macro

; Conditional auto bed levelling using 3 Z motors

M561 ; clear any existing bed transforms
;check heaters
M291 P"Preheating bed and nozzle for accurate probing"
if heat.heaters[0].current <=65 && heat.heaters[1].current <=195
if heat.heaters[0].current <60
M140 S60 ; Set bed temperature to 60
M116 ; waiting for bed to reach temperature
M140 S65
if heat.heaters[1].current <195
M104 S195 ; Set current tool temperature to 195C
M116 S3 ; waiting for heaters 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

;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 = 6
M291 P"auto bed levelling FAILED"
M140 S0 ; Set bed temperature to 0C
M104 S0 ; Set current tool temperature to 0C
G1 X50 Y230 F24000 ; move the head to park
abort "Too many auto calibration attempts"
else
echo "Test = ", iterations+1
if move.calibration.initial < 0.01The
if move.calibration.final.deviation < move.calibration.initial + 0.005
if move.calibration.final.deviation > move.calibration.initial - 0.005
break
echo "Repeating calibration because initial deviation (" ^ move.calibration.initial ^ "mm) must be < 0.01"
echo "and (" ^ move.calibration.final.deviation ^ "mm) must be within 0.005 of initialDeviation"
M291 P{"Test No " ^iterations+1 ^" Initial Deviation " ^move.calibration.initial ^" Deviation " ^move.calibration.final.deviation}
M98 P"0:/macros/Conditional/bedlevel.g"
echo "Auto calibration successful, deviation", move.calibration.final.deviation ^ "mm"
echo "Auto calibration successful, initialDeviation", move.calibration.initial ^ "mm"
M291 P{"Auto Calibration Success, Initial Deviation " ^move.calibration.initial ^" Deviation " ^move.calibration.final.deviation}
G28 Z
G1 X50 Y228 F24000 ; move the head to park
M291 P"Auto bed levelling using 3 Z motors completed, head moved to park position"

chas2706 · 9 Feb 2020, 12:11

@dc42 said in RepRapFirmware 3.01-RC1 released:

For Duet 3 with SBC, for now you will have to update RRF manually by uploading the firmware binary on the System page of DWC. Make sure you are running the correct version of DSF, 1.2.4.0 or a more recent update.

Ok will do Thanks.

dc42 · 9 Feb 2020, 12:46

@appjaws said in RepRapFirmware 3.01-RC1 released:

I have loaded firmware 3.01-RC1 and have encountered the following error.
Error: in file macro, line 31 column 39: expected numeric operand.

This macro worked with firmware 3.01-Beta3.
I changed the Object model variables move.initialDeviation and move.calibrationDeviation to move.calibration.initial and move.calibration.final.

This is line 31:

if move.calibration.initial < 0.01The

If that's really in your file, them I am not surprised that it doesn't work.

appjaws · 9 Feb 2020, 12:55

No sorry that "the" is not in the file, so that is not the problem

appjaws · 9 Feb 2020, 13:34

@appjaws said in RepRapFirmware 3.01-RC1 released:

It appears that move.calibration.initial and move.calibration.final is not working.

It looks as if these objects are returning null

DaBit · 9 Feb 2020, 13:53

Great, continue works now. Now I can implement 'M116 with wipes over silicone during waiting' without too much fiddling.

Question: we do have state.currentTool. Is there also a previousTool somewhere or a workaround for obtaining the previous toolnumber?

Current (yet untested) tpost0.g:

 ; Make sure we are at the purge position
M98 P"purgeposition.g"
 
; Start toolchange cooling helper fan
M106 P2 S255
 
; Wait until the current tool has heated up and the previous tool has cooled down. Wipe every 5 seconds
while iterations < 20
	G4 S5
	M98 P"wipe.g"
	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
 
; Stop toolchange cooling helper fan
M106 P2 S0
 
; Undo retraction and prime extruder (200mm/min is 8.02mm^3/s)
M83
G1 E3 F1500
G1 E5 F200
 
; Retract, wipe once more
G1 E-1 F1500
M98 P"wipe.g"
 
; Return to pre-toolchange location, and unretract
G1 R2 X0 Y0 Z0.5 F12000
G1 R2 X0 Y0 Z0 E1 F1500

In the 'has the previous tool cooled down enough yet?' logic (second if() in the while() loop) I have fixed tool numbers now. I would like to split the code in a macro that can be used for any tool.

I could put the waiting for cooling down in tfree and waiting for warming up in tpost, but I would prefer to do both in tpost for the new tool.

dc42 · 9 Feb 2020, 14:41

@appjaws, I just ran the following on my delta (before I ran auto calibration) running 3.01RC1:

 09/02/2020, 12:49:41 	echo move.calibration.final.deviation
0.000
09/02/2020, 12:49:17 	echo move.calibration.initial.deviation
0.000

So they are working for me. What do those commands return on your Duet?

Are you certain you are running 3.01-RC1? What does M115 return? I get this:

 09/02/2020, 14:45:29 	m115
FIRMWARE_NAME: RepRapFirmware for Duet 2 WiFi/Ethernet FIRMWARE_VERSION: 3.01-RC1 ELECTRONICS: Duet WiFi 1.0 or 1.01 FIRMWARE_DATE: 2020-02-08b3

dc42 · 9 Feb 2020, 14:51

@DaBit said in RepRapFirmware 3.01-RC1 released:

Question: we do have state.currentTool. Is there also a previousTool somewhere or a workaround for obtaining the previous toolnumber?

Not yet, but I can add it in a future release. My thinking is that it would only be applicable if you switched directly from another tool to the current one. If you did T-1 followed by T1, then previousTool would be -1. Do you agree that it should work like this?

Danal · 9 Feb 2020, 15:31

@dc42 said in RepRapFirmware 3.01-RC1 released:

@DaBit said in RepRapFirmware 3.01-RC1 released:

Question: we do have state.currentTool. Is there also a previousTool somewhere or a workaround for obtaining the previous toolnumber?

Not yet, but I can add it in a future release. My thinking is that it would only be applicable if you switched directly from another tool to the current one. If you did T-1 followed by T1, then previousTool would be -1. Do you agree that it should work like this?

Yes.

appjaws · 9 Feb 2020, 16:03

From the upgrade notes at https://github.com/dc42/RepRapFirmware/blob/v3-dev/WHATS_NEW_RRF3.md.
Object model variables move.initialDeviation and move.calibrationDeviation are renamed to move.calibration.initial and move.calibration.final. If you use these variables in bed.g or in other macro files then you will need to update those files.

I cut and pasted the new code, not realizing that I needed to put".deviation" at the end.

So my fault, my macro now works.
Thanks for your help.

dc42 · 9 Feb 2020, 16:39

I'm glad you got it working! Each of those values has both .mean and .deviation components, although the mean of the final value should always be zero if calibration was successful. the same was true in 3.01beta3, but possibly not in the very early 3.01 betas.

dc42 · 9 Feb 2020, 17:10

@Danal said in RepRapFirmware 3.01-RC1 released:

@dc42 said in RepRapFirmware 3.01-RC1 released:

@DaBit said in RepRapFirmware 3.01-RC1 released:

Question: we do have state.currentTool. Is there also a previousTool somewhere or a workaround for obtaining the previous toolnumber?

Not yet, but I can add it in a future release. My thinking is that it would only be applicable if you switched directly from another tool to the current one. If you did T-1 followed by T1, then previousTool would be -1. Do you agree that it should work like this?

Yes.

I have implemented state.previousTool in the internal RRF3 builds at https://www.dropbox.com/sh/3azy1njy3ayjsbp/AACquxr2m00eV568RZg5QG5wa?dl=0.

gtj0 · 9 Feb 2020, 17:21

@dc42 said in RepRapFirmware 3.01-RC1 released:

@gtj0 said in RepRapFirmware 3.01-RC1 released:

@dc42 I think the change to set the axes unhomed on ATX power off got reverted.

M115
FIRMWARE_NAME: RepRapFirmware for Duet 3 MB6HC v0.6 or 1.0 FIRMWARE_VERSION: 3.01-RC1 ELECTRONICS: Duet 3 MB6HC FIRMWARE_DATE: 2020-02-08b1

I've just tested it, and it's working for me. To be clear, it's the loss of VIN voltage (to below about 9.5V) that sets the axes to not homed.

I just retried it with your binary. I do get the "12V under-voltage event (9.5V)" message but the axes still show homed. Also looked using M409 K"move.axes"with the same result.

dc42 · 9 Feb 2020, 18:35

I've just tried it on a second machine (E3D Tool Changer). It's working correctly on that machine too. With both USB and VIN power applied, I home the printer. Then I turn off VIN power. All axes go to "not homed".

The code that does this is at Platform.cpp(1015):

 #if HAS_VOLTAGE_MONITOR
		if (currentVin < driverPowerOffAdcReading)
		{
			driversPowered = false;
			++numVinUnderVoltageEvents;
			lastVinUnderVoltageValue = currentVin;					// save this because the voltage may have changed by the time we report it
			reprap.GetGCodes().SetAllAxesNotHomed();
		}

	M408 S2
	{
	"coords" : {
	"axesHomed" : [
	1,
	1,
	1
	],
	"extr" : [
	0
	],
	"machine" : [
	0,
	0,
	4.9
	],
	"wpl" : 1,
	"xyz" : [
	0,
	0,
	4.9
	]
	},
	"currentTool" : -1,
	"params" : {
	"atxPower" : 0,
	"babystep" : 0,
	"extrFactors" : [
	100
	],
	<snip>
	}

	; Make sure we are at the purge position
	M98 P"purgeposition.g"

	; Start toolchange cooling helper fan
	M106 P2 S255

	; Wait until the current tool has heated up and the previous tool has cooled down. Wipe every 5 seconds
	while iterations < 20
	G4 S5
	M98 P"wipe.g"
	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

	; Stop toolchange cooling helper fan
	M106 P2 S0

	; Undo retraction and prime extruder (200mm/min is 8.02mm^3/s)
	M83
	G1 E3 F1500
	G1 E5 F200

	; Retract, wipe once more
	G1 E-1 F1500
	M98 P"wipe.g"

	; Return to pre-toolchange location, and unretract
	G1 R2 X0 Y0 Z0.5 F12000
	G1 R2 X0 Y0 Z0 E1 F1500

	09/02/2020, 12:49:41 echo move.calibration.final.deviation
	0.000
	09/02/2020, 12:49:17 echo move.calibration.initial.deviation
	0.000

	09/02/2020, 14:45:29 m115
	FIRMWARE_NAME: RepRapFirmware for Duet 2 WiFi/Ethernet FIRMWARE_VERSION: 3.01-RC1 ELECTRONICS: Duet WiFi 1.0 or 1.01 FIRMWARE_DATE: 2020-02-08b3

	#if HAS_VOLTAGE_MONITOR
	if (currentVin < driverPowerOffAdcReading)
	{
	driversPowered = false;
	++numVinUnderVoltageEvents;
	lastVinUnderVoltageValue = currentVin; // save this because the voltage may have changed by the time we report it
	reprap.GetGCodes().SetAllAxesNotHomed();
	}