Nonplanar Layers

[supermerill]

Discussion on how and what to integrate as nonplanar solution.

There is two solution I know:

• merge @Zip-o-mat fork into current codebase. [Feature Request] Nonplanar Layers #84
• incorporate the curvislicer "script" Feature Request: compatibility with curvislicer #177

For the first one, I don't know how hard it is. Zip-o-mat said that it was working to 'finish' it but maybe it won't.
For the second one, It has to be launched a first time to modify the object geometry, and a second time to post-process the gcode. The integration is useful to disable all problematic settings and to visualize the real object vs the modified object. It shouldn't be that hard.

@RaymondAndrea

[nordurljosahvida]

Thanks for opening the thread @supermerill. We've never used the curvislicer script, we're having excellent results with zip-o-mat's fork on our delta. @Zip-o-mat anything new since your last comment on jun 25? Could we ask you for pointers on where we could start?
For reference, @RaymondAndrea and I from our team could contribute with a dev, @tpimh is available to help.

Thanks to all

[Zip-o-mat]

Hi,
first of all I would love to see an implementation on an up to date slicer. Unfortunately, I can not help implementing this due to lack of time. But I will help getting a usable concept and can also help fixing issues.

First of all do you want to just port my concept/code as it is to a more modern slicer version or do you want to get a stable implementation for all users? If you want an implementation for all users, I would recommend to get a good concept and re implementing at least part of the code.

The implementation can be divided into three main topics:
1. Identification of nonplanar surfaces.
Do you want to use the automatic detection by surface angle(currently implemented) or a maybe a manual selection of nonplanar areas?
The automatic detection definitely needs a proper collision detection because otherwise only a few models are printable without collisions.

2. Collision detection
The current polygon layer based collision detection suffers from small artifacts that are created from offsetting and subtracting polygons from each other. In my opinion, my implementation is not really usable at this moment. Maybe the collision checking can be done on stl level and not on the layer polygon level.
Or the collision detection is thrown out but then you need manual selection and big warning signs that every user has to check for these collisions by eyeballing the gcode visualization.

3. Toolpath generation
This implementation also suffers from the small artifacts that are created from polygon offsetting especially on non vertical walls and complex shapes. Maybe there is a smarter way to create the nonplanar layer than the current projection based setup.

