• Tags
  • Documentation
  • Order
  • Register
  • Login
Duet3D Logo Duet3D
  • Tags
  • Documentation
  • Order
  • Register
  • Login

[RRF 2.02] M703 blocking or async?

Scheduled Pinned Locked Moved
Firmware installation
2
7
711
Loading More Posts
  • Oldest to Newest
  • Newest to Oldest
  • Most Votes
Reply
  • Reply as topic
Log in to reply
This topic has been deleted. Only users with topic management privileges can see it.
  • undefined
    wilriker
    last edited by wilriker 15 Jan 2019, 13:25

    Duet Web Control 2.0.0-RC3
    Electronics: Duet WiFi 1.02 or later
    Firmware: RepRapFirmware for Duet 2 WiFi/Ethernet 2.02(RTOS) (2018-12-24b1)
    Duet WiFi Server Version: 1.22

    I changed my setup regarding what the slicer does and what is configured directly on the Duet yesterday and stumbled across something strange with the second print.

    Setup

    I have a start.g that looks like the following:

    ; start.g
    ; called by RRF when a print is started (not though when resumed)
    M80 ; Turn the VIN PSU on
    G21 ; metric values
    G90 ; absolute positioning
    M83 ; relative extrusion mode
    M106 P0 S0 ; start with the fan off
    M703 ; Load filament's config.g (includes heating)
    M350 E128 I0 ; Increase ustep factor on extruder to x128
    G28 ; home all axes

    My filament's config.g loaded by the above M703 looks like this:

    M207 S2.0 F6000 T2000 Z0.0 ; Firmware retract settings
    M572 D0 S0.1 ; Pressure Advance
    M140 S70 ; set bed temp
    M116 H0 ; wait for bed temp
    G10 P0 S230 ; set extruder temp
    M116 P0 ; wait for extruder temp

    My slicer is configured to not issue any commands related to heating and nothing in its start codes section.

    Expected Behavior

    What I expect from these codes would be the following:

    • when starting a print
    1. heat the bed
    2. heat the hotend
    3. home all axes
    • start printing
    • at the end of a print I call M0 which in turn calls stop.g (I do not have a cancel.g anymore)
    ; stop.g
    ; called when M0 (Stop) is run (e.g. when a print from SD card is cancelled)
    ;
    ; generated by RepRapFirmware Configuration Tool on Sat Apr 28 2018 20:07:26 GMT+0200 (CEST)
    G10 P0 R-273.15 S-273.15 ; extruder heater off
    M140 S-273.15 ; bed heater off
    [do some movements and turn off PSU]

    Observed Behavior

    Now, this worked for the first print as expected. The second print though the following order was observed:

    1. home all axes
    2. heat the bed
    3. heat the hotend

    I printed the exact same GCode again that worked the first time but the second time it did the homing first not last. In my case this is an issue because I have set M906 ... I0 and M84 S120 and heating takes longer than 120s so the motors had been turned off and at the start of the print the axes where no longer homed.

    Speculated Reason

    My guess is that it has to to with the commands in stop.g that turn the heaters off.

    Manuel
    Duet 3 6HC (v0.6) with RPi 4B on a custom Cartesian
    with probably always latest firmware/DWC (incl. betas or self-compiled)
    My Tool Collection

    1 Reply Last reply Reply Quote 0
    • undefined
      dc42 administrators
      last edited by 15 Jan 2019, 15:26

      You are using unsupported old release candidate firmware, so please upgrade your firmware to 2.02.

      I recall that there was a bug in older firmware that affected the last line of a macro file under some conditions, and that might responsible for what you observe.

      A common reason for a second print not behaving the same way as the first print is to do with whether or not a tool is selected before you start the print.

      Duet WiFi hardware designer and firmware engineer
      Please do not ask me for Duet support via PM or email, use the forum
      http://www.escher3d.com, https://miscsolutions.wordpress.com

      undefined 1 Reply Last reply 15 Jan 2019, 15:35 Reply Quote 0
      • undefined
        wilriker @dc42
        last edited by wilriker 15 Jan 2019, 15:35

        @dc42 You might have misread the listing of the versions. It is DWC that is running 2.0-RC3. RRF is 2.02 final.

        EDIT:
        I do have T0 in my config.g and also just one tool selected. I never deselect the tool - or is that done by G10 P0 R-273.15 S-273.15?

        Also why would it skip bed heating in this case?

        Manuel
        Duet 3 6HC (v0.6) with RPi 4B on a custom Cartesian
        with probably always latest firmware/DWC (incl. betas or self-compiled)
        My Tool Collection

        undefined 1 Reply Last reply 15 Jan 2019, 15:40 Reply Quote 0
        • undefined
          dc42 administrators @wilriker
          last edited by 15 Jan 2019, 15:40

          @wilriker said in [RRF 2.02] M703 blocking or async?:

          @dc42 You might have misread the listing of the versions. It is DWC that is running 2.0-RC3. RRF is 2.02 final.

          I'm sorry, I did indeed misread that.

          Your G10 command should not deselect the tool, although M0 will if you don't have a stop.g file. You are right, even if no tool is selected, it should still wait for the bed to heat up.

          Duet WiFi hardware designer and firmware engineer
          Please do not ask me for Duet support via PM or email, use the forum
          http://www.escher3d.com, https://miscsolutions.wordpress.com

          undefined 1 Reply Last reply 15 Jan 2019, 15:58 Reply Quote 0
          • undefined
            wilriker @dc42
            last edited by wilriker 15 Jan 2019, 15:58

            @dc42 I do have a stop.g (but not cancel.g) that does contain the above G10 command.

            Now I added explicit T0 to the beginning of my start.g and it seems to fix the issue.

            EDIT: the tool was listed as off in DWC after the print finished. T0 in start.g changes it to active.

            EDIT2: As an aside on this:
            G10 P P0 R-273.15 S-273.15 does turn the tool to off and sets both active and standby temperatures to 0°C
            M140 S-273.15 does turn the bed heater to off but it leaves its active temperature (and probably also the standby temperature) at the last set value.

            Is this difference intented?

            Manuel
            Duet 3 6HC (v0.6) with RPi 4B on a custom Cartesian
            with probably always latest firmware/DWC (incl. betas or self-compiled)
            My Tool Collection

            undefined 1 Reply Last reply 22 Jan 2019, 15:25 Reply Quote 0
            • undefined
              dc42 administrators @wilriker
              last edited by 22 Jan 2019, 15:25

              @wilriker said in [RRF 2.02] M703 blocking or async?:

              As an aside on this:
              G10 P P0 R-273.15 S-273.15 does turn the tool to off and sets both active and standby temperatures to 0°C
              M140 S-273.15 does turn the bed heater to off but it leaves its active temperature (and probably also the standby temperature) at the last set value.
              Is this difference intented?

              It probably wasn't intended, but I don't think it's unreasonable behaviour.

              I've never liked using -273.15 to turn heaters off, IMO there should be a more direct way.

              Duet WiFi hardware designer and firmware engineer
              Please do not ask me for Duet support via PM or email, use the forum
              http://www.escher3d.com, https://miscsolutions.wordpress.com

              undefined 1 Reply Last reply 22 Jan 2019, 15:27 Reply Quote 0
              • undefined
                wilriker @dc42
                last edited by 22 Jan 2019, 15:27

                @dc42 said in [RRF 2.02] M703 blocking or async?:

                I've never liked using -273.15 to turn heaters off, IMO there should be a more direct way.

                Same here.

                Manuel
                Duet 3 6HC (v0.6) with RPi 4B on a custom Cartesian
                with probably always latest firmware/DWC (incl. betas or self-compiled)
                My Tool Collection

                1 Reply Last reply Reply Quote 0
                1 out of 7
                • First post
                  1/7
                  Last post
                Unless otherwise noted, all forum content is licensed under CC-BY-SA