RepRapFirmware 3.01-RC1 released

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

DaBit

@dc42 said in RepRapFirmware 3.01-RC1 released:

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, at least in tpostX.g and regular macros.

@dc42 said in RepRapFirmware 3.01-RC1 released:

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

Now that's quick!
Printer is busy, I will give it a shot when it is free.

@dc42 said in RepRapFirmware 3.01-RC1 released:

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

On my machine RRF 3.01-RC1 shows correct behaviour: with auxiliary 5V applied to a Duet Wifi 2, the 24V main supply switched using PS_ON the axes go to 'not homed'.

gtj0

@dc42 said in RepRapFirmware 3.01-RC1 released:

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

Well, I just went back to 3.01-BETA2 and it's still not working. It's pretty bizarre. Ah well.

dc42

Are you certain that VIN really is dropping to below 9.5V? What voltage does DWC report? Which Duet are you using?

gtj0

@dc42 said in RepRapFirmware 3.01-RC1 released:

Are you certain that VIN really is dropping to below 9.5V? What voltage does DWC report? Which Duet are you using?

Duet3. Tried standalone mode as well as DSF. When I issue an M81, the LEDs and fans go off and I can hear the motors snap to a full step.

M409 K"boards"
{
   "flags" : "",
   "key" : "boards",
   "result" : [
      {
         "canAddress" : 0,
         "firmwareFileName" : "Duet3Firmware_MB6HC.bin",
         "firmwareVersion" : "3.01-RC1",
         "iapFileNameSBC" : "Duet3_SBCiap_MB6HC.bin",
         "iapFileNameSD" : "Duet3_SDiap_MB6HC.bin",
         "mcuTemp" : {
            "current" : 35.8,
            "max" : 36.1,
            "min" : 32.6
         },
         "name" : "Duet 3 MB6HC",
         "shortName" : "MB6HC",
         "v12" : {
            "current" : 0.3,
            "max" : 12.2,
            "min" : 0.3
         },
         "vIn" : {
            "current" : 0.3,
            "max" : 25.7,
            "min" : 0.2
         }
      }
   ]
}

dc42

I've been testing this on Duet 2. I'll try on Duet 3 tomorrow.

gtj0

@dc42 said in RepRapFirmware 3.01-RC1 released:

I've been testing this on Duet 2. I'll try on Duet 3 tomorrow.

Thanks!

dc42

Confirmed, it doesn't work on Duet 3. This is because Duet 3 has separate code to provide a fast response to loss of 12V power in order to protect the drivers, which preempts that code I added. I will fix it in the next build.