Firmware 2.03 (Duet 2) and 1.24 (Duet 06/085) released


  • administrators

    I have just released these at https://github.com/dc42/RepRapFirmware/releases/tag/2.03. Compared to firmware version 2.02, this release includes around 80 new or improved features and around 50 bug fixes. The full list and upgrade notes are at https://github.com/dc42/RepRapFirmware/blob/dev/WHATS_NEW.md.

    I slipped in a late new feature: a "jerk policy" which is set by the M566 P parameter. The default value is 0 which replicates the previous behaviour. Setting it to 1 or anything higher allows jerk to be applied in circumstances in which it is not strictly needed, for example when transitioning between travel moves and printing moves. This mimics the way in which some other firmwares behave. Please note, it may not work well when used in conjunction with high values of pressure advance.



  • So reading through the Whats new file, I saw the comment about offsets being in the tool files for IDEX printers. Any clarification on what this means for existing configs?

    "Tool changers, IDEX printers and similar using tpre#.g and tpost#.g files: tool offsets are now applied within the tpre#.g and tpost#.g macros."

    My tool definitions in config.g are this: (Having issues with the duplication one as I mentioned in another post but that's besides the point)
    *; Tool 0 X - Left hand Extruder
    M563 P0 D0 H1 F0 X0 S"Left Titan Aero" ; tool 0 uses extruder 0 and heater 1 and maps X to X, use fan 2 as the print cooling fan
    G10 P0 X0 Y0 Z0 ; Set tool 0 axis offsets
    ;G10 P0 R0 S0 ; Set initial tool 0 active and standby temperatures to 0C

    ;Tool 1 U - Right hand Extruder
    M563 P1 D1 H2 X3 F1 S"Right Titan Aero" ; tool 1 uses extruder 1 and heater 2 and maps X to U, use fan 1 as the print cooling fan
    G10 P1 X0 Y-2.95 Z0 ; Set initial tool 1 active and standby temperatures to 0C (was -.71 before adjusted the Left X axis down)
    ;G10 P1 R0 S0 ; Set initial tool 0 active and standby temperatures to 0C

    ; Duplication Tool 2
    M563 P2 D0:1 H1:2 X0:3 F0:1 S"Dual Duplication Print" ; tool 2 uses both extruders and hot end heaters, maps X to both X and U, and uses both print cooling fans
    G10 P2 X150 Y0 U-150 S0 R0 ; set tool offsets and temperatures for tool 2
    M567 P2 E1:1 ; set mix ratio 100% on both extruders*

    Does this mean I need to move the G10 lines to the Pre/post macros? Just curious what the actual guidance is based on that mention in the documentation.



  • the configurator needs to be updates with a choice for this firmware because of the M669.


  • administrators

    @veti said in Firmware 2.03 (Duet 2) and 1.24 (Duet 06/085) released:

    the configurator needs to be updates with a choice for this firmware because of the M669.

    Not necessary, because the M669 K codes that RRF 2.02 supports are also supported in RRF 2.03 and they set the appropriate default matrix.



  • Thanks! Time to update my boards!

    I'm not sure what qualifies as "high levels" for pressure advance, but most likely I'm going to leave the jerk settings to default anyway, so it probably won't matter.



  • Thanks for the continuing updates to the 1.x firmware. Will update later this evening.


  • Moderator

    Tested it out last night on a 6 hour print. I even tried the Jerk policy of 1 to see if I could tell the difference. I wasn't sure what to look out for, but the print completed successfully at any rate. XY jerk of 700, PA of 0.045.



  • Since updating to 2.03, I think, that there is a new issue.

    Within long prints, the display and the web interface twice got unresponsive about in the middle of a print (after around 5h).
    But the print was finished correctly. After finishing, the duet display (7´) and the web interface still show the bed and hotend temperature that where used during the print.

    The "STOP" button on the display reacts, but failed to connect to the duet board again.

    Power on/off fixes the problem.

    In the 2.03 RC the fault did not appear.



  • @alpenprinter said in Firmware 2.03 (Duet 2) and 1.24 (Duet 06/085) released:

    Within long prints, the display and the web interface twice got unresponsive about in the middle of a print (after around 5h).
    But the print was finished correctly. After finishing, the duet display (7´) and the web interface still show the bed and hotend temperature that where used during the print.

    I also observed that!
    At first I thought only of wireless problems but also the PanelDue did not react anymore.
    I also had this in 2.03 RC, Final 2.03 I have just installed today.



  • What's the latest firmware version known to run stable?

    @zerspaner_gerd said in Firmware 2.03 (Duet 2) and 1.24 (Duet 06/085) released:

    @alpenprinter said in Firmware 2.03 (Duet 2) and 1.24 (Duet 06/085) released:

    Within long prints, the display and the web interface twice got unresponsive about in the middle of a print (after around 5h).
    But the print was finished correctly. After finishing, the duet display (7´) and the web interface still show the bed and hotend temperature that where used during the print.

    I also observed that!
    At first I thought only of wireless problems but also the PanelDue did not react anymore.
    I also had this in 2.03 RC, Final 2.03 I have just installed today.


  • Moderator

    @alpenprinter said in Firmware 2.03 (Duet 2) and 1.24 (Duet 06/085) released:

    What's the latest firmware version known to run stable?

    2.02 was the last stable release.

    What version of DWC and PanelDue firmware are you running?



  • @phaedrux said in Firmware 2.03 (Duet 2) and 1.24 (Duet 06/085) released:

    @alpenprinter said in Firmware 2.03 (Duet 2) and 1.24 (Duet 06/085) released:

    What's the latest firmware version known to run stable?

    2.02 was the last stable release.

    What version of DWC and PanelDue firmware are you running?

    Panel Due 1.20
    DWC 2.0.0



  • @phaedrux said in Firmware 2.03 (Duet 2) and 1.24 (Duet 06/085) released:

    @alpenprinter said in Firmware 2.03 (Duet 2) and 1.24 (Duet 06/085) released:

    What's the latest firmware version known to run stable?

    2.02 was the last stable release.

    What version of DWC and PanelDue firmware are you running?

    I downgraded to 2.02 and all is running fine again. I kept DWC 2.0.0, no problem with this.



  • Not sure if this is a bug or a feature/limitation, but if using M918 P1 E4 to enable a 12864 display the PanelDue serial port does not get the {"beep_freq":7000,"beep_length":2000} message even if the serial port is set up with M575 P1 B57600 S0. Which seems odd as {"message":"HELLO WORLD"} from M117 Hello World is sent to the PanelDue port even with the 12864 display enabled, removing the 12864 from the config results in the beep messages being sent to the PanelDue port without any other changes made.

    (Also M918 P0 is rejected as unkown display, so only way is to reboot. Same behavior in v3 in both cases)


  • administrators

    @bearer said in Firmware 2.03 (Duet 2) and 1.24 (Duet 06/085) released:

    Not sure if this is a bug or a feature/limitation, but if using M918 P1 E4 to enable a 12864 display the PanelDue serial port does not get the {"beep_freq":7000,"beep_length":2000} message even if the serial port is set up with M575 P1 B57600 S0. Which seems odd as {"message":"HELLO WORLD"} from M117 Hello World is sent to the PanelDue port even with the 12864 display enabled, removing the 12864 from the config results in the beep messages being sent to the PanelDue port without any other changes made.

    That's the way it is written. But I can make both the 12864 and PanelDue bleep in the next build.

    (Also M918 P0 is rejected as unkown display, so only way is to reboot. Same behavior in v3 in both cases)

    I didn't anticipate any requirement to disable the 12864 display once it has been enabled.



  • @dc42 said in Firmware 2.03 (Duet 2) and 1.24 (Duet 06/085) released:

    I didn't anticipate any requirement to disable the 12864 display once it has been enabled.

    I just tried as the g-code wiki listed Pn Directly-connected display type: P0 = none (default) which the firmware rejected, I don't see the need to un-configure it, but maybe the wiki was a bit unclear in that respect.

    As for the beep with and without 12864, I'm okay either way, was just surprised that there was a difference between M117 and M300 without any indication of it being by design or not. If supporting efforts like https://forum.duet3d.com/topic/10720/duet3d-monitor-adding-a-big-status-light-to-your-printer is a priority I can see having the protocol as complete as possible even if not used with a PanelDue would be beneficial.


  • administrators

    @bearer said in Firmware 2.03 (Duet 2) and 1.24 (Duet 06/085) released:

    I just tried as the g-code wiki listed Pn Directly-connected display type: P0 = none (default) which the firmware rejected, I don't see the need to un-configure it, but maybe the wiki was a bit unclear in that respect.

    I have removed the P0 option from the description in the GCode wiki.

    As for the beep with and without 12864, I'm okay either way, was just surprised that there was a difference between M117 and M300 without any indication of it being by design or not. If supporting efforts like https://forum.duet3d.com/topic/10720/duet3d-monitor-adding-a-big-status-light-to-your-printer is a priority I can see having the protocol as complete as possible even if not used with a PanelDue would be beneficial.

    That's why I changed the code yesterday to send the beep to both displays. This change is already in the RRF3 beta build and it will also be in RRF 2.03.1 when I release that.



  • ☝ Awesome!



  • Another "maybe" bug.
    I have duet 3d wifi on a delta printer, with the new function "M665 L260.0:260.0:260.0" to give the firmware the diagonal rod offsets, if I leave them the same as in the example everything works fine, now, if I change the values after calibrating with the hexagon I get (and thats what I got when I was running Marlin) L267.3:267.1:266.9, a 0.2mm difference between the rod pairs, my printer misses steps while homing (the second bump, but not in the first one) and misses steps while calibrating and printing.
    I, then, proceed to experiment, the greater the difference, the more steps it misses.
    So I'm now back to the L267.1 (the mean of the tree pairs) until this is fixed, it happens too to others in my printing community.

    Here I provide you my homedelta, config override and config in case you want to check them out.

    2_1561532460509_homedelta.g 1_1561532460509_config-override.g 0_1561532460509_config.g


  • administrators

    Thanks for your report - I've added it to my list to investigate.

    The recommended way to handle scaling errors is not to adjust the rod lengths but to use M579.



  • Two things I've seen so far.

    M280 to turn a servo in a macro sometimes doesn't run until the end of the macro, after any other moves etc. Putting M400's before/after fixes it. (It's not every macro that's affected, some run as expected, others don't turn the servo until the end, no rhyme or reason I can spot)

    M116 behavior changed slightly, still looking at this. Probably only affects testing, but I'm not sure. Previously if no temp was set I could switch through tools and the M116 did nothing. Now it stalls and waits on something. I tried setting the temp to 30c on each tool. It does bring the temp up to 30c but never proceeds. I may need to set a standby temp for each tool and retest, still looking into it. Commenting out the M116 lets the swaps proceed as normal.

    One other thing that may be as intended, but surprised me. I thought having a minima for Z set to -0.1 wouldn't affect anything other than letting me move down "into the bed" past Z=0. I homed X/Y/Z, then did a mesh probe and the mesh showed entirely "under the bed". Changing the minima to Z0 resolved that. It's likely I just misunderstood this functionality, but figured I'd note it. (the documentation seems to indicate this is expected behavior)


  • administrators

    @kraegar said in Firmware 2.03 (Duet 2) and 1.24 (Duet 06/085) released:

    M280 to turn a servo in a macro sometimes doesn't run until the end of the macro, after any other moves etc. Putting M400's before/after fixes it. (It's not every macro that's affected, some run as expected, others don't turn the servo until the end, no rhyme or reason I can spot)

    Can you construct a macro that reproduces this reliably?

    M116 behavior changed slightly, still looking at this. Probably only affects testing, but I'm not sure. Previously if no temp was set I could switch through tools and the M116 did nothing. Now it stalls and waits on something.

    There has been no intentional change to M116. Can you reproduce it, preferably in a standalone macro?

    One other thing that may be as intended, but surprised me. I thought having a minima for Z set to -0.1 wouldn't affect anything other than letting me move down "into the bed" past Z=0. I homed X/Y/Z, then did a mesh probe and the mesh showed entirely "under the bed". Changing the minima to Z0 resolved that. It's likely I just misunderstood this functionality, but figured I'd note it. (the documentation seems to indicate this is expected behavior)

    No, it's not intentional behaviour. The only way that the M208 Zmin setting should affect the Z=0 position is if you use a Zmin homing switch, and after the G1 H1 Z-nnn move in homez.g you don't have a G92 Z command to set the actual Z position.



  • The method for my testing is simply a macro that loops through tool changes, "Test Tools Pickup".

    So it loops through each tool in order. I'm not going to cover them all, but here's the summary so far:

    The first issue hit is with M280 in tfree0.g (tpost0.g completes with no issue with either M116 or M280, weirdly). If I wrap M400's around the M280, tfree0.g completes fine.
    The next issue happens during tpost1.g where it stalls out on the M116 line. I tried setting all of the active & standby temps to 30c before testing, and it still hangs on the M116 on tool 1.

    The macros in question are here (quickly cleaned up for readability):
    https://www.dropbox.com/sh/oo610lsff1g3n85/AAA6O112JlaB--WkmdfMJla8a?dl=0

    Here are screenshots of the difference between M208 Z-0.2 vs. M208 Z0 for Zmin. No other changes. Steps to reproduce:
    Home X/Y, Home Z using a microswitch on the X carriage. Run G29.

    Z-0.1:
    https://i.imgur.com/R7qS1ro.png

    Z0:
    https://i.imgur.com/eWa53j6.png



  • This post is deleted!


  • Another one. Not sure if it's any gcode, or just this file. 4 tool print. First 3 go fine. 4th tool it picks up, runs the cleaning routing, then goes to print, and the Z height drops to -3.30mm.

    Here's the section of gcode:

    G1 E24.67887 F2400.00000
    G92 E0
    G1 Z0.600 F7800.000
    G91
    G1 Z5 E-2 F1800
    G90
    T3
    G92 E0
    G1 E-2.00000 F2400.00000
    G92 E0
    G1 X150.900 Y99.100 F7800.000
    G1 Z0.350
    G1 E2.00000 F2400.00000
    G1 F1800
    G1 X150.900 Y85.900 E2.66248

    Since it's setting the working height to 0.350 in the gcode, I can't for the life of me figure why it's diving to -3.30mm. If it were an offset issue, it would display it was at the correct Z of 0.350

    Dropping to 2.02 resolved this issue. (Though in 2.02 it's not running T0 to grab that tool at the start of my print, need to figure that out next I guess since I know others are on 2.02)

    I can post my offset files and tool change scripts if that helps.


Log in to reply