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

    New firmware 1.21RC3 available

    Scheduled Pinned Locked Moved
    Firmware installation
    31
    159
    24.0k
    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.
    • deckingmanundefined
      deckingman
      last edited by

      @dc42:

      …..........................................
      Coming back to M564, currently we have:

      S0 - allow movement outside limits
      S1 (in practice, Sn for n >= 1) - don't allow movement outside limits

      I could add another parameter:

      H0 - allow movement before the axis has been homed (not for Delta or Scara printers)
      H1 - don't allow movement before the printer has been homed (default)

      ....................................

      Personally, I'd be happy with that. If it just means putting M564 H1 into my config.g file which will easier than having to edit my homing files and also save me the hassle of creating a macro and more importantly, remember that I have to use it.
      I appreciate the safety concern but over the years, I've become accustomed to doing things a certain way. As well as the scenarios that others have put forward, I often just want to drop the bed 100mm or so to get it out of the way when I want to change hot ends, remove the glass for cleaning, apply a coat of 3d lac without getting it on the hot end or otherwise work on the printer. So having to home it first when I don't even want to print anything would be a bit of a PITA.

      Ian
      https://somei3deas.wordpress.com/
      https://www.youtube.com/@deckingman

      1 Reply Last reply Reply Quote 0
      • garyd9undefined
        garyd9
        last edited by

        @whosrdaddy:

        +1 for M564 H0
        @Garyd9, adding M564 H0 to config.g would be enough, no need to add an option to PanelDue/DWC.

        For some reason, I completely overlooked that M564 H0 could be left permanently enabled (via config.g.)

        "I'm not saying that you are wrong - I'm just trying to fit it into my real world simulated experience."

        1 Reply Last reply Reply Quote 0
        • resamundefined
          resam
          last edited by

          Yes, M564 H0 would be acceptable. I probably also put it in my config.g.
          Thanks!

          If you really want to make me happy, please add a button in the PanelDue jog window - so this override is accessible when needed.

          1 Reply Last reply Reply Quote 0
          • Catalin_ROundefined
            Catalin_RO
            last edited by

            Regarding homing for CNC machines, I think that the truth is somewhere in the middle. For rather simple machines, with no slave axis and no extra features (like touch probes for the tool length or tool changers), homing is not needed at all. One just jogs the spindle to the desired position, based on the already positioned raw material, zeros the coordinates and starts the job. With GRBL the homing can be disabled completely and a freshly started machine, although it reports it needs homing, can be software reset and unlocked and homing is no longer needed no matter what.

            Realistically now, with CNC homing is really necessary for machines with slave axis that can get out of sync (independent motors as the solution with mechanical link between the master and slave axis is much simpler for the controller) and when there are various tools installed at well defined machine coordinates.

            Looking differently at it, for 3D printing it might be more important than for simple CNC machines. With 3D printing you have to print an item of a certain size and you need to know that the object won't get beyond the printable area if the origin of the print is not correctly set. With CNC you already have a big lump of raw material, at least as large as the final item, and if you know the area that the machine can "process", it is practically impossible to go beyond that (misplacing the raw material or going for a smaller piece is not considered here!).

            As for the dangers of homing, the CNC world has its own! It is not unheard of using a tool longer than what is safe in the machine setup, based on the fact that one can manually jog through the obstacles to the location where the machining has to be done. Homing in such situations, although the Z-axis is almost always the first one, doesn't guarantee that the tool doesn't touch an obstacle. Allowing manual jogging without homing first would be very useful in these situations as well! (been there myself, luckily with rather inexpensive tools in the spindle!)

            In conclusion, there should be a rather easy solution for jogging without homing, especially because the emergency situations are really critical! By default it should not be allowed, but a manual override solution would be great. User defined macros are acceptable from my point of view….

            1 Reply Last reply Reply Quote 0
            • garyd9undefined
              garyd9
              last edited by

              @Catalin_RO:

              In conclusion, there should be a rather easy solution for jogging without homing, especially because the emergency situations are really critical! By default it should not be allowed, but a manual override solution would be great. User defined macros are acceptable from my point of view….

              Most (all?) of the points for movement when not homed are in non-printing situations. They occur either before a print is started (with the understanding that homing must occur before a print can start) or after a print is finished or aborted. Remember also that this is all in relation to manual movements such as jog controls, and not to any type of automated or unattended movement. The act of pressing one of the jog control buttons is always a "manual override."

              "I'm not saying that you are wrong - I'm just trying to fit it into my real world simulated experience."

              1 Reply Last reply Reply Quote 0
              • garyd9undefined
                garyd9
                last edited by

                RC3 issue: Unable to simulate printing due to printer not being homed. (The irony here is that one of the first commands the gcode file is G28)

                From my gcode console log:

                [[language]]
                6:35:45 PM    M37 P"ABS - L/Car_Ears2.gcode"
                                      Simulating print of file ABS - L/Car_Ears2.gcode
                                      Error: G0/G1: insufficient axes homed
                
                

                Here are the first instructions in my gcode file (skipping comments) up to the G28:

                [[language]]
                G90
                M83
                M106 S0
                ; S3D starting gcode for LEFT extruders
                ;
                M140 S105  ; start heating the bed (no wait) while homing
                G28                       ; homeall
                
                

                Additional info: The above all occurred via DWC. When I went to the physical location of the printer, I found that PanelDue was reporting that the printer was in a "simulating" status (and ended up doing an "emergency stop" via the paneldue to get control.)

                "I'm not saying that you are wrong - I'm just trying to fit it into my real world simulated experience."

                1 Reply Last reply Reply Quote 0
                • CRPerryJrundefined
                  CRPerryJr
                  last edited by

                  Unable to upgrade Duet 0.85 to 1.21RC3 from 1.19.2 using RepRapFirmware.bin. I tried utilizing DWC firmware update method first, and it appeared to transfer successfully and reboot, but it failed come back up. I tried erasing and utilizing the Bossac method. The new firmware transfers successfully via Bossac, but causes the Duet to reboot itself after 30 seconds or so repeatedly. (I can tell because the USB drops and reconnects about every 30 seconds.) Erased and Reflashed the firmware using Bossac back to 1.19.2 and the Duet is operating normally again.

                  1 Reply Last reply Reply Quote 0
                  • Catalin_ROundefined
                    Catalin_RO
                    last edited by

                    Jog controls, while being a "manual override" situation, could easily tell the controller to go beyond the hardware possibilities (printing head/spindle at coordinate 50 on one axis, and the user asks moving that axis with -100…). Thus manual override must be a "high level decision", so the controller should not accept any jog command as being such a decision by default, at least not with GUI based jog solutions.

                    Regarding 3D printing, I must admit that my own experience is non existent for now (not needed so far!). I do only CNC, and I do that only when there is a real a real need, not as a hobby. But I tend to understand the 3D printing problems, looking from above, as I follow the domain for many years.

                    Again, comparing to my every day situations, when I have to find ways to implement something in software that suits more customers, a solution to tell firmware it should no longer care about homing is clearly needed. How it is implemented is less important - it could be a 5-6 characters command or a 10K macro - it just needs to be rather simple way to access. Complex macros can be easily copy&pasted, simple commands can be turned into macros.

                    With 3D printing I see a lot of issues regarding printing resuming.. Worst case scenario - for a 10 hours job, the power goes away after every 20 minutes of printing. Let's consider that the printer is recovering when the power is back on, of course, with some delay. How about the missing microstepping status? Personally, I wouldn't even dare considering continuing a failed print. If really unlucky, a normally vertical wall would be just another staircase! And clearly this one would not go to heaven! 😉

                    1 Reply Last reply Reply Quote 0
                    • dc42undefined
                      dc42 administrators
                      last edited by

                      @CRPerryJr:

                      Unable to upgrade Duet 0.85 to 1.21RC3 from 1.19.2 using RepRapFirmware.bin. I tried utilizing DWC firmware update method first, and it appeared to transfer successfully and reboot, but it failed come back up. I tried erasing and utilizing the Bossac method. The new firmware transfers successfully via Bossac, but causes the Duet to reboot itself after 30 seconds or so repeatedly. (I can tell because the USB drops and reconnects about every 30 seconds.) Erased and Reflashed the firmware using Bossac back to 1.19.2 and the Duet is operating normally again.

                      Several users have reported this problem with various versions of RRF, one even with version 1.18. it's something to do with DHCP because setting a static IP address in the M552 command fixes it.

                      Please share your config.g file and I'll have another go at reproducing it.

                      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

                      1 Reply Last reply Reply Quote 0
                      • dc42undefined
                        dc42 administrators
                        last edited by

                        @Mike:

                        I'm getting "Error: Attempt to seek on a non-open file." upon trying to print files from slic3r PE on 1.21RC3. The same files work OK on 1.20.

                        I can't reproduce this, nor find a reason for it. Can you share the GCode file? What is the filename? Does the print go ahead, or not?

                        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

                        1 Reply Last reply Reply Quote 0
                        • resamundefined
                          resam
                          last edited by

                          Weirdly I also just got this "Error: Attempt to seek on a non-open file." error.
                          The first line (G28 X Y) is executed, and the the print stops with this error.

                          I have to mention, this is not a regular gcode file from a slicer. It was generated by LaserWeb and should utilise a laser with M452 to cut paper. I tried to "fake" a few expected magic comments like layer height, slicer name, etc. but it still errors.

                          Here is my gcode file (manually reduced, but still shows the fault for me): https://www.dropbox.com/s/5mczpuy9vzst7jb/pew-pew.gcode?dl=0

                          Here my debug:

                          18:45:47 M122
                          === Diagnostics ===
                          Used output buffers: 3 of 32 (14 max)
                          === Platform ===
                          RepRapFirmware for Duet 2 WiFi/Ethernet version 1.21RC3 running on Duet WiFi 1.02 or later
                          Board ID: 08DDM-9FAMU-JWNSW-6J9F2-3S46N-KLJRT
                          Static ram used: 16144
                          Dynamic ram used: 100584
                          Recycled dynamic ram: 2056
                          Stack ram used: 1224 current, 8496 maximum
                          Never used ram: 3792
                          Last reset 00:01:47 ago, cause: software
                          Last software reset at 2018-03-09 18:43, reason: User, spinning module GCodes, available RAM 3792 bytes (slot 1)
                          Software reset code 0x0003 HFSR 0x00000000, CFSR 0x00000000, ICSR 0x0041f000, BFAR 0xe000ed38, SP 0xffffffff
                          Error status: 0
                          Free file entries: 10
                          SD card 0 detected, interface speed: 20.0MBytes/sec
                          SD card longest block write time: 0.0ms
                          MCU temperature: min 40.6, current 40.9, max 41.2
                          Supply voltage: min 24.1, current 24.2, max 24.4, under voltage events: 0, over voltage events: 0
                          Driver 0: standstill, SG min/max 0/37
                          Driver 1: standstill, SG min/max 0/34
                          Driver 2: standstill, SG min/max 0/148
                          Driver 3: standstill, SG min/max not available
                          Driver 4: standstill, SG min/max 0/160
                          Date/time: 2018-03-09 18:45:47
                          Slowest main loop (seconds): 0.155312; fastest: 0.000113
                          === Move ===
                          MaxReps: 2, StepErrors: 0, LaErrors: 0, FreeDm: 240, MinFreeDm 236, MaxWait: 61748ms, Underruns: 0, 0
                          Scheduled moves: 6, completed moves: 6
                          Bed compensation in use: none
                          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 ===
                          Responder states: HTTP(1) HTTP(0) HTTP(0) HTTP(0) FTP(0) Telnet(1) 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.21RC4(08b3)
                          WiFi MAC address ec:fa:bc:0b:fb:94
                          WiFi Vcc 3.33, reset reason Turned on by main processor
                          WiFi flash size 4194304, free heap 14944
                          WiFi IP address 10.0.0.42
                          WiFi signal strength -48dBm, reconnections 0, sleep mode modem
                          Socket states: 2 2 0 0 0 0 0 0
                          === Expansion ===
                          18:45:41Error: Attempt to seek on a non-open file.
                          
                          
                          1 Reply Last reply Reply Quote 0
                          • Mikeundefined
                            Mike
                            last edited by

                            @dc42:

                            @Mike:

                            I'm getting "Error: Attempt to seek on a non-open file." upon trying to print files from slic3r PE on 1.21RC3. The same files work OK on 1.20.

                            I can't reproduce this, nor find a reason for it. Can you share the GCode file? What is the filename? Does the print go ahead, or not?

                            I did, it got buried earlier in the tread. Here it is again:

                            ; generated by Slic3r Prusa Edition 1.39.1-beta1-prusa3d-win64 on 2018-03-06 at 18:25:08
                            
                            ; 
                            
                            ; external perimeters extrusion width = 0.45mm
                            ; perimeters extrusion width = 0.45mm
                            ; infill extrusion width = 0.45mm
                            ; solid infill extrusion width = 0.45mm
                            ; top infill extrusion width = 0.40mm
                            ; first layer extrusion width = 0.45mm
                            
                            M107
                            M106 P1 S0.1 I0 F500 H-1; 
                            M140 S110;
                            G28 X Y
                            G1 X150 Y100
                            M190 S110;
                            G30 X150 Y100
                            G1 X150 Y100 Z25
                            M104 S267 T0; 
                            M109 S267 T0;
                            M106 P1 S0.2 I0 F500 H-1; 
                            ; Filament gcode
                            ;M290 S0.05
                            G21 ; set units to millimeters
                            G90 ; use absolute coordinates
                            M83 ; use relative distances for extrusion
                            G1 Z0.300 F10500.000
                            G1 E-1.20000 F2280.00000
                            G1 X125.225 Y99.725 F10500.000
                            G1 E1.20000 F2280.00000
                            G1 F600
                            G1 X174.775 Y99.725 E2.38319
                            G1 X174.775 Y100.275 E0.02645
                            G1 X125.225 Y100.275 E2.38319
                            G1 X125.225 Y99.785 E0.02357
                            G1 X125.625 Y99.726 F10500.000
                            G1 X125.418 Y100.000 F10500.000
                            G1 F600
                            G1 X174.582 Y100.000 E1.00800
                            G1 E-1.20000 F2280.00000
                            ; Filament-specific end gcode 
                            ;END gcode for filament
                            M104 S0 ; turn off extruder
                            M140 S0 ; turn off bed
                            M107; Turn off fans
                            G91
                            G1 Z50 ; lift z
                            G90
                            ;G28  Z; home all axes
                            M84 ; disable motors
                            M106 P1 S0.5 I0 F500 H-1; dim lights
                            
                            

                            It's a tiny test object, just 2 lines. The same job sliced in S3D or Slic3r PE doesn't start on the CoreXY - the execution stops after finishing the G28 command.

                            Edit: As for the filename it was something very generic - test_line.gcode or something similar. No special characters. The file shows up in the "G-codes" tab in DWC, no issues there.

                            1 Reply Last reply Reply Quote 0
                            • resamundefined
                              resam
                              last edited by

                              dc42: did you consider simulation mode and unhomed moves? I think I found a bug in RC3:
                              Simulating a print fails everytime with: "Error: G0/G1: insufficient axes homed".

                              I know that the file in question prints fine, because I successfully printed it the day before yesterday.

                              1 Reply Last reply Reply Quote 0
                              • dc42undefined
                                dc42 administrators
                                last edited by

                                Yes, that's a known issue.

                                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

                                1 Reply Last reply Reply Quote 0
                                • nytundefined
                                  nyt
                                  last edited by

                                  @dc42:

                                  Yes, that's a known issue.

                                  So how about double tap homing on G30? Possible to add behavior to match bed leveling?

                                  1 Reply Last reply Reply Quote 0
                                  • dc42undefined
                                    dc42 administrators
                                    last edited by

                                    @nyt:

                                    @dc42:

                                    Yes, that's a known issue.

                                    So how about double tap homing on G30? Possible to add behavior to match bed leveling?

                                    I am looking at this now. It would be easier if I change the behaviour of G30 with no P parameter so that after probing it moves the probe up to the dive height, just as it does when there is a P parameter. Can anyone see a reason why I shouldn't make this change?

                                    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

                                    1 Reply Last reply Reply Quote 0
                                    • resamundefined
                                      resam
                                      last edited by

                                      @dc42:

                                      It would be easier if I change the behaviour of G30 with no P parameter so that after probing it moves the probe up to the dive height, just as it does when there is a P parameter. Can anyone see a reason why I shouldn't make this change?

                                      Sounds good for my CoreXY. It would also be nice if I could do a fast-slow Z-home with G30. Currently the probe speed is fixed in M558 - and I don't really like copy-pasting my M558 lines to get different speeds.

                                      Either M558 can take two parameters: a slow and a fast speed,
                                      or G30 takes a new parameter to override the probe speed for the single probing move.

                                      1 Reply Last reply Reply Quote 0
                                      • dc42undefined
                                        dc42 administrators
                                        last edited by

                                        Another possibility I have considered is to keep G30 behaving as now (but possibly with a speed override), but to make G30 P0 Z-9999 S1 do "1-factor calibration" on all machine architectures, i.e. set the Z height. Then in homez.g you would do G30 followed by G30 P0 Z-9999. The G30 with P parameter would support multi tap.

                                        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

                                        1 Reply Last reply Reply Quote 0
                                        • nytundefined
                                          nyt
                                          last edited by

                                          Speed override would be great, could do a normal home like that, then whatever multi tap command.

                                          1 Reply Last reply Reply Quote 0
                                          • dc42undefined
                                            dc42 administrators
                                            last edited by

                                            I have changed the code so that G30 by itself can do multi tap. Only G30 S-1 and S-2 now do single tap on!y.

                                            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

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