New firmware 2.01 beta 2 available


  • administrators

    I've just released this at https://github.com/dc42/RepRapFirmware/releases/tag/2.01beta2. Changes since 2.01beta1 are:

    Bug fixes:

    • Non-movement commands were not correctly synchronised with movement commands when there were more than 8 non-movement commands interspersed with more than 2 seconds of movement
    • If M28/M29 was used in a macro file to then the commands between M28 and M29 were executed as well as being written to the target file
    • If you used the jog buttons in DWC before homing the axes, and you didn't use M564 H0 in config.g, then as well as the "insufficient axes homed" error message, a stack underflow error message was produced
    • Neither M561 nor G29 S2 adjusted the user Z coordinate if bed compensation was previously active (G29 S2 did if you ran it twice)
    • Duet 06/085 only: fixed a buffer overflow in the Netbios responder code
    • Duet 2 series: when an under-voltage event occurred, spurious driver status warnings/errors were sometimes reported
    • Duet 2 series: when an under- or over-voltage event occurred, the VIN voltage reported was the current voltage, not the voltage when the event was recorded
    • When an axis was made visible and later hidden, subsequent move commands sometimes sent step commands incorrectly to the driver(s) associated with that axis. This could cause unwanted movement if the axis was still mapped to a real driver. If it was mapped to a dummy driver, it could still cause step errors to be recorded and/or some movements to be slowed down.
    • The longest loop time reported by M122 was distorted by the fact that M122 itself takes a long time to execute, due to the volume of output it produces and the need to synchronise with the Network task

    New features/changed behaviour:

    • On the Duet 2 Maestro, the 2 optional add-on drivers are now assumed to be TMC2224 with UART interface
    • When the Z probe type is set to 9 for BLTouch, the probe output is no longer filtered, for faster response
    • If an error occurs while reading or writing the SD card, the operation is retried. The M122 report includes the maximum number of retries that were done before a successful outcome.
    • On the Duet WiFi/Ethernet, at startup the firmware does additional retries when checking for the presence of a DueX2 or DueX5 and/or additional I/O expansion board
    • When a resurrect.g file is generated, it now includes G92 commands just before it invokes resurrect-prologue.g, to set the assumed head position to the point at which power was lost or the print was paused. This is to better handle printers for which homing Z is not possible when a print is already on the bed. Caution: this doesn't allow for any Z lift or other movement in the power fail script.
    • RTOS builds only: added a separate software watchdog to monitor the Heat task
    • RTOS builds only: in the M122 report, the software reset data now includes which task was active, and only owned mutexes are listed
    • Upgraded compiler to 2018-q2-update

    If you find any new issues with this release, or any of the bug fixes don't work for you, or if it works beautifully for you, please report that in this thread.


  • Moderator

    Am I correct to assume that the changes made by @chrishamm to include the current and requested speed display as well as heater and fan renaming are not present in this release? They appeared to be there at first, but then after completely reloading the page they are gone.


  • administrators

    Those changes are not in this beta. They will be in the next one.



  • @dc42 said in New firmware 2.01 beta 2 available:

    Non-movement commands were not correctly synchronised with movement commands when there were more than 8 non-movement commands interspersed with more than 2 seconds of movement

    Laser engraving works correctly now, thank you.


  • administrators

    @spw said in New firmware 2.01 beta 2 available:

    @dc42 said in New firmware 2.01 beta 2 available:

    Non-movement commands were not correctly synchronised with movement commands when there were more than 8 non-movement commands interspersed with more than 2 seconds of movement

    Laser engraving works correctly now, thank you.

    Thanks for confirming this.



  • I have done some initial tests air cutting one of the GCode files with problems and they are indeed gone! Some undesired problems are also gone, but they may be related to the movement/non-movement sync fix. Now going to check the maximum jerk - I suspect I might be able to bring it back to default 900 value!

    P.S. Did those jerk tests. While there are no error messages, going back to the original 900mm/min brings some genuine mechanical noises when reversing the direction. In the end it is an actual limit of the machine.


  • administrators

    @catalin_ro, thanks for confirming the fix.



  • @dc42 said in New firmware 2.01 beta 2 available:

    • On the Duet 2 Maestro, the 2 optional add-on drivers are now assumed to be TMC2224 with UART interface

    Amazing! I will have some time on the weekend to properly test this! Along with the 7th Driver pin reversal. I will report back as soon as I can.



  • Tested on my railcore 2 (with a bltouch), a few test prints through, and everything's working as expected.



  • @dc42 said in New firmware 2.01 beta 2 available:

    • If M28/M29 was used in a macro file to then the commands between M28 and M29 were executed as well as being written to the target file

    The part with executing as well as writing seems to be fixed but still not working as expected. M29 does not seem to be recognized inside a macro. Or not executed.

    I have the following filament load macro:

    M28 /sys/current_material.g
    M98 P/macros/Settings/PETG/DevilDesign
    M29
    
    • ✔ It will now successfully create the file /sys/current_material.g reliably
    • ✔ It will not exectute /macros/Settings/PETG/DevilDesign (this file exists)
    • ⛔ It will not close the file at the end of the macro but continue to write all following commands into this file until I explicitely call M29 via GCode console - strangely enough the M29 from the macro will also not end up in the written file

    So, if I execute the above macro by loading the filament this is assigned to and afterwards enter the following commands manually in GCode Console

    1. M82
    2. M84
    3. M29

    I end up with the following contents in /sys/current_material.g

    M98 P/macros/Settings/PETG/DevilDesign
    M82
    M84
    

    If I enter M29 immediately after loading the filament it will only be the first line.

    EDIT: On GCode console I get the following output (note: descending time stamp)

    16:27:04    M29
                Done saving file.
    16:26:54    M702
                M701 S"PETG_DevilDesign"
                Writing to file: /sys/current_material.g
                GCode end-of-file being interpreted.
    


  • Would it be possible to get a mirror for the files? github seems to have problems.



  • @dc42 laser engraving working great here too. With the G1 S for lasers you said would be in 2.02 (I think) things should be perfect!



  • @obeliks nevermind, it's back


  • administrators

    @wilriker said in New firmware 2.01 beta 2 available:

    @dc42 said in New firmware 2.01 beta 2 available:

    • If M28/M29 was used in a macro file to then the commands between M28 and M29 were executed as well as being written to the target file

    The part with executing as well as writing seems to be fixed but still not working as expected. M29 does not seem to be recognized inside a macro. Or not executed.

    I have the following filament load macro:

    M28 /sys/current_material.g
    M98 P/macros/Settings/PETG/DevilDesign
    M29
    
    • ✔ It will now successfully create the file /sys/current_material.g reliably
    • ✔ It will not exectute /macros/Settings/PETG/DevilDesign (this file exists)
    • ⛔ It will not close the file at the end of the macro but continue to write all following commands into this file until I explicitely call M29 via GCode console - strangely enough the M29 from the macro will also not end up in the written file

    So, if I execute the above macro by loading the filament this is assigned to and afterwards enter the following commands manually in GCode Console

    1. M82
    2. M84
    3. M29

    I end up with the following contents in /sys/current_material.g

    M98 P/macros/Settings/PETG/DevilDesign
    M82
    M84
    

    If I enter M29 immediately after loading the filament it will only be the first line.

    EDIT: On GCode console I get the following output (note: descending time stamp)

    16:27:04    M29
                Done saving file.
    16:26:54    M702
                M701 S"PETG_DevilDesign"
                Writing to file: /sys/current_material.g
                GCode end-of-file being interpreted.
    

    Strange, I tested it several times and it worked for me. Please try adding a comment line in your macro file after the M29 command, in case the M29 at the end of the file isn't being interpreted correctly..



  • @dc42 said in New firmware 2.01 beta 2 available:

    Strange, I tested it several times and it worked for me. Please try adding a comment line in your macro file after the M29 command, in case the M29 at the end of the file isn't being interpreted correctly..

    Adding an additional line with just a comment at the end makes it work. Adding an inline comment on the M29 line does not change the faulty behavior.

    Now, why would the last line not be interpreted correctly? These seems only to apply to M29. I just tested with a M117 as the last line (right after M29) and the text was displayed.



  • Using this version on 4 different printers with no noticable differences between beta 1 and 2. BLtouch has been working much better over these past two versions. Thanks for taking the time to make them work perfectly (ie no-bounce, fast response).


  • administrators

    @wilriker said in New firmware 2.01 beta 2 available:

    @dc42 said in New firmware 2.01 beta 2 available:

    Strange, I tested it several times and it worked for me. Please try adding a comment line in your macro file after the M29 command, in case the M29 at the end of the file isn't being interpreted correctly..

    Adding an additional line with just a comment at the end makes it work. Adding an inline comment on the M29 line does not change the faulty behavior.

    Now, why would the last line not be interpreted correctly? These seems only to apply to M29. I just tested with a M117 as the last line (right after M29) and the text was displayed.

    Before you added the comment, did you have a newline at the end of the M29, or not?


  • administrators

    @bpislife said in New firmware 2.01 beta 2 available:

    Using this version on 4 different printers with no noticable differences between beta 1 and 2. BLtouch has been working much better over these past two versions. Thanks for taking the time to make them work perfectly (ie no-bounce, fast response).

    Thanks for the feedback!



  • @dc42 said in New firmware 2.01 beta 2 available:

    Before you added the comment, did you have a newline at the end of the M29, or not?

    I did not. Is that an implicit requirement?

    EDIT: Empty newline at the end also works.


  • administrators

    @wilriker said in New firmware 2.01 beta 2 available:

    @dc42 said in New firmware 2.01 beta 2 available:

    Before you added the comment, did you have a newline at the end of the M29, or not?

    I did not. Is that an implicit requirement?

    EDIT: Empty newline at the end also works.

    Thanks for confirming that. The firmware appends a newline to the end of the last command if there isn't one, but I guess it's doing it a little too late in the case of having to recognise M29. I'll fix it in the next beta or RC if the fix isn't complicated.



  • @incogizmo said in New firmware 2.01 beta 2 available:

    @dc42 said in New firmware 2.01 beta 2 available:

    • On the Duet 2 Maestro, the 2 optional add-on drivers are now assumed to be TMC2224 with UART interface

    Amazing! I will have some time on the weekend to properly test this! Along with the 7th Driver pin reversal. I will report back as soon as I can.

    @dc42 got to testing it all sooner than expected. Can confirm microstepping is now applying on both addon drivers and driver 6 (7th driver) is also working as expected.

    Are there any commands or anything else I can do to help you confirm all is working as expected?


  • administrators

    @incogizmo said in New firmware 2.01 beta 2 available:

    @incogizmo said in New firmware 2.01 beta 2 available:

    @dc42 said in New firmware 2.01 beta 2 available:

    • On the Duet 2 Maestro, the 2 optional add-on drivers are now assumed to be TMC2224 with UART interface

    Amazing! I will have some time on the weekend to properly test this! Along with the 7th Driver pin reversal. I will report back as soon as I can.

    @dc42 got to testing it all sooner than expected. Can confirm microstepping is now applying on both addon drivers and driver 6 (7th driver) is also working as expected.

    Are there any commands or anything else I can do to help you confirm all is working as expected?

    Thanks for confirming this. I can't think of any other tests needed on the expansion board at present.


  • Moderator

    I just had a print stop on me. I think it happened when I tried to connect to the DWC from my iphone to check on the print. I had just looked at the camera and things we're going smoothly. I loaded the DWC and it wouldn't finish loading on the iphone. I went to check the printer and it was stopped sitting above the print. Heaters off and cooling down.

    M122

    M122
    === Diagnostics ===
    RepRapFirmware for Duet 2 WiFi/Ethernet version 2.01beta2(RTOS) running on Duet WiFi 1.02 or later
    Board ID: 08DDM-9FAM2-LW4SD-6JKF0-3SN6N-T2ZBY
    Used output buffers: 3 of 20 (10 max)
    === RTOS ===
    Static ram: 28484
    Dynamic ram: 96160 of which 0 recycled
    Exception stack ram used: 328
    Never used ram: 6100
    Tasks: NETWORK(ready,328) HEAT(blocked,1192) MAIN(running,3616)
    Owned mutexes:
    === Platform ===
    Last reset 00:16:07 ago, cause: software
    Last software reset at 2018-07-20 22:02, reason: Stuck in spin loop, spinning module PrintMonitor, available RAM 5724 bytes (slot 1)
    Software reset code 0x4049 HFSR 0x00000000 CFSR 0x00000000 ICSR 0x0041f80f BFAR 0xe000ed38 SP 0x2001ffd0 Task 0x4e49414d
    Stack: 00000008 0044509b 00008096 ffffffed 00000000 00f00000 e000ef34 c0000000 20006c94 00445195 00444f0c 61000000 ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff
    Error status: 0
    Free file entries: 10
    SD card 0 detected, interface speed: 20.0MBytes/sec
    SD card longest block write time: 0.0ms, max retries 0
    MCU temperature: min 36.6, current 38.8, max 40.1
    Supply voltage: min 23.8, current 24.0, max 24.2, under voltage events: 0, over voltage events: 0
    Driver 0: standstill, SG min/max not available
    Driver 1: standstill, SG min/max not available
    Driver 2: standstill, SG min/max not available
    Driver 3: standstill, SG min/max not available
    Driver 4: standstill, SG min/max not available
    Date/time: 2018-07-20 22:19:11
    Slowest loop: 9.67ms; fastest: 0.08ms
    === Move ===
    Hiccups: 0, StepErrors: 0, LaErrors: 0, FreeDm: 240, MinFreeDm: 240, MaxWait: 0ms, Underruns: 0, 0
    Scheduled moves: 0, completed moves: 0
    Bed compensation in use: mesh
    Bed probe heights: 0.000 0.000 0.000 0.000 0.000
    === Heat ===
    Bed heaters = 0 -1 -1 -1, chamberHeaters = -1 -1
    Heater 1 is on, I-accum = 0.0
    === GCodes ===
    Segments left: 0
    Stack records: 2 allocated, 0 in use
    Movement lock held by null
    http is idle in state(s) 0
    telnet is idle in state(s) 0
    file is idle in state(s) 0
    serial is idle in state(s) 0
    aux is idle in state(s) 0
    daemon is idle in state(s) 0
    queue is idle in state(s) 0
    autopause is idle in state(s) 0
    Code queue is empty.
    === Network ===
    Slowest loop: 71.55ms; fastest: 0.01ms
    Responder states: HTTP(0) HTTP(0) HTTP(0) HTTP(0) FTP(0) Telnet(0) Telnet(0)
    HTTP sessions: 1 of 8
    - WiFi -
    Network state is running
    WiFi module is connected to access point 
    Failed messages: pending 0, notready 0, noresp 0
    WiFi firmware version 1.21
    WiFi MAC address 5c:cf:7f:ef:4a:74
    WiFi Vcc 3.31, reset reason Turned on by main processor
    WiFi flash size 4194304, free heap 14808
    WiFi IP address 10.10.0.63
    WiFi signal strength -36dBm, reconnections 0, sleep mode modem
    Socket states: 0 0 0 0 0 0 0 0
    === Expansion ===
    

    In the console of the PanelDue I also see an error from 3 hours earlier saying Wifi reported error: incomplete write. But nothing else. I'm not sure what that would have been from.



  • I'm running an earlier version of post 2.0 beta firmware (will confirm on Monday) on a Duet Ethernet/Deux5/CoreXY with three steppers for the z-axis.

    I run a bed level compensation that probes three points in the bed.g file and adjusts the screws to level the bed.

    I've a limit switch on max y (homing works fine) but found that if the coordinate in the bed.g is beyond that limit switch the system will drive the axis into the switch and then some while the stepper misses steps.


  • administrators

    @phaedrux said in New firmware 2.01 beta 2 available:

    I just had a print stop on me. I think it happened when I tried to connect to the DWC from my iphone to check on the print. I had just looked at the camera and things we're going smoothly. I loaded the DWC and it wouldn't finish loading on the iphone. I went to check the printer and it was stopped sitting above the print. Heaters off and cooling down.

    Thanks for your report. Unfortunately the stack trace doesn't provide any useful data in this case. I will change it in the next beta.


Log in to reply