Duet Slicer Integration?



  • So if you haven’t seen the post on the 3D code viewer, head over and check that one out.

    Anyway, gave me a thought - with the PI now serving the next generation web interface, why not incorporate a slicer into the mix? (say slic3r).

    By utilizing the code viewer, you could view the output. Integrating with the same 3D viewer for part placement wouldn’t be too difficult an interface to create via html. A simple dialog pop up for Slic3r inputs... then pass it from the web UI back to the server on the pi and have the pi launch slicer, then deliver the gcode back to the UI for the viewer.

    This could be an opportunity to create a full platform for slicing and part preparation, fully leveraging the Duet’s capabilities.

    Thoughts?



  • Haven't tried yet on the pi4, but I tried slicing on a pi3B+ and it was dog slow... I think I'd keep slicing on my computer anyways as I have multiple printers that I want to feed gcode from one place (and not all of them are worth the investment of a full duet3 treatment).



  • In case you are interested, you can find armhf builds of my Cura development releases that will run on Buster at https://www.dropbox.com/sh/s43vqzmi4d2bqe2/AAADdYdSu9iwcKa0Knqgurm4a?dl=0

    As you would expect, performance isn't stellar but it is actually usable. All the normal functionality is there apart from the fact that the layer display is using compatibility mode due to the legacy OpenGL support available on the Pi 4.

    1_1568016569047_Screenshot_2019-09-09_09-08-21.png
    0_1568016569046_Screenshot_2019-09-09_09-09-08.png



  • That's pretty impressive, @burtoogle!



  • I'd be surprised if the community didn't throw that together, especially if dc42 makes a Duet 2 firmware that allows Pi to be used instead of wifi/ethernet, and possibly the next Maestro version.

    Personally I don't see the usefullness as I hardly use the browser from anything else than my computer, and at that point its faster to slicer locally anyways, but I'm sure others have differing workflows.

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



  • I personally think this idea is a non starter for a number of reasons.

    1. As has been said slicing on a SBC is going to be more than a little slow.

    2. The real world use other than the novelty factor is going to be very limited.

    3. (the killer blow) the Duet 3 is aimed at more than just a 3d printer and certain OEM's are going to be using it with their chosen software, so if you choose one slicer over an other you might be pissing off a huge customer base (read that as the potential to be losing revenue)


  • administrators

    @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!



  • @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.



  • @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.



  • @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.



  • @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



  • @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.



  • 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?



  • @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.



  • @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.



  • @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.


  • administrators

    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.



  • @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.



  • Doesn't have to be scary, just optional.



  • @bearer

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


Log in to reply