New firmware 3.01-RC2 available


  • administrators

    I've released RepRapFirmware 3.01-RC2 at https://github.com/dc42/RepRapFirmware/releases/tag/3.01-RC2 and compatible expansion board and tool board firmware at https://github.com/dc42/Duet3Expansion/releases/tag/3.01-RC2. For the upgrade notes and changes, see https://github.com/dc42/RepRapFirmware/blob/v3-dev/WHATS_NEW_RRF3.md.

    This release includes rather more changes than I would normally make in a Release Candidate. However, it became apparent that major changes were needed in the way that pins are configured for use as general purpose inputs, and some of the parameters to M143 needed to be changed. For the benefit of users switching to RRF3, I am trying to avoid the need to make any major changes like these after the 3.01 stable release.



  • @dc42 @droftarts Just looking at the gcode reference for M581 for RC3.01 and later and it shows this format in the example M581 P0:3" S1 T2 C1. i.e. there is a single double quote which looks like it either ought not to be there, or it needs a partner?


  • administrators

    That was a misprint, and I've just corrected it.



  • updated the firmware, no problems. one print completed.
    thanks @dc42



  • fyi: M308 S1 P"temp1" Y"thermistor" B4725 C7.06e-8 seems to be working in rc2



  • Updated on a CoreXY and no problems. Test cube looks great.



  • so far so good 😄



  • @dc42 fan rpm showing up in dwc. Thank you very much.



  • I haven't seen anything in the release notes so I guess the answer is still no, but is M303 heater tuning for remote heaters implemented yet?


  • administrators

    @deckingman said in New firmware 3.01-RC2 available:

    I haven't seen anything in the release notes so I guess the answer is still no, but is M303 heater tuning for remote heaters implemented yet?

    Not yet, however I now have an implementation plan for it.



  • might found a bug:

    all files uploaded since RC2 have N/A for "last modified" time/date

    fca396cb-8d0c-4ac4-9142-632628ad8223-image.png

    M905 show proper date/time on the board
    60a6dad4-5430-4810-8b30-3659d7cde383-image.png



  • The console is showing Stack Overflow errors when trying to deploy the BLTouch from a macro that that was started from a Trigger and calls another macro. The probe then fails to deploy.

    Process:
    A state change occurs on "e1stop" and trigger7.g is run. It calls "UnloadFilament.g" which then runs "CheckifHomed.g". During the homing operation the BL Touch probe fails to deploy and the bed crashes. The console shows 2 Stack Overflow errors when the probe attempts to deploy.

    CheckifHomed.g - Runs fine when run on it's own
    CheckifHomed.g - Runs fine when called from "UnloadFilament.g" if UnloadFilament was started from the macro menu
    CheckifHomed.g - Runs fine when called from startcode.g
    CheckifHomed.g - Runs fine when called directly from trigger7.g

    If trigger7.g is moved to the Macro Folder and started manually everything works fine.

    config.g Info

    M950 J3 C"e1stop"		;Load Buton
    M581 T7 P3  	;Runs trigger7.g file when pressed - First step of Unload process
    

    457137b9-1a4c-4ddd-8c70-367685e5471f-image.png

    Please let me know if you need any more information.


  • administrators

    @arhi said in New firmware 3.01-RC2 available:

    might found a bug:

    all files uploaded since RC2 have N/A for "last modified" time/date

    Strange, it's working for me, I just tested uploading to Duet WiFi and to Duet 3 in standalone mode. Are you using DWC 2.0.7? Which Duet?


  • administrators

    @TurtlePrint said in New firmware 3.01-RC2 available:

    A state change occurs on "e1stop" and trigger7.g is run. It calls "UnloadFilament.g" which then runs "CheckifHomed.g". During the homing operation the BL Touch probe fails to deploy and the bed crashes. The console shows 2 Stack Overflow errors when the probe attempts to deploy.

    Looks like you are exceeding the maximum allowed stack depth. Every macro file called (including homing macros and the Z probe deploy/retract macro) uses one level. I can increase it in the next RC.



  • @dc42 said in New firmware 3.01-RC2 available:

    @arhi said in New firmware 3.01-RC2 available:

    might found a bug:

    all files uploaded since RC2 have N/A for "last modified" time/date

    Strange, it's working for me, I just tested uploading to Duet WiFi and to Duet 3 in standalone mode. Are you using DWC 2.0.7? Which Duet?

    Board: Duet Ethernet 1.02 or later
    Firmware: RepRapFirmware for Duet 2 WiFi/Ethernet 3.01-RC2 (2020-02-18b1) 
    Duet Web Control 2.0.7
    

    but looks like when I upload from DWC (upload gcode file button) it works ok but when I curl it to the duet

    @echo off
    
    for %%a in (%1) do (
        set filepath=%%~dpa
        set filename=%%~na
        set extension=%%~xa
    )   
    set if=%filepath%%filename%%extension%
    
    G:\bin\curl-7.50.3-win64-mingw\bin\curl.exe -G --data-urlencode gcode=M30"%filename%%extension%" http://ender5.local.lan/rr_gcode
    G:\bin\curl-7.50.3-win64-mingw\bin\curl.exe  --data-binary "@%if%" "http://ender5.local.lan/rr_upload?name=gcodes/%filename%%extension%"
    
    

    the datetime is not there


  • administrators

    There is an additional parameter to the rr_upload command that specifies the date/time to use for the time stamp.

    What was the latest version of RRF for which the time stamp was set when you uploaded files using curl?

    EDIT: I just ran the following:

    curl.exe --data-binary "@symarchive.bat" "http://192.168.1.126/rr_upload?name=gcodes/symarchive.bat"
    

    and it did set the time stamp on the uploaded file.

    Note, you need to have connected to the Duet with DWC before you do the upload using curl, otherwise the date/time will not be set on the Duet. Or you can pass the time stamp as an extra parameter, like this:

    C:\Eclipse\Firmware>curl.exe --data-binary "@symarchive.bat" "http://192.168.1.126/rr_upload?name=gcodes/symarchive.bat&time=2013-04-05T11:12:13"
    


  • @dc42 Is it possible to have the Duet "Emergency Stop" when a Stack overflow occurs?


  • administrators

    @TurtlePrint said in New firmware 3.01-RC2 available:

    @dc42 Is it possible to have the Duet "Emergency Stop" when a Stack overflow occurs?

    I can quite easily make it abandon the current print job.



  • @dc42 said in New firmware 3.01-RC2 available:

    There is an additional parameter to the rr_upload command that specifies the date/time to use for the time stamp.

    ah, didn't know that

    What was the latest version of RRF for which the time stamp was set when you uploaded files using curl?

    The update to the RRF and script for s3d came roughly at the same time so I started using CURL when I updated to RC2

    Note, you need to have connected to the Duet with DWC before you do

    That's the missing link! Thanks, that solved the problem 😄
    Apologies for the false alarm.

    Will modify the script to send proper time value, thanks for example.

    Is there a way to tell DWC to refresh file list using curl?


  • administrators

    @arhi said in New firmware 3.01-RC2 available:

    Is there a way to tell DWC to refresh file list using curl?

    Not AFAIK, but @chrishamm might know otherwise.



  • Hey - will state.previoustool be persistent through power cycle/M999?
    It would be nice if there could be a condition check on homing to make sure that the previous tool is re-docked before attempting a home, to prevent damage to tool (especially from inattentive tinkerers)


  • administrators

    @Luke-sLaboratory said in New firmware 3.01-RC2 available:

    Hey - will state.previoustool be persistent through power cycle/M999?
    It would be nice if there could be a condition check on homing to make sure that the previous tool is re-docked before attempting a home, to prevent damage to tool (especially from inattentive tinkerers)

    The only things that persist across a restart are data stored in config-override.g when you run M500, and the software reset data.

    For tool changers I suggest using microswitches to detect when tools are docked, or a microswitch to detect when a tool is loaded.



  • @dc42 Talking about tool changes... is it possible also to have a nexttool object? That would make it possible to already preheat the next tool to be used.


  • administrators

    @TC said in New firmware 3.01-RC2 available:

    @dc42 Talking about tool changes... is it possible also to have a nexttool object? That would make it possible to already preheat the next tool to be used.

    A facility to read the GCode stream ahead so that tools can be preheated and filament mixes changed in advanced is planned for Duet 3. There probably isn't enough RAM to fit it in Duet 2.



  • I have Duet 2 Wifi and i have same problem with fan rpm showing random number's. So i will try this update to see is will be same or it will dissape. Thanks @dc42.


Log in to reply