Duet Slicer Integration?

DocTrucker

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.

DocTrucker

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

garyd9

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

DocTrucker

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

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.

DocTrucker

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

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.

grizewald

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

TLAS

@grizewald

I don't suppose you use any modern cloud environment, like GitHub, Fusion 360 or OneDrive? It's not about computing power, it's about mobility, universal compatibility, and creating a community ecosystem with ease of access to everyone.

Major advantages of using a cloud technology (or really just web ignoring the buzz word), could involve the following:

Saving slicing configurations that follow you, regardless of the device.
Pre/parallel slicing using your standard configurations (view the g-code outputs immediately from your common settings to pick a starting point for refinement).
Direct access (without installation) to any of the top slicing engines, on any device.
Repositories of slicing configurations for specific printers, including manufacturer recommendations. Imagine "the nominal Bowden retraction is 2.7mm with a standard deviation of 0.7mm" for ultimakers, etc...
Direct access (without installation) to custom slicing engines optimized for specific printers and/or setups. Code and slicing setups for multi-color materials or multi-tool setups that can be easily shared.
Machine learning technologies that flag common failure settings for your geometry. "Changing to a 0.25mm first layer will increase the probability of a successful print for your printer by 20%"... etc...

Edit: I do agree with you about the personal network. I'd love to see whatever 'cloud' system is developed to have universal compatibility with a local network and distribute tasks / settings to all computers on that network with a lot of the benefits of a cloud but not actually leaving your own network.

DocTrucker

I think I may be talking at a slight tangent here because I don't wish to see one particular slic3r wrapped into the Duet, merely a robust way that I can achieve things such as slicing on the fly.

However, one thing that I really don't like about Slic3r (unless I have missed something) is that I can't save a 'build file' that is a single packet with the STL files, and the parameter sets used to create them. The closest I get to achieving this is manually creating build folder with the stl files and gcode contained. If I really needed to I could scrape (or import using Slic3r) the variables from the comments at the end of the file. This is a particular nuisance when I am experimenting with things like line width or fill patterns that can't be bodged with the DWC speed or extrusion multiplier sliders, or injected gcode.

In terms of long term re usability of the code I feel these sort of files are more useful than raw gcode too, as you would have the option of doing a side by side comparison to your current variable sets to see if you wish to change anything in the original to perhaps account for your preferred variable sets changing, or you've made a change to the machine. The other factor is the file is highly likley to be smaller, and so less likely to be corrupted by a random drive failure.

The thing is though if you are set on saving the gcode data you could preview sections of the file that give you cause for concern (potentially saving that previewed data as cached gcode) then have slice on the fly save the data as it runs. This way you have the benefit of no slice file prep time before you start (other than first slice that will probably be within warm up time) and no repeat processing of data later, but with the disadvantage of needing to store reems of extra data.

As for the cloud I'm not that fussed by that. I prefer to be able to work completely off the net if needed and be reliant on my own equipment.

TLAS

@DocTrucker said in Duet Slicer Integration?:

However, one thing that I really don't like about Slic3r (unless I have missed something) is that I can't save a 'build file' that is a single packet with the STL files, and the parameter sets used to create them. The closest I get to achieving this is manually creating build folder with the stl files and gcode contained. If I really needed to I could scrape (or import using Slic3r) the variables from the comments at the end of the file. This is a particular nuisance when I am experimenting with things like line width or fill patterns that can't be bodged with the DWC speed or extrusion multiplier sliders, or injected gcode.

Having just gone through the entire custom development setup to get everything working, I found out that all your configuration files are saved in %appdata%/Slic3r. Running the slicer from the command line interface is actually pretty effective. You could write a batch script to save off copies of your inputs at that given point in time fairly easily to back-reference.

Syntax took me a few minutes to get right though. You load in the .ini file in the main Sli3r directory to specify which filaments / printer / print settings you use, then will need to use the --load with each of those .ini files buried a bit deeper.

Danal

@DocTrucker said in Duet Slicer Integration?:

However, one thing that I really don't like about Slic3r (unless I have missed something) is that I can't save a 'build file' that is a single packet with the STL files, and the parameter sets used to create them

Slic3rPE certainly does this. Saves "project" files. File extension "3mf". Plate layout, settings, shapes, etc.

And... I use PE with multiple non-Prusa printers. No harder to set up a custom printer in PE than in Cura or whatever.

DocTrucker

@TLAS I've got the folder containing the printer, filament, and slicing settings on my dropbox account and redirect my slicer to load them at startup.

Interesting to hear your experience though. I thought it must be relatively straight forward as I had used some software in the past that ran the api or command line side of it.

DocTrucker

@Danal it is such an easy thing todo which is part of my frustration with the issue. I made similar features for experiments on F&S Realizer machines back somewhere around 2005 based on features I used on DTM 2000s before my research days, ironically around 2000.

I understand why Ultimaker and Prusa have done there own thing, but while I only have time for one slicer I will keep my efforts on a offering that isn't heavily tied with a specific manufacturer.

Danal

@DocTrucker said in Duet Slicer Integration?:

it is such an easy thing todo which is part of my frustration with the issue

Very good point.

Is there any possibility of someone "just doing" this, specifically in a format that can be a pull request?

TLAS

@Danal

Might already have - there’s a TON of pull request on the slic3r branch in Github. It feels like everyone seems to have their own version of slic3r, but the branches are more diverging than anything else. The main program updates are fairly slow and don’t seem to be adding a lot of features. But at the same time when you look at the issues, there’s a lot going on behind the scenes. Not really sure what to make of its development state.

I really wish the slicer was made in a more modern language though. Personally I’d only seen Perl used as alternatives to basic or Visual Basic (1990s) before slic3r. Would have loved at least C#.

Hard to match from the number of advanced features and customizations though. Anyone else know of anything in development that could match it? I’ve looked at several of the other major options and they are just missing a good number of the feature options.

Danal

@TLAS said in Duet Slicer Integration?:

I really wish the slicer was made in a more modern language though.

From the main slic3r github read me:

What language is it written in?
The core parts of Slic3r are written in C++11, with multithreading. The graphical interface is in the process of being ported to C++14.

I take it from your comment that the GUI is still mostly PERL... Which means a save/load would get into that territory as well. Hmmm...

TLAS

@Danal
Haven't tried too much compiling the GUI, but it looks like a lot of the more abstract commands are in Perl. Things like what extruder to use, which infill / perimeter to fill first, outputting the gcode are all in Perl.

They do have a C++ library version of it though (I haven't compiled that one as the instructions looked like it didn't have full support yet with some functions not working). Kind of curious if they ported the Perl to C++ there. I'll take a look.

DocTrucker

That work in progress explains a likely cause of some of the issues with the dev version. For example; changing parameter set on the tabs behaves differently to changing them on the right hand side and the parameter sets often need to be saved to commit changes to what will be used when slicing.

T3P3Tony

@TLAS

Do you know if the slicer on the Pi is doing everything in RAM or is it caching to disk? i to disk then you coul try a RAM drive as the working directory for your slicer.