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

    Duet Slicer Integration?

    Scheduled Pinned Locked Moved
    Duet Web Control
    12
    47
    3.1k
    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.
    • A Former User?
      A Former User
      last edited by

      @TLAS said in Duet Slicer Integration?:

      2). Workflow automation

      Select part in Fusion 360, Make -> 3D print. That sends the .stl file to the selected slicer software, verify settings and click print; off it goes to the Duet and start working.

      For some reason they moved the Make button off to a new "Tools" toolbar, so that adds a click, but apart from the time it takes to initially load the external slicer* its hard to improve the workflow unless you always use the same material and same slicer settings.

      *) which if you avoid Cura, isn't a big factor.

      1 Reply Last reply Reply Quote 0
      • A Former User?
        A Former User @TLAS
        last edited by

        @TLAS said in Duet Slicer Integration?:

        Workflow automation. I’m not sure I’m like the average user here or not, but as an Engineer, I work in native CAD design tools and have to export to STL, then open a slicer interface, slice the object, upload it to the Duet, then print. With a server directly connected to the Duet (which only happens to be on the pi here), you could plug the CAD software directly to the PI server and have a 1-click(ish) print capability. Leveraging pieces of a nice flexible web interface to debug any setup also helps streamline.

        That I can understand, but there is also the other side of the coin.

        As an engineering educator we use the multiple steps you mention specifically to get the junior engineers to be able to "switch" their brains to be able to accomplish the workflow tasks using different software systems on purpose.

        I'm all for tools to be used to streamline the process but if you unable to use/understand each "subsystem" on its own, we feel it (in our area) that if you make it too simple there is a lesser understanding of how the nuts and bolts of the process works.

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

          I think we will see the introduction of cloud-based slicing soon. Then you will be able to use a tablet to control the slicing, or even a smartphone. The Duet will log in to your cloud account and download the GCode file.

          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

          A Former User? 1 Reply Last reply Reply Quote 0
          • A Former User?
            A Former User @dc42
            last edited by

            @dc42

            That's a scary thought, while I find it interesting, my concern would be the risk of exposing the duet and possibly other hardware to the outside world unless a high level of network security was properly implemented.

            1 Reply Last reply Reply Quote 0
            • A Former User?
              A Former User
              last edited by

              Doesn't have to be scary, just optional.

              A Former User? 1 Reply Last reply Reply Quote 1
              • A Former User?
                A Former User @A Former User
                last edited by

                @bearer

                exactly, as long as it is.....

                1 Reply Last reply Reply Quote 0
                • T3P3Tonyundefined
                  T3P3Tony administrators
                  last edited by

                  Cloud connectivity would definitely be optional - I share the security concerns, and just because we now running an SBC on duet 3 the advice to not put it on the public internet (or large intranet) has not changed.

                  Where i see cloud connectivity being used initially is with services which add value that some people don't get from a normal slicer. that might be ease of use, or more advanced features or something. For the majority of current Duet users i think having control of all the steps will be preferred. Time will tell!

                  www.duet3d.com

                  TLASundefined 2 Replies Last reply Reply Quote 0
                  • Danalundefined
                    Danal
                    last edited by Danal

                    • All (or nearly all) of the "workflow is why" replies seem to ignore the fact that the slicer almost always requires some tweaking and re-slicing. At least for me.

                    Therefore, let me turn that into a question: Is it really true that a lot of people are just "clicking through" the sequence: Load an STL, slice it, save the gcode, without changing a single parameter in the slicer? Or even re-arranging things on the stage? I can see this in a big production shop; easily see this. But hobbyist people? "Just" workflow? That's pretty impressive.

                    • The "cloud is why" and/or "ecosystem is why", those I kinda get. Kind of.

                    I still don't entirely get the "use a tablet or phone" idea though.... where did the STL come from? Cloud storage? OK, so any browser device. Perhaps you guys are looking more to the future, and that's great, I just don't see it yet.

                    • And last:

                    @TLAS said in Duet Slicer Integration?:
                    ... you could plug the CAD software directly to the PI server...

                    ...you could plug the CAD software directly to the slicer on your MAC/PC just as easily (if not more easily). And, most of the major 'desktop' slicers have plug-ins for sending to Duet. This is super easy and very effective. I'd be really hinky about an "outside my local lan" service being able to send things to my printer. I do see "ease the workflow", fewer clicks, smoother, etc. I don't see that moving the slicer particularly helps this. In fact, it may hinder it.

                    • And, just to be clear, I'm not at all opposed to this happening for the people who want it. I'm really just figuring out how to make beneficial use of it, for me. Because, you know, its always all about me. šŸ™‚

                    Delta / Kossel printer fanatic

                    1 Reply Last reply Reply Quote 1
                    • TLASundefined
                      TLAS @T3P3Tony
                      last edited by

                      @T3P3Tony
                      @Danal

                      FYI, just ran a benchmark on the PI and my desktop machine. I used 3DBenchy as the stl object.

                      Desktop: 3.775 seconds
                      Ubuntu on Windows, slic3r compiled on device
                      16 GB Ram
                      Intel i7 6700K (Quad Core) Overclocked to 4.5 GHz (4.00 GHz base)

                      Raspberry Pi 4: 25.085 seconds
                      Raspbian, slic3r compiled on device
                      4 GB Ram
                      Cortex-A72 (ARM v8, Quad Core) 1.5GHz

                      Slicing Time Difference: 6.6x slower
                      CPU Difference: 3x slower

                      Conclusion:

                      • Architecture differences between the PI and a normal desktop account for an additional ~2x reduction in speed beyond base CPU speed differences.
                      • Actual slicing time on a desktop is trivial
                      • Slicing time on a Pi 4 is within usable bounds
                      • Slicing directly on the Pi may be faster than switching programs to a separate slicer in some conditions.
                      • Upload time to upload back to the Pi not considererd
                      DocTruckerundefined 1 Reply Last reply Reply Quote 1
                      • TLASundefined
                        TLAS @T3P3Tony
                        last edited by

                        @T3P3Tony
                        FYI, I'm planning to eventually integrate slic3r into the Web Control. In my use case, I need to run a slightly modified version of slic3r, and embedding it directly on the Pi seems like the easiest option.

                        I also think embedding a local application running on the windows machine outside of the browser would be ideal (say a node.js instance) so the slicing can be run on the users local machine without requiring the user to exit from the web interface and the communication can all happen on the back end.

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

                          I have to agree with @Danal here. It just doesn't make sense to me to just print a STL. We're not talking about a word processing document that is going to look almost identical no matter what printer or ink is used, and consumer 3D printing technology isn't to a point where we can have 2-3 generic presets (draft/normal/HQ) that work for everything.

                          To me, slicing is an interactive part of the workflow where I make decisions based on the specific printer, the specific filament, the specific model, the use case of the print, and even things like the weather (because I might want less part cooling fan if it's cold.)

                          Yes, I have some "presets" that I use as a starting point, but I almost always tweak those presets for specific prints. (I hate that programs like "cura" promote using only presets when they hide "advanced" settings by default.) The interaction of making a change and then previewing the change is valuable to me for making some decisions: Should I use tree supports or normal supports? Should I change the extrusion width a bit so there aren't gaps in thin parts? How will the slicer handle this flaw in the STL?

                          I'll admit that that the slicing technologies are getting better and moving closer to a point where a lot of decisions can be made automatically (for example, dynamic layer heights), but we aren't there yet...

                          "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 1
                          • Danalundefined
                            Danal
                            last edited by

                            @garyd9 said in Duet Slicer Integration?:

                            To me, slicing is an interactive part of the workflow

                            Exactly. Well phrased.

                            Delta / Kossel printer fanatic

                            1 Reply Last reply Reply Quote 0
                            • DocTruckerundefined
                              DocTrucker
                              last edited by

                              Regards speed when slicing is done on the PI the only requirement on speed is that it can prepare data faster than the machine can print it. I've been looking to run Slic3r from the command line for some time so I can get better control over the process, and prepare better ecperimental arrays. I don't need to see the gcode, but previewing slices would still be useful.

                              At the moment the preparing gcode in advance feels like a hang over from slow processor and limited ram days. If you slice the same stl file, with the same control variables twice you will get identical results. Therefore all I need is the variable set, the stls, and their orientation in the workspace.

                              Your not seeing the raw control set with gcode anyway, it is still a middle man with much mangling and further processing by the duet.

                              Running 3 P3Steel with Duet 2. Duet 3 on the shelf looking for a suitable machine. One first generation Duet in a Logo/Turtle style robot!

                              Danalundefined 1 Reply Last reply Reply Quote 0
                              • DocTruckerundefined
                                DocTrucker @TLAS
                                last edited by

                                @TLAS said in Duet Slicer Integration?:

                                Desktop: 3.775 seconds
                                Ubuntu on Windows, slic3r compiled on device
                                16 GB Ram
                                Intel i7 6700K (Quad Core) Overclocked to 4.5 GHz (4.00 GHz base)

                                Raspberry Pi 4: 25.085 seconds
                                Raspbian, slic3r compiled on device
                                4 GB Ram
                                Cortex-A72 (ARM v8, Quad Core) 1.5GHz

                                Fastest I've heard of benchys being printed was around 15 minutes at the East Coast Reprap Festival this year. The quality didn't appear what you would use on a day to day basis.

                                So 900 seconds to print, 25 seconds to slice. This should leave enough head room for running the duet at the same time.

                                Running 3 P3Steel with Duet 2. Duet 3 on the shelf looking for a suitable machine. One first generation Duet in a Logo/Turtle style robot!

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

                                  @DocTrucker said in Duet Slicer Integration?:

                                  @TLAS said in Duet Slicer Integration?:

                                  Raspberry Pi 4: 25.085 seconds
                                  Raspbian, slic3r compiled on device
                                  4 GB Ram
                                  Cortex-A72 (ARM v8, Quad Core) 1.5GHz

                                  So 900 seconds to print, 25 seconds to slice. This should leave enough head room for running the duet at the same time.

                                  I'm curious what slicing options were selected, and how much of the time spent was actually slicing/processing and how much time was just writing to the sdcard. Slicing isn't a single-pass bottom to top process. Aspects of the "top" of the print impact how the lower levels will be sliced. (For example, supports.) That suggests that printing can't start until after the slicing is completed...

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

                                  DocTruckerundefined 1 Reply Last reply Reply Quote 1
                                  • DocTruckerundefined
                                    DocTrucker @garyd9
                                    last edited by

                                    @garyd9 yes, slicing isn't purely concerned with data that intersects that slice plane, but things like supports can be represented as a surface which is then sliced. I've not dug into the details of how slic3r does it yet.

                                    Running 3 P3Steel with Duet 2. Duet 3 on the shelf looking for a suitable machine. One first generation Duet in a Logo/Turtle style robot!

                                    1 Reply Last reply Reply Quote 0
                                    • Danalundefined
                                      Danal @DocTrucker
                                      last edited by Danal

                                      @DocTrucker said in Duet Slicer Integration?:

                                      the only requirement on speed is that it can prepare data faster than the machine can print it.

                                      Once again, I'm incredibly impressed that there is NO review in that workflow. Start printing before slicing finishes... man someday I hope to reach that level of expertise in operating a slicer, that I don't even have to glance at its output before the print starts.

                                      If you slice the same stl file, with the same control variables twice you will get identical results. Therefore all I need is the variable set, the stls, and their orientation in the workspace.

                                      This is a non-sequitur. If the STL was sliced before, the gcode exists. Identical stl/control/slice should never be a "time critical" critical path, for example in a shop that prints the same thing 20 times, the gcode should be reused for 2 through 20.

                                      Delta / Kossel printer fanatic

                                      DocTruckerundefined TLASundefined 2 Replies Last reply Reply Quote 0
                                      • DocTruckerundefined
                                        DocTrucker @Danal
                                        last edited by

                                        @Danal said in Duet Slicer Integration?:

                                        Once again, I'm incredibly impressed that there is NO review in that workflow. Start printing before slicing finishes... man someday I hope to reach that level of expertise in operating a slicer, that I don't even have to glance at its output before the print starts.

                                        There's only no review if you cut out the bit of my post where I talk about previewing slice data. I don't need to see the whole lot, and I don't often go through preview data when I am working with a known variable set.

                                        @Danal said in Duet Slicer Integration?:

                                        This is a non-sequitur. If the STL was sliced before, the gcode exists. Identical stl/control/slice should never be a "time critical" critical path, for example in a shop that prints the same thing 20 times, the gcode should be reused for 2 through 20.

                                        I was merely saying that there isn't a degree of randomness in how the slicer behaves, unless you request it. Give it the same geometry and you get the same result. Much like I don't need to see the fine by time instructions the duet creates.

                                        Running 3 P3Steel with Duet 2. Duet 3 on the shelf looking for a suitable machine. One first generation Duet in a Logo/Turtle style robot!

                                        1 Reply Last reply Reply Quote 0
                                        • TLASundefined
                                          TLAS @Danal
                                          last edited by TLAS

                                          @Danal
                                          FYI, here are a few other thoughts with a potential implementation:

                                          • The gcode viewer would be implemented in the web interface to allow gcode viewing / live look-ahead (see the previous post I mentioned before).
                                          • I would reuse the 3D viewer to show STL files and locations prior to sending them to the slicer and viewing gcode. This would allow placement and other settings common in programs like Repetier Host.
                                          • A nice, searchable UI would allow modification of the Slic3r settings (or potentially other slicers). Should be much cleaner and more usable when compared to the slic3r native gui.
                                          • Slicing could be performed on the Pi or pushed to the computer you're working from for the slicing.
                                            • Once you launch the 'Duet Slicing Application' on your machine, it should just look like 2 buttons in the web interface -
                                            • Slice on Pi // Slice on Computer
                                              Maybe at some point a // Slice on cloud could be implemented very easily. Essentially the same thing as the 'Slice on Computer' just over the internet rather than your local machine.
                                          grizewaldundefined 1 Reply Last reply Reply Quote 0
                                          • grizewaldundefined
                                            grizewald @TLAS
                                            last edited by

                                            @TLAS said in Duet Slicer Integration?:

                                            Maybe at some point a // Slice on cloud could be implemented very easily. Essentially the same thing as the 'Slice on Computer' just over the internet rather than your local machine.

                                            Why on earth would I want to pay someone like Amazon to perform trivial computing tasks for me when I already have countless thousands of MIPS on my own, private network at home?

                                            It seems just as pointless as reducing my choice and slowing down the process by having a slicer integrated into the Duet web interface running on a Pi.

                                            As others have rightly pointed out, getting the right g-code for a good print depends on many factors - the model being printed is one of the most important ones. I fail to see what Pi integration, a fixed choice of g-code generator or farming trivial computing tasks out to a third party brings to any 3D printing workflow, apart from increasing the buzzword score.

                                            Maybe we can slice on the blockchain? šŸ™„

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