RepRapFirmware 3.01-RC1 released

dc42

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

@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

@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

@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

@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

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

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

@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

@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

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

appjaws

@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

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

@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

@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

@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

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

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

@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

@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

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();
		}