RepRapFirmware 3.01-RC1 released

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.

dc42

Fixed in latest commit.

SpoonUnit

I've just migrated from 2.04 to 3.01 (via 3.0). I must admit, I didn't stop at 3.0 to check everything was working. Anyway, after a few hiccoughs, I have almost everything working from a control perspective. All tools are registered and reporting the correct temp, all axes can be homed, tools can be heated, bed can be heated. Pretty happy with this, I moved to run my first job, which starts with mesh bed leveling, and that's where I encountered the first issue. Once G29 was issued, the head moved much slower than expected to the first point, but then held there. I looked at DWC to find it waiting for manual bed leveling. It wanted me to raise the bed up to the head. Not wanting to do this for 40 points, I quickly realised there's no way to abort this process from DWC once it begins. You can click OK, but you probably can't get to the emergency stop button before the next point, so you're just trapped. Even booting DWC up on a second browser instance resulted in the dialog popping up which I couldn't cancel. So first issue - could ideally do with a way of cancelling manual bed leveling.

However, I can't really see what's wrong with the setup. My starting point is the setup I have for Duet 2, but adjusted based on @dc42 post on the e3d forum.

M558 P8 C"zstop" H3 F360 I0 T35000 	; Set Z probe type to switch, the axes for which it is used and the dive height + speeds
G31 P200 X0 Y0 Z0	 				; Set Z probe trigger value, offset and trigger height
M557 X10:290 Y20:180 S40 			; Define mesh grid

The only difference is my mesh definition as I'm not ready to switch to having 0,0 in the center of my bed. As far as I can see, there's no other setup for the automated mesh bed leveling, so I'm not sure what I'm missing here? I trigger the bed measurement with a simple G29, which doesn't seem to have been altered for RRF3 (https://duet3d.dozuki.com/Wiki/Gcode#Section_G29_Mesh_bed_probe). Perhaps I need to specify S0 even though that should be the default?

The second issue I have relates to the setup of a thermistor to measure the bed temperature. While the heating plate itself has an inbuilt temperature report, the physical bed itself takes some time longer to reach working temperature. To measure this, I've mounted a thermistor against the bed itself, and plugged that into duex.e5temp. The only way I could figure out how to use this to hold processing in Duet 2 was to define this as a chamber, and then use M191 P0 S65 to cause processing to wait for the bed to report a sufficient temperature to continue. In Duet 2, I defined this like this:

M305 S"P0" P6 R4700 T100000 B4388 			
M141 H6 P0

Even with no actual heater assigned to the chamber, the chamber would appear in DWC and I could use M191. I kinda knew this was a hack, but now I need a similar hack for Duet 3 as I don't have a heater for this chamber. So far, I've just (ab)used duex.e3heat to act as the ghost heater, which then means I have no heater for tool 3.

M308 S6 P"duex.e5temp" Y"thermistor" A"T0" T100000 B4725 C7.06e-8 	; Set thermistor
M950 H6 C"duex.e3heat" T6					; Bed heater
M141 P0 H6

This looks like it'll work, but I wonder if there's a better way?

SpoonUnit

OK. Have made a bit of progress. It seems that I'm struggling as I'm using the same tool (a microswitch) for both a Z endstop and a Z probe. By executing commands from config.g individually, I can see that once this executes:

M574 Z1 S1 P"zstop"   ; Z min active high endstop switch

this then fails

M558 P8 C"zstop" H3 F360 I0 T35000

I can't quite fathom whether this should or shouldn't be the case from the docs.

"Note, if your Z probe is connected to the Z endstop input, in RRF 3.0 on Duet 2 boards only (not in RRF 3.01 and later, and not in RRF 3.0 on Duet 3), that input is by default pre-assigned to be used by the Z endstop, so you must free it up first."

If I read it right, this whole statement doesn't apply as this is RRF 3.01, albeit an RC, not final release. So does this mean I shouldn't need to free it up? I find that if I do free it up, the the M558 command will work, and I can then execute G29 which then works properly. At this stage then, it feels like my homing statement will need to clear the pin and define M574, and my levelling process will need to clear the pin and define M558. Is this the intended final outcome or am I missing a simple alternative?

gtj0

@dc42 said in RepRapFirmware 3.01-RC1 released:

Fixed in latest commit.

Thanks!

gtj0

@dc42 said in RepRapFirmware 3.01-RC1 released:

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.

@dc42 said in RepRapFirmware 3.01-RC1 released:

Fixed in latest commit.

Confirmed fixed, thanks.