A good benchmark object for all these issues is this. It has layers that do not match the projection of the nonplanar surfaces, overhangs and nonplanar surfaces in the cheese holes. If you just print the last surface of the cheese, this should be printable. But I never got this object to work :(

For more information, I can just look in my thesis and the publication on the CASE conference.

[siamak06]

Good afternoon All,

OI am very new to this particular Thread, but I have been following the Non-Planar Tool-Path Generational for a while,

Zip-o-mat 's Slic3r is and excellent job, nevertheless it occupies only on the last few layers, very good.

This in more on the Aesthetic part of the printing,

The Main reason of Non-Planar Slicing and printing is t increase the mechanical properties of the printer object, Isotropic is the main objective of Non-Planar Slicing and printing, as far as I can say and tries, Curvislicer, can more or less achieve this property, but it is Command lien and indeed needs Post processing the gcode after having done the Slicing.

I think the Curviclicer is an Open-Source Slicer, and those who have the knowledge of Programming and Tool-Path generation, can do the integration into popular slicers, i.e Slic3r which is the most powerful one I can see and have used for several years now.

I we (Royal we) can try to keep the slicing as successive 3D curves, with very low angle and very low amplitude that can randomly increase at the beginning and decrease in the end, this can easily solve the collision problem?

I hope one day one person, hoping to be Zip-o-mat, that will come with a brilliant solution of integrating the Slic3r and Curvislicer together for us the Mortal users.

Cheers and good luck.

Siamak

[fhteagle]

I would like to add to the discussion by articulating the use cases I can see this working on. It might guide partial / incremental development to at least get something going as steps in the right direction.

I think the easiest use case, especially for the majority of nozzles that are fixed in orientation relative to the bed, is essentially nonplanar ironing of a nearly horizontal surface. Below a certain threshold angle, the slicer would add nonplanar passes with low volumetric flow to fill in the "steps" produced by planar slicing and layer buildups. This works for things like RC wings or drone rotors, where a layer-stepped leading edge really is not as big of a deal for noise, drag, and lift reductions as having a very smooth upper surface from forward of mid-chord to trailing edge. My other use case for this is 3d printing models of topography and land forms, where having a smooth surface would make demonstrating rainfall collection in various contour features easier for students and clients to see happening accurately. This method does not really enhance complex overhang situations, etc. This means collecting a critical angle (and critical depth below a gantry for cartesian and coreXY type motion systems) setting from the user (expressed in degrees from vertical like the current overhang support angle setting?), above which the smoothing will not even be attempted. Implementation decision about whether to collect and apply only one critical angle for every direction, or have separate angles for -X, +X, -Y, +Y, etc needs to be made. The math gets exponentially harder I think for the latter separate angle case, but might unlock steeper angles for some hot ends/abl/cooling duct setups.

I found this video that details some of the math involved in trying to get equidistant passes on nonplanar geometries. Very interesting, and probably could be adapted to the nonplanar ironing use case if the max distance between passes was some small multiple of the nozzle tip diameter, as in regular planar ironing. https://youtu.be/OZe4WKgbwnw

The second case I can contemplate is 3d printing via robot arm, where a curved toolpath at the "elbow" of the robot arm is the most efficient / least wear and tear motion for the machine. This more closely aligns to the Slicer4RTN where the nozzle rotates versus the plane. Again, very complex math to model this. Would also need to know information about the motion axes of the machine, which greatly adds complexity in the slicer algorithm. An interesting and cool use case, but probably out of scope.

The third case of complex overhangs, I wonder if the math would be easier by just non-horizontal but parallel planar slicing (analogous to slicing for a conveyor belt bed machine I think) the whole model until you find one angle that remains under the critical user defined no collision angle / depth, but at a maximum angle relative to the normal of all surfaces. Probably not that much easier, but it might be an interim step to get the program closer for now. A further iteration might be locally re-defining the non-horizontal planes of slicing, so most of it is horizontal, but user defined or automatically generated volumetric zoning tilts the planes by a little less than the critical angle (and no deeper than critical gantry collision depth) for just that section. Reset and re-try planar vs non-planar area decision logic once the critical collision depth is reached?

No idea if this rambling is helpful or not, but I am really looking forward to this feature working for my future projects. The math is kind of out of my wheelhouse, but I will be happy to contribute testing time whenever there's something worth testing.

Thanks.

[siamak06]

Good afternoon All,

OI am very new to this particular Thread, but I have been following the Non-Planar Tool-Path Generational for a while,

Zip-o-mat 's Slic3r is and excellent job, nevertheless it occupies only on the last few layers, very good.

This in more on the Aesthetic part of the printing,

The Main reason of Non-Planar Slicing and printing is t increase the mechanical properties of the printer object, Isotropic is the main objective of Non-Planar Slicing and printing, as far as I can say and tries, Curvislicer, can more or less achieve this property, but it is Command lien and indeed needs Post processing the gcode after having done the Slicing.

I think the Curviclicer is an Open-Source Slicer, and those who have the knowledge of Programming and Tool-Path generation, can do the integration into popular slicers, i.e Slic3r which is the most powerful one I can see and have used for several years now.

I we (Royal we) can try to keep the slicing as successive 3D curves, with very low angle and very low amplitude that can randomly increase at the beginning and decrease in the end, this can easily solve the collision problem?

I hope one day one person, hoping to be Zip-o-mat, that will come with a brilliant solution of integrating the Slic3r and Curvislicer together for us the Mortal users.

Cheers and good luck.

Siamak