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.
    • T3P3Tonyundefined
      T3P3Tony administrators
      last edited by

      @CaLviNx We would not seek to endorse only one slicer integration however...

      Duet 3/SBC should allow an infrastructure where slicers can be "plugged in" to the API. This will of course require work by the slicer devs or third parties, its too soon to say if this is functionality that people will want on the SBC, on their PC with a more tightly coupled network between the SBC and the PC or "on the cloud" we shall see!

      www.duet3d.com

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

        @T3P3Tony

        I agree. I can see both a local version and a remote (desktop) version being useful.

        All you’d really need to execute the slicer on a remote machine is a application / server to bypass the CORS and executable restrictions of the normal browser environments. With most slicers relatively small, you could even download them directly from the PI with minimal delay.

        Now, that being said, I’d be interested if anyone has any benchmarks for a slicing file on the pi vs desktop. The PI 4 CPU is nothing to laugh at - 1.7 GHz quad core. At worst, that’s only ~3x slower than top of the line desktops. The benchmarks to previous pi generations shows between 2x and 8x improvement.

        There are a couple of potential roadblocks around that CPU though - if the slicer writes to disk when slicing instead of memory, you’ll hit the SD bandwidth pretty quickly. Another one could be the GPU if that is used to do matrix decomposition operations in the slicer software. While the GPU doesn’t sound bad, it is a long shot from state of the art. While the quad core could benefit the slicer, I’d actually be fairly surprised if any open source slicer software was written with multi-core utilization.

        Anyway, I think it’ll be worthwhile to gather some benchmarks to understand exactly how feasible slicing on the pi is. If no one else has anything already, I’ll queue it up in my todo list.

        burtoogleundefined 1 Reply Last reply Reply Quote 0
        • burtoogleundefined
          burtoogle @TLAS
          last edited by

          @TLAS said in Duet Slicer Integration?:

          I’d actually be fairly surprised if any open source slicer software was written with multi-core utilization.

          Well, Cura does make use of multiple cores for various operations (even on the Pi!)

          In terms of performance running on the Pi, the Cura slicer backend that does the actual conversion of models to g-code (written in C++ and utilises multiple cores) runs pretty quickly. The GUI front end which handles all the configuration of profiles, loading of models, etc. is made from some combination of Python + QT + QML + OpenGL shaders and is fairly sluggish. I think a lot of that is down to the legacy OpenGL support.

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

            @burtoogle
            With the Duet server using web technologies, the UI should be fairly low impact for any slicer setup and viewing. Even the new WebGL graphics technology integrates well with the GPU. I’m thinking that most practical versions would just run the slicer from the command line and rely on a good web interface for the UI components.

            Interesting to hear about Cura’s Multi-core utilization. Do you know if that’s used in the actual geometric processing of the STL layers? From a CPU / GPU standpoint, I’d imagine that’s the most demanding task.

            burtoogleundefined 1 Reply Last reply Reply Quote 0
            • psychotik2k3undefined
              psychotik2k3 @A Former User
              last edited by

              @bearer said in Duet Slicer Integration?:

              Edit: Live preview while processing a job on the other hand would be quite welcome, at least for cnc and laser

              totally agree with you

              1 Reply Last reply Reply Quote 0
              • burtoogleundefined
                burtoogle @TLAS
                last edited by

                @TLAS said in Duet Slicer Integration?:

                Interesting to hear about Cura’s Multi-core utilization. Do you know if that’s used in the actual geometric processing of the STL layers?

                Yes, a lot of the processing is done using parallel constructs that make use of all the available CPU cores. The GPU (if any) is not used by the backend, it's only used for the UI.

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

                  Serious question here, not challenging... just curious:

                  What is the use case for slicing on the printer? Octoprint has had this forever and I've never used it. I just don't "get it".
                  Genuinely curious what workflow this helps, etc?

                  • Are there circumstances where I am going to submit a print starting with an STL, and I'm originating on a device that doesn't slice?

                  Phones/Tablets don't strike me as good places to be manipulating STLs...? Nearly anything else, where I would actually be working with STLs, such as a Windows PC, Mac, Linux... They all run slicers better than the Pi or whatever that's on the printer. Yes? No?

                  • Why would I be more willing to try to tweak slicer settings remotely? Why not directly tweak the slicer on my originating device?

                  It is pretty rare for me to open a slicer, slice, and go, without changing a setting or two and re-slicing several times. I use S3D, Cura, and Slic3rPE on a regular basis and I find this to be true of all three.

                  • Performance?

                  It is hard for me to see a use case where the Pi is anywhere near the speed of whatever submitted the STL to the Pi.

                  What am I missing? What is a frequent/common use case for this?

                  Delta / Kossel printer fanatic

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

                    @Danal
                    For me, there would be 2 major draws:

                    1. A decent, open, modern UI. Web technologies trump pretty much everything out there in terms of usibility, ease of programming, and potential for future expansion.
                      2). 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.

                    Also, to piggy back on the cloud comments earlier - if Duet were to create a cloud service, it could start to leverage machine learning and AI to predict failed part geometries and/or optimize component placing and slicing automatically. Let alone begin to gather interesting data like printer calibration over time, better time estimation for prints, and common configuration errors or buggy code. It really opens the doors to a lot of future capabilities beyond the silo’d machine approach.

                    I do agree that just using the pi as a slicer because you can isn’t that much a benefit. Thinking it’s more about what you can wrap around it.

                    A Former User? 1 Reply Last reply Reply Quote 0
                    • 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
                                            • First post
                                              Last post
                                            Unless otherwise noted, all forum content is licensed under CC-BY-SA