RepRapFirmware 3.01-beta 3 released


  • administrators

    Get it from https://github.com/dc42/RepRapFirmware/releases/tag/3.01-beta3.

    Users of RRF 2.x are reminded that you cannot upgrade directly to this release, you have to upgrade via RRF 3.0; and that substantial changes to config.g are needed when transitioning from RRF2 to RRF3.



  • I can now see Fans 0,1 & 2 in DWC which weren't there in beta2. Is this something to do with:

    A fan that hadn't explicitly been configured using M106 with some parameter other than P or S was reported to DWC as being non-controllable

    If I comment out these lines from config.g they disappear

    M950 F0 C"fan0"     ; Default Fan definition as these were removed in RRF 3.01beta1 (V38)
    M950 F1 C"fan1"     ; Default Fan definition as these were removed in RRF 3.01beta1 (V38)
    M950 F2 C"fan2"     ; Default Fan definition as these were removed in RRF 3.01beta1 (V38)
    
    

    Apart from fan0 on the Duet which is the part cooling fan by default all my other fans are on the Duex. Fans 4 & 5 are thermo controlled and therefore invisible, Fan 3 is LED lights and is manually controlled so visible.

    ;---- 12V Fans on Duex2 -----------------------
    
    M950 F3 C"duex.fan3" Q500                               ; create fan 3 on pin duex.fan3 and set its frequency (V35)
    M106 P3 S0.1 H-1 B0 C"Lights"                           ; set fan 3 value. LED Lights (V35)
    
    M950 F4 C"duex.fan4" Q500                               ; create fan 4 on pin duex.fan4 and set its frequency (V35)
    M106 P4 S1.0 H2:3 T26:65 L0.4 C"Enclosure Fans"         ; set fan 4 value. Thermostatic control on. Linked to MCU & Stepper Drivers (V35)
    
    M950 F5 C"duex.fan5" Q500                               ; create fan 5 on pin duex.fan5 and set its frequency (V37)
    M106 P5 S1.0 H1 T50 C"Hotend Fan"                       ; set fan 5 value. Thermostatic control is turned on. Linked to Hotend (H1) (V37)
    
    M563 P0 D0 H1 S"Extruder"                 ; Define tool 0 - uses Drive 0 (E0), Heater 1. Tool Fan is Fan0 by default (part-cooling fan) (V17)
    G10 P0 X0 Y0 Z0                           ; Set tool 0 axis offsets
    G10 P0 R0 S0                              ; Set initial tool 0 active and standby temperatures to 0C
    
    

    Board: Duet WiFi 1.02 or later + DueX2
    Firmware: RepRapFirmware for Duet 2 WiFi/Ethernet 3.01-beta3 (2020-01-29b1)
    Duet WiFi Server Version: 1.23
    Duet Web Control 2.0.7



  • RRF 3.01beta2
    Screenshot from 2020-01-29 14-02-21.png

    RRF 3.01beta3
    Screenshot from 2020-01-29 14-03-41.png

    Screenshot from 2020-01-29 14-22-55.png


  • administrators

    The current version of DWC makes fans 0, 1 and 2 visible by default if RRF reports them as controllable. To make other fans visible, click on the Change Visibility link in DWC. In RRF3 you can of course map fans 0, 1, 2 to whatever outputs you wish.

    We are having discussions on which fans to make visible by default, so this may change in a future version of DWC.



  • Ok, thanks. I don't want to see fans 0-2 so I'll just delete the 3 M950 commands.
    Presumably this doesn't apply to fans on the duex.


  • administrators

    @tekkydave said in RepRapFirmware 3.01-beta 3 released:

    Ok, thanks. I don't want to see fans 0-2 so I'll just delete the 3 M950 commands.
    Presumably this doesn't apply to fans on the duex.

    Yes, only use M950 to create fans you only want to use. Bear in mind that Fan 0 is the default print cooling fan; but in RRF3, Fan 0 can be on the DueX if you wish.



  • @dc42 said in RepRapFirmware 3.01-beta 3 released:

    @tekkydave said in RepRapFirmware 3.01-beta 3 released:

    Ok, thanks. I don't want to see fans 0-2 so I'll just delete the 3 M950 commands.
    Presumably this doesn't apply to fans on the duex.

    Yes, only use M950 to create fans you only want to use. Bear in mind that Fan 0 is the default print cooling fan; but in RRF3, Fan 0 can be on the DueX if you wish.

    I have my part cooling fans on the Duet as they are 24V (Vin = 24V). The other fans are all 12V so connected to the Duex. It's handy to have the option of 12 or 24V for fans that the Duex gives.



  • Hi,
    I tried the new meta commands the first time but run in some error message:

    M98 P"0:/macros/test"
    Error: in file macro, line 5 column 5: 'elif' did not follow 'if
    

    The macro is a simple test:

    if state.currentTool = 0
    	M106 P9 S0.10
    elif state.currentTool = 1
    	M106 P9 S0.20
    elif state.currentTool = 2
    	M106 P9 S0.30
    elif state.currentTool = 3
    	M106 P9 S0.40
    

    In generally it is working to the right command it issued for each tool. But every time I get the error message


  • administrators

    I confirm this issue. It appears that when you have multiple 'elif' parts, if there are multiple 'elif' parts after the 'if' or 'elif' with the true condition, the error message is generated on the second one. So if the condition on line 1 is true, the error is generated on line 5; and if the condition on line 1 is false but the condition on line 3 is true, the error is generated on line 7.

    I will fix this in the next beta.



  • @dc42 said in RepRapFirmware 3.01-beta 3 released:

    I confirm this issue. It appears that when you have multiple 'elif' parts, if there are multiple 'elif' parts after the 'if' or 'elif' with the true condition, the error message is generated on the second one. So if the condition on line 1 is true, the error is generated on line 5; and if the condition on line 1 is false but the condition on line 3 is true, the error is generated on line 7.

    I will fix this in the next beta.

    Based on the description, that must have been a challange to track down. So much so, that I'm looking forward to the github commit to see the before/after code.



  • One more question:
    When is the state.currentTool updated?

    After the tpre.g or after the tpost.g?
    Normally it should after the tpre.g, right?



  • @smoki3 said in RepRapFirmware 3.01-beta 3 released:

    One more question:
    When is the state.currentTool updated?

    After the tpre.g or after the tpost.g?
    Normally it should after the tpre.g, right?

    Based on when tool offsets are active (or not) in the various macros, the machine appears to consider the tool NOT mounted in pre, and to consider it mounted in post. I would expect that state.currentTool would follow.

    Of course, @dc42 can give the definitive answer...


  • administrators

    @Danal said in RepRapFirmware 3.01-beta 3 released:

    Based on when tool offsets are active (or not) in the various macros, the machine appears to consider the tool NOT mounted in pre, and to consider it mounted in post. I would expect that state.currentTool would follow.

    That's the intention. It should be set to n-1 just after executing tfree and to the new tool number just before executing tpost.



  • @dc42 said in RepRapFirmware 3.01-beta 3 released:

    @Danal said in RepRapFirmware 3.01-beta 3 released:

    Based on when tool offsets are active (or not) in the various macros, the machine appears to consider the tool NOT mounted in pre, and to consider it mounted in post. I would expect that state.currentTool would follow.

    That's the intention. It should be set to n-1 just after executing tfree and to the new tool number just before executing tpost.

    Yeah tried it today... Working fine 🙂



  • Been printing steadily and haven't seen any issues to report yet. Still tinkering with conditional gcode 🙂


  • administrators

    @garyd9 said in RepRapFirmware 3.01-beta 3 released:

    Based on the description, that must have been a challange to track down. So much so, that I'm looking forward to the github commit to see the before/after code.

    This is now fixed, source code committed, and new binaries put on Dropbox.



  • Running latest beta (3+1) on duet wifi I get an error

    G28 U
    Error: in file macro, line 11 column 5: 'else' did not follow 'if'
    Error: Homing failed
    

    homeU.g file

    if sensors.endstops[4].triggered 
    	if state.status == "Busy"
    		M291 P" Idle MMU loaded. Selector homing not allowed.Please unload MMU manually." S2
    
    if sensors.endstops[4].triggered 
    	if state.status == "Processing" 
    		M25
    		M291 P"printing  MMU loaded. Selector homing not allowed.Please unload MMU manually." S2	
    
    else
    	M913 U50              		 ; reduce motor current to 50% to prevent bad noises
    	M915 U S5 F0			; set stall parameters
    	G91                   		 ; use relative positioning
    	G1 H1 U5 F2000            	  ; move out 5mm
    	G1 H1 U-100 F1000       	     ; move carriage to home
    	G90                 		   ; back to absolute positioning
    	M400               		     ; make sure everything has stopped before we reset the motor currents
    	M913 U100       		    ; motor currents back to normal
    

    Was working on beta2.



  • @dc42 Apparently you and @chrishamm aren't on speaking terms because the DSF doesn't get the current axis coordinates with the latest 3.01betas.


  • administrators

    @Ntrack said in RepRapFirmware 3.01-beta 3 released:

    Running latest beta (3+1) on duet wifi I get an error
    G28 U
    Error: in file macro, line 11 column 5: 'else' did not follow 'if'
    Error: Homing failed

    Please try the new binary at https://www.dropbox.com/sh/3azy1njy3ayjsbp/AACquxr2m00eV568RZg5QG5wa?dl=0.


  • administrators

    @gtj0 said in RepRapFirmware 3.01-beta 3 released:

    @dc42 Apparently you and @chrishamm aren't on speaking terms because the DSF doesn't get the current axis coordinates with the latest 3.01betas.

    Which DSF version are you using?

    Does M408 S2 report the correct coordinates?



  • @dc42 said in RepRapFirmware 3.01-beta 3 released:

    @Ntrack said in RepRapFirmware 3.01-beta 3 released:

    Running latest beta (3+1) on duet wifi I get an error
    G28 U
    Error: in file macro, line 11 column 5: 'else' did not follow 'if'
    Error: Homing failed

    Please try the new binary at https://www.dropbox.com/sh/3azy1njy3ayjsbp/AACquxr2m00eV568RZg5QG5wa?dl=0.

    Just reinstalled the latest firmware for duet wifi .Firmware: RepRapFirmware for Duet 2 WiFi/Ethernet 3.01-beta3+1 (2020-01-30b1) . The issue is still present .


  • administrators

    @Ntrack said in RepRapFirmware 3.01-beta 3 released:

    Just reinstalled the latest firmware for duet wifi .Firmware: RepRapFirmware for Duet 2 WiFi/Ethernet 3.01-beta3+1 (2020-01-30b1) . The issue is still present .

    Thanks, I will look into it.



  • @dc42 said in RepRapFirmware 3.01-beta 3 released:

    @gtj0 said in RepRapFirmware 3.01-beta 3 released:

    @dc42 Apparently you and @chrishamm aren't on speaking terms because the DSF doesn't get the current axis coordinates with the latest 3.01betas.

    Which DSF version are you using?

    1.2.4.0 which is also the last commit pushed to github

    Does M408 S2 report the correct coordinates?

    It depends...
    The toolhead is in the printable area (not at an endstop or home)

    "xyz":[-130.000,-125.000,0.000],"machine":[0.000,0.000,0.000],
    

    xys is correct but the machine coordinates are always 0.

    From the DSF...
    move.axes.drives[0].machinePosition always shows 0.000 but...
    move.drives[0].position is correct at -130.
    I have no idea what the difference between move.axes.drives and move.drives is.


  • administrators

    Thanks, it looks like machinePosition is not being updated. I will investigate it.


  • administrators

    @dc42 said in RepRapFirmware 3.01-beta 3 released:

    @Ntrack said in RepRapFirmware 3.01-beta 3 released:

    Just reinstalled the latest firmware for duet wifi .Firmware: RepRapFirmware for Duet 2 WiFi/Ethernet 3.01-beta3+1 (2020-01-30b1) . The issue is still present .

    Thanks, I will look into it.

    I'm sorry, I can't reproduce that. I don't have an MMU, so I had to modify your file to try to cover all possibilities. Can you produce the same error using a similar file that doesn't refer to any object model variables?

    PS - please also check whether the same issue occurs on the 3.01-beta3+1 (2020-01-31b2) build, now in the same location.


Log in to reply