New firmware 1.21RC5 available


  • administrators

    I have just release what I intend to be the final release candidate for firmware 1.21 at https://github.com/dc42/RepRapFirmware/releases. I plan to release 1.21 on Monday or Tuesday.

    There have been significant changes to the following areas:

    • Step pulse timing for external stepper drivers, including new M569 T options (see the GCodes page on the wiki)
    • CNC workplace coordinates (G53..G59, G10 L2 and G10 L20)

    So I would especially appreciate feedback form you if you are using either external stepper drivers or workplace coordinates.

    See https://github.com/dc42/RepRapFirmware/blob/dev/WHATS_NEW.md for the detailed change list.



  • what is the correct procedure to update the firmware from 1.21RC2 ?
    Can I just follow this steps : https://duet3d.dozuki.com/Wiki/Installing_and_Updating_Firmware ?


  • administrators

    It's slightly more complicated than normal, because the name of the main firmware binary for the Duet WiFi and Duet Ethernet has changed.

    To update a Duet WiFi or Duet Ethernet from RC2 to RC5, rename Duet2CombinedFirmware.bin to either DuetWiFiFirmware.bin or DuetEthernetFirmware.bin according to what your existing firmware and DWC expect. Then upload that file through the Settings->General tab of DWC. It will ask whether you want to install the firmware. Say Yes.

    When it has finished, check that the new version number is shown on the Settings->General page of DWC. Then, if your board is a Duet WiFi, upload the new DuetWiFiServer.bin file and allow it to install that.

    Finally, upload the new DuetWebControl.zip file.



  • A suggestion for when you actually release 1.21 (assuming the firmware filename changes are staying the same):

    Provide a DuetWifiFirmware.bin and DuetEthernetFirmware.bin (that are just exact copies of to Duet2CombinedFirmware.bin.) This way, anyone upgrading from the previously released firmware (1.20) won't need to be concerned about the firmware filename changes.

    Then when moving past 1.21, just inform people that they if they are <= 1.21, they need to install 1.21 before the next version.



  • I'm getting inconsistent homing still…. Homing at the same point as a leveling point.

    This is with mini IR sensor. Using 0.005 tolerance.

    M558 P1 X0 Y0 Z1 F180 H0.5 T18000 A5 S0.005

    from homeall, which is called before bed leveling...

    G1 X198 Y192 F12000
    G30

    The point highlighted here is the homing point



  • I have a question about the M569 T parameters. I have external drivers that I am setting back up after burning out the logic converters my breakout board.

    is the image correct? I assume bb is a minimum step pulse interval?



  • I've upgraded to 1.21 RC5 firmware and 1.21 RC4 webcontrol

    When I press the home all button, i get the following error

    G28
    Error: G0/G1: Insufficient axes homed

    I've never gotten this before and the setup as not changed from v1.20. Any idea what's causing this?



  • @DougJones:

    I've upgraded to 1.21 RC5 firmware and 1.21 RC4 webcontrol

    When I press the home all button, i get the following error

    G28
    Error: G0/G1: Insufficient axes homed

    I've never gotten this before and the setup as not changed from v1.20. Any idea what's causing this?

    Most likely this.

    From the release note for RC 3 we have:
    "New features:

    On Cartesian and CoreXY printers, normal movement commands are no longer permitted until the corresponding axes have been homed"

    Then we have:
    "On Cartesian and CoreXY printers, normal G0 and G1 moves are no longer allowed before the corresponding axes have been homed. In particular, if your homex.g, homey.g and homeall.g files raise Z a little at the start and lower it at the end, you will need to add the S2 parameter to those G1 Z moves. Otherwise the G1 Z move will be refused unless Z has already been homed and the homing macro will be terminated."

    But in the release note for RC4 we have
    "Upgrade notes:

    As for 1.21RC3.

    New features and changed behaviour:

    On CoreXZ machines we no longer require Z to be homed before bed probing with G30"

    So following that trail of breadcrumbs I'd assume that for Cartesian printers, if there is a Z move at the start of homeall, you need to add S2 to that move.

    But we also have:

    "Added M564 H0 command to allow axis movement before homing on Cartesian/CoreXY printers"

    So I'd guess that adding that M564 H0 to your config.g will restore the printer back to it's previous behaviour.



  • Gotcha. It's homing now just fine.

    Did you see my question above with the M569 T parameters and the timing chart?

    I am using M569 P5 S1 R1 T10:10:7:2. But both channels seem to be the same still. This should give the dir signal being on 7 usec before and staying on 2 usec after the step signal turns off.

    And for some reason my images are not showing up correctly.


  • administrators

    @DougJones:

    I have a question about the M569 T parameters. I have external drivers that I am setting back up after burning out the logic converters my breakout board.

    is the image correct? I assume bb is a minimum step pulse interval?

    https://ibb.co/fPj9Pc

    Yes, your image is correct. The values are the minimum intervals that will be used. In practice they will be rounded up a little; you can send e.g. M569 P5 to see how much.



  • Ok. here is the image that I am getting on the scope. yellow is step, blue is direction.

    The direction should lead the step by 7 usec and trail the step by 2 usec. The image indicates that they are the roughly the same.


  • administrators

    I don't think you can be looking at the step and direction signals, because the timings are too close. RRF never changes step and dir at the same time, even if you haven't specified any timing requirements. The yellow trace in particular looks very odd and its amplitude is lower than for the blue trace; so I think the yellow trace is probably crosstalk from the blue one.



  • (continued from the rc4 thread, in case relevant here)

    Ok, so if I downgrade back to 1.2.0 everything works as expected and I can see the Endstops hit = No for all axes
    Then I upgrade to 1.2.1 (rc4 or 5) and all axes show Endstops hit = yes.

    Two wire switches connected to left two pins on duet board (with wifi component bottom left)

    Should this be happening? Have I done something wrong?



  • Sorry to be boring, upgraded rc4 to rc5 combined firmware bin and wifi server, still have the rc4 webserver code on cartesian printer. Still works as expected, just like before the upgrade :-))
    Thank you for the g30 multi-touch change


  • administrators

    @Drammy:

    (continued from the rc4 thread, in case relevant here)

    Ok, so if I downgrade back to 1.2.0 everything works as expected and I can see the Endstops hit = No for all axes
    Then I upgrade to 1.2.1 (rc4 or 5) and all axes show Endstops hit = yes.

    Two wire switches connected to left two pins on duet board (with wifi component bottom left)

    Should this be happening? Have I done something wrong?

    The DWC machine properties page shows the raw endstop input state wirth used wirth firmware 1.21RC5. So "Endstop hit" really means the endstop input is high, otherwise it is low. M119 reports the actual endstop status.

    The incorrect readout by DWC doesn't affect the behaviour.



  • @dc42:

    @Drammy:

    (continued from the rc4 thread, in case relevant here)

    Ok, so if I downgrade back to 1.2.0 everything works as expected and I can see the Endstops hit = No for all axes
    Then I upgrade to 1.2.1 (rc4 or 5) and all axes show Endstops hit = yes.

    Two wire switches connected to left two pins on duet board (with wifi component bottom left)

    Should this be happening? Have I done something wrong?

    The DWC machine properties page shows the raw endstop input state wirth used wirth firmware 1.21RC5. So "Endstop hit" really means the endstop input is high, otherwise it is low. M119 reports the actual endstop status.

    The incorrect readout by DWC doesn't affect the behaviour.

    Thanks for the tip with M119. I've checked that and its working fine.

    I still have the problem though. When I downgrade to 1.2.0 Z homes correctly, when I upgrade to 1.2.1 (rc4 and 5) Z crashes into the bed and ignores the Z switch. Any ideas?

    Sorry, a bit new to all this so rather helpless…


  • administrators

    You posted your config.g file in the RC4 thread, but I haven't seen your homing files yet. Please post them.



  • Here's the homing files. They were on the rc4 thread as well so apologies if I'm double posting

    [[language]]
    ; homex.g
    ; called to home the X axis
    ;
    ; generated by RepRapFirmware Configuration Tool on Wed Mar 07 2018 10:07:16 GMT+0000 (GMT)
    G91               ; relative positioning
    G1 S2 Z5 F6000    ; lift Z relative to current position
    G1 S1 X-205 F6000 ; move quickly to X axis endstop and stop there (first pass)
    G1 X5 F6000       ; go back a few mm
    G1 S1 X-205 F600  ; move slowly to X axis endstop once more (second pass)
    G1 S2 Z-5 F6000   ; lower Z again
    G90               ; absolute positioning
    
    
    [[language]]
    ; homey.g
    ; called to home the Y axis
    ;
    ; generated by RepRapFirmware Configuration Tool on Wed Mar 07 2018 10:07:16 GMT+0000 (GMT)
    G91               ; relative positioning
    G1 S2 Z5 F6000    ; lift Z relative to current position
    G1 S1 Y-205 F6000 ; move quickly to Y axis endstop and stop there (first pass)
    G1 Y5 F6000       ; go back a few mm
    G1 S1 Y-205 F600  ; move slowly to Y axis endstop once more (second pass)
    G1 S2 Z-5 F6000   ; lower Z again
    G90               ; absolute positioning
    
    
    [[language]]
    ; homez.g
    ; called to home the Z axis
    ;
    ; generated by RepRapFirmware Configuration Tool on Wed Mar 07 2018 10:07:16 GMT+0000 (GMT)
    G91               ; relative positioning
    G1 Z5 F6000       ; lift Z relative to current position
    G1 S1 Z-180 F6000 ; move Z down until the switch triggers
    G92 Z0            ; set Z position to trigger height
    
    ; Uncomment the following lines to lift Z after probing
    ;G91              ; relative positioning
    ;G1 Z5 F100       ; lift Z relative to current position
    ;G90              ; absolute positioning
    
    
    [[language]]
    ; homeall.g
    ; called to home all axes
    ;
    ; generated by RepRapFirmware Configuration Tool on Wed Mar 07 2018 10:07:16 GMT+0000 (GMT)
    G91                     ; relative positioning
    G1 S2 Z5 F6000          ; lift Z relative to current position
    G1 S1 X-205 Y-205 F6000 ; move quickly to X and Y axis endstops and stop there (first pass)
    G1 X5 Y5 F6000          ; go back a few mm
    G1 S1 X-205 Y-205 F600  ; move slowly to X and Y axis endstops once more (second pass)
    G1 S2 Z-180 F6000 S1    ; move Z down stopping at the endstop
    G90                     ; absolute positioning
    G92 Z0                  ; set new Z position
    ;G1 Z5 F100             ; uncomment this line to lift the nozzle after homing
    
    

  • administrators

    The only thing I've spotted is that in homez.g, in this line:

    G1 Z5 F6000 ; lift Z relative to current position

    you need to add parameter S2.

    Please run M574 without parameters, to check that the Z endstop configuration is reported correctly.

    I suggest you test Z homing by starting with the nozzle a long way above the bed, telling the machine to home Z, then triggering the Z endstop switch manually. If that doesn't stop the Z movement, that will give you time to turn the power off before the nozzle reaches the bed.



  • Thanks for the tip of moving Z up first and triggering manually!

    So HomeZ now works fine but HomeAll doesn't. I still get the same problem. Is this line correct (from homaall.g)..

    [[language]]
    G1 S2 Z-180 F6000 S1    ; move Z down stopping at the endstop
    
    

Locked
 

Looks like your connection to Duet3D was lost, please wait while we try to reconnect.