RepRapFirmware 3.01-RC1 released


  • administrators



  • @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.



  • @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>
    }
    

  • administrators

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



  • @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


  • administrators

    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.



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



  • @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.


  • administrators

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



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



  • @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



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


  • administrators

    @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
    

  • administrators

    @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?



  • @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.



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


  • administrators

    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.


  • administrators

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



  • @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.


  • administrators

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


  • @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'.



  • @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.


  • administrators

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



  • @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
             }
          }
       ]
    }
    

  • administrators

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


Log in to reply