[semi-on-topic] print speed optimized sinus support material. integration interface possible??
well what should i say? i am glad your slicer is working out well for
you, so you will probably have no need for similar tools and all the
export and import steps the process requires,
it was definitely not the case on my models with slic3r, that was the
very reason i interrupted the work on the part and took time to
implement the support.
first in .scad and redoing it in javascript for the reasons we have been
talking about. and it is actually working reasonably well for me (and i
am not going to say perfect no, but it is an obvios improvement in
support quality vs printing time in my case).
there are many reasons i am not going to f#rk (with) slicers source i
just have been discussing in the same thread with nop-head. there were
many reasons to go the .js path, and it seems to work, and i hope others
who experience similar problems with slicers support, can use it as
well, that is why i put it on github, and in the process of this
discussion may be we will come up with a way of making openscad more
extensible and open for tools. thats it.
Peter
On 12.03.2016 16:21, Parkinbot wrote:
My slicer does a nice path on that. If linewidth is not to thin jump don't
occur often. Of course, there are jumps at the boundaries. Jump minimization
is another task done by the slicer.
So, if path planning and GCODE optimization is your concern, OpenScad will
not help you. Better follow nophead's proposal and fork out your own slic3r
branch to solve your problems there. https://github.com/alexrj/Slic3r
Rudolf
--
View this message in context: http://forum.openscad.org/semi-on-topic-print-speed-optimized-sinus-support-material-integration-interface-possible-tp16383p16443.html
Sent from the OpenSCAD mailing list archive at Nabble.com.
OpenSCAD mailing list
Discuss@lists.openscad.org
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
Ronaldo i am not 100% sure i understand you right, but i think this i
exactly what the current tool we are discussing is doing, it just skips
the extrusion step and processes the2D .svg of the projection directly.
then it writes out the support path data as an openscad vector text
file supportPathData.scad which one can then extrude to any height needed.
comprende?
Peter
On 12.03.2016 16:34, Ronaldo Persiano wrote:
I understand your point and agree that there is no way to do it
entirely in OpenSCAD without geometry query tools. However, it would
not be difficult to write a javascript code to process an OpenSCAD stl
file of the linear_extrude() of the part projection. This code would
generate a text file like this:
model=[
[[275,50,0], [275,100,0], [285,50,0]],
[[315,-50,0], [325,-50,0], [325,-100,0]],
[[315,50,0], [325,100,0], [325,50,0]],
[[315,50,0], [275,100,0], [325,100,0]],
[[285,-50,0], [285,50,0], [315,-50,0]],
[[315,-50,0], [285,50,0], [315,50,0]],
[[285,50,0], [275,100,0], [315,50,0]],
[[275,-100,0], [285,-50,0], [315,-50,0]],
[[275,-100,0], [275,-50,0], [285,-50,0]],
[[325,-100,0], [275,-100,0], [315,-50,0]]];
which could be inserted in a OpenSCAD code for further processing.
That approach doesn't avoid an external processing but the javascript
code could be valuable to any application demanding geometric queries.
And you may write then your support generation methods in OpenSCAD. :)
As a complement, would be nice also to have an OpenSCAD library to
answer geometric queries about models generated this way.
2016-03-12 11:15 GMT-03:00 pproj@posteo.de mailto:pproj@posteo.de
<pproj@posteo.de mailto:pproj@posteo.de>:
i think i have problems explaining what this javascript tool is
actually
about.
the starting point was a code in scad very similar to yours creating a
sine filled block.
but the tool does _not_ create a rectangular box filled with sinus.
cutting out a footprint of almost any model out of such block will
produce many discontinuities at the areas where the sinus wave is
cut by
the outline of footprint of the model. it will create many standalone
"islands" of fractures of a sinewave. this will slow down the print.
what the javascript tool realy does, and i think it is impossible in
openscad without querieng the geometry, it tries to create a
_continous_
sine or half-scircle wave in the footprint of the model, so that
you do
not have to cut out the footprint out of a sine block, and printer can
(ideally) print the whole layer of support without deccelerating
or idly
moving its head
Peter
On 12.03.2016 14:45, Parkinbot wrote:
The following code will create a box filled with cosine support.
CGAL
rendering is almost instantaneous.
Is it what you were asking for?
supportblock();
module supportblock(rows = 10, cols = 10, box = [100, 100, 10],
thickness
= .1)
{
amplitude = box[1]/rows/2;
wavelength = box[0]/cols PI;
linear_extrude(height = box[2])
for(i = [0:rows-1])
Ty(iamplitude*2)
polygon(points = sine(cols, amplitude, wavelength, i%2,
thickness));
}
function sine(periods, amplitude, wavelength, mode, thickness =
.01) =
let(amp = amplitude-thickness/1.9)
concat(
[for(i=[0:10:360periods]) [i/wavelength, ampcos(i+mode180)]],
[for(i=[360periods:-1:0]) [i/wavelength,
ampcos(i+mode180)+thickness]]);
Rudolf
--
View this message in context:
http://forum.openscad.org/semi-on-topic-print-speed-optimized-sinus-support-material-integration-interface-possible-tp16383p16438.html
Sent from the OpenSCAD mailing list archive at Nabble.com.
OpenSCAD mailing list
Discuss@lists.openscad.org mailto:Discuss@lists.openscad.org
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
_______________________________________________
OpenSCAD mailing list
Discuss@lists.openscad.org <mailto:Discuss@lists.openscad.org>
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
OpenSCAD mailing list
Discuss@lists.openscad.org
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
In my simple mind OpenScad is as simple tool for describing geometry, not
querying it. Slicers take geometry and produce tool paths. If you don't
like the tool path modify the slicer. Don't advocate making OpenScad more
more complicated. Make the slicer more sophisticated.
Support material doesn't need to be sinusoidal, but it could benefit from
rounded corners (as could all tool paths) because above a certain radius
the x and y accelerations are capable of turning the corner without slowing
down at all.
I must admit I do make support structures myself in Openscad but I export
them separately and slice them separately and combine the gcode with the
appropriate z offset. See
http://hydraraptor.blogspot.co.uk/2012/08/peel-able-support.html. Support
needs a solid interface layer less than a layer height below the object, so
you can't export it in the same file as the object and expect the slicer to
make it peelable.
One day I will write my own slicer to do this automatically.
On 12 March 2016 at 16:00, pproj@posteo.de pproj@posteo.de wrote:
Ronaldo i am not 100% sure i understand you right, but i think this i
exactly what the current tool we are discussing is doing, it just skips the
extrusion step and processes the2D .svg of the projection directly. then
it writes out the support path data as an openscad vector text file
supportPathData.scad which one can then extrude to any height needed.
comprende?
Peter
On 12.03.2016 16:34, Ronaldo Persiano wrote:
I understand your point and agree that there is no way to do it entirely
in OpenSCAD without geometry query tools. However, it would not be
difficult to write a javascript code to process an OpenSCAD stl file of the
linear_extrude() of the part projection. This code would generate a text
file like this:
model=[
[[275,50,0], [275,100,0], [285,50,0]],
[[315,-50,0], [325,-50,0], [325,-100,0]],
[[315,50,0], [325,100,0], [325,50,0]],
[[315,50,0], [275,100,0], [325,100,0]],
[[285,-50,0], [285,50,0], [315,-50,0]],
[[315,-50,0], [285,50,0], [315,50,0]],
[[285,50,0], [275,100,0], [315,50,0]],
[[275,-100,0], [285,-50,0], [315,-50,0]],
[[275,-100,0], [275,-50,0], [285,-50,0]],
[[325,-100,0], [275,-100,0], [315,-50,0]]];
which could be inserted in a OpenSCAD code for further processing.
That approach doesn't avoid an external processing but the javascript code
could be valuable to any application demanding geometric queries. And you
may write then your support generation methods in OpenSCAD. :)
As a complement, would be nice also to have an OpenSCAD library to answer
geometric queries about models generated this way.
2016-03-12 11:15 GMT-03:00 pproj@posteo.depproj@posteo.de <
pproj@posteo.de>:
i think i have problems explaining what this javascript tool is actually
about.
the starting point was a code in scad very similar to yours creating a
sine filled block.
but the tool does not create a rectangular box filled with sinus.
cutting out a footprint of almost any model out of such block will
produce many discontinuities at the areas where the sinus wave is cut by
the outline of footprint of the model. it will create many standalone
"islands" of fractures of a sinewave. this will slow down the print.
what the javascript tool realy does, and i think it is impossible in
openscad without querieng the geometry, it tries to create a continous
sine or half-scircle wave in the footprint of the model, so that you do
not have to cut out the footprint out of a sine block, and printer can
(ideally) print the whole layer of support without deccelerating or idly
moving its head
Peter
On 12.03.2016 14:45, Parkinbot wrote:
The following code will create a box filled with cosine support. CGAL
rendering is almost instantaneous.
Is it what you were asking for?
supportblock();
module supportblock(rows = 10, cols = 10, box = [100, 100, 10],
thickness
= .1)
{
amplitude = box[1]/rows/2;
wavelength = box[0]/cols PI;
linear_extrude(height = box[2])
for(i = [0:rows-1])
Ty(iamplitude*2)
polygon(points = sine(cols, amplitude, wavelength, i%2,
thickness));
}
function sine(periods, amplitude, wavelength, mode, thickness = .01) =
let(amp = amplitude-thickness/1.9)
concat(
[for(i=[0:10:360periods]) [i/wavelength, ampcos(i+mode180)]],
[for(i=[360periods:-1:0]) [i/wavelength,
ampcos(i+mode180)+thickness]]);
Rudolf
--
View this message in context:
http://forum.openscad.org/semi-on-topic-print-speed-optimized-sinus-support-material-integration-interface-possible-tp16383p16438.html
http://forum.openscad.org/semi-on-topic-print-speed-optimized-sinus-support-material-integration-interface-possible-tp16383p16438.html
Sent from the OpenSCAD mailing list archive at Nabble.com.
OpenSCAD mailing list
Discuss@lists.openscad.org
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
OpenSCAD mailing listDiscuss@lists.openscad.orghttp://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
OpenSCAD mailing list
Discuss@lists.openscad.org
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
@nophead That blog post is quite interesting, thanks.
This makes it clear why you need a special feature in the slicer to do user
defined peelable support. The support object would have to be imported as a
separate STL. Or, if we implement multiple colours/materials using a single
AMF file, as discussed in other threads, then the support object could be
included in the AMF file as a separate labeled object.
On 12 March 2016 at 20:06, nop head nop.head@gmail.com wrote:
In my simple mind OpenScad is as simple tool for describing geometry, not
querying it. Slicers take geometry and produce tool paths. If you don't
like the tool path modify the slicer. Don't advocate making OpenScad more
more complicated. Make the slicer more sophisticated.
Support material doesn't need to be sinusoidal, but it could benefit from
rounded corners (as could all tool paths) because above a certain radius
the x and y accelerations are capable of turning the corner without slowing
down at all.
I must admit I do make support structures myself in Openscad but I export
them separately and slice them separately and combine the gcode with the
appropriate z offset. See
http://hydraraptor.blogspot.co.uk/2012/08/peel-able-support.html. Support
needs a solid interface layer less than a layer height below the object, so
you can't export it in the same file as the object and expect the slicer to
make it peelable.
One day I will write my own slicer to do this automatically.
On 12 March 2016 at 16:00, pproj@posteo.de pproj@posteo.de wrote:
Ronaldo i am not 100% sure i understand you right, but i think this i
exactly what the current tool we are discussing is doing, it just skips the
extrusion step and processes the2D .svg of the projection directly. then
it writes out the support path data as an openscad vector text file
supportPathData.scad which one can then extrude to any height needed.
comprende?
Peter
On 12.03.2016 16:34, Ronaldo Persiano wrote:
I understand your point and agree that there is no way to do it entirely
in OpenSCAD without geometry query tools. However, it would not be
difficult to write a javascript code to process an OpenSCAD stl file of the
linear_extrude() of the part projection. This code would generate a text
file like this:
model=[
[[275,50,0], [275,100,0], [285,50,0]],
[[315,-50,0], [325,-50,0], [325,-100,0]],
[[315,50,0], [325,100,0], [325,50,0]],
[[315,50,0], [275,100,0], [325,100,0]],
[[285,-50,0], [285,50,0], [315,-50,0]],
[[315,-50,0], [285,50,0], [315,50,0]],
[[285,50,0], [275,100,0], [315,50,0]],
[[275,-100,0], [285,-50,0], [315,-50,0]],
[[275,-100,0], [275,-50,0], [285,-50,0]],
[[325,-100,0], [275,-100,0], [315,-50,0]]];
which could be inserted in a OpenSCAD code for further processing.
That approach doesn't avoid an external processing but the javascript
code could be valuable to any application demanding geometric queries. And
you may write then your support generation methods in OpenSCAD. :)
As a complement, would be nice also to have an OpenSCAD library to answer
geometric queries about models generated this way.
2016-03-12 11:15 GMT-03:00 pproj@posteo.depproj@posteo.de <
pproj@posteo.de>:
i think i have problems explaining what this javascript tool is actually
about.
the starting point was a code in scad very similar to yours creating a
sine filled block.
but the tool does not create a rectangular box filled with sinus.
cutting out a footprint of almost any model out of such block will
produce many discontinuities at the areas where the sinus wave is cut by
the outline of footprint of the model. it will create many standalone
"islands" of fractures of a sinewave. this will slow down the print.
what the javascript tool realy does, and i think it is impossible in
openscad without querieng the geometry, it tries to create a continous
sine or half-scircle wave in the footprint of the model, so that you do
not have to cut out the footprint out of a sine block, and printer can
(ideally) print the whole layer of support without deccelerating or idly
moving its head
Peter
On 12.03.2016 14:45, Parkinbot wrote:
The following code will create a box filled with cosine support. CGAL
rendering is almost instantaneous.
Is it what you were asking for?
supportblock();
module supportblock(rows = 10, cols = 10, box = [100, 100, 10],
thickness
= .1)
{
amplitude = box[1]/rows/2;
wavelength = box[0]/cols PI;
linear_extrude(height = box[2])
for(i = [0:rows-1])
Ty(iamplitude*2)
polygon(points = sine(cols, amplitude, wavelength, i%2,
thickness));
}
function sine(periods, amplitude, wavelength, mode, thickness = .01) =
let(amp = amplitude-thickness/1.9)
concat(
[for(i=[0:10:360periods]) [i/wavelength, ampcos(i+mode180)]],
[for(i=[360periods:-1:0]) [i/wavelength,
ampcos(i+mode180)+thickness]]);
Rudolf
--
View this message in context:
http://forum.openscad.org/semi-on-topic-print-speed-optimized-sinus-support-material-integration-interface-possible-tp16383p16438.html
http://forum.openscad.org/semi-on-topic-print-speed-optimized-sinus-support-material-integration-interface-possible-tp16383p16438.html
Sent from the OpenSCAD mailing list archive at Nabble.com.
OpenSCAD mailing list
Discuss@lists.openscad.org
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
OpenSCAD mailing listDiscuss@lists.openscad.orghttp://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
OpenSCAD mailing list
Discuss@lists.openscad.org
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
nophead wrote
In my simple mind OpenScad is as simple tool for describing geometry, not
querying it.
Beyond paradigm discussion and the fact that no function can operate over
geometry by now: By design of OpenSCAD there is also a severe technical
restriction to query geometry. CSG (F5) representation is rendered only
implicitly by OpenGL. Explict geometry (which may be queried) is only known
after CGAL rendering (F6).
But as already has been discussed in other threads there is no reason to NOT
offer a query on STL imports - at least from an implementation point of view
- which I hope will be coming with the next major release.
Rudolf
--
View this message in context: http://forum.openscad.org/semi-on-topic-print-speed-optimized-sinus-support-material-integration-interface-possible-tp16383p16458.html
Sent from the OpenSCAD mailing list archive at Nabble.com.
Yes getting info from imported geometry is useful and has no impact on the
declarative nature. It effectively becomes part of the description, another
form of source code. Similarly getting info from a polygon or polyhedron as
the mesh is available during preview.
On 13 March 2016 at 12:49, Parkinbot rudolf@parkinbot.com wrote:
nophead wrote
In my simple mind OpenScad is as simple tool for describing geometry, not
querying it.
Beyond paradigm discussion and the fact that no function can operate over
geometry by now: By design of OpenSCAD there is also a severe technical
restriction to query geometry. CSG (F5) representation is rendered only
implicitly by OpenGL. Explict geometry (which may be queried) is only known
after CGAL rendering (F6).
But as already has been discussed in other threads there is no reason to
NOT
offer a query on STL imports - at least from an implementation point of
view
- which I hope will be coming with the next major release.
Rudolf
--
View this message in context:
http://forum.openscad.org/semi-on-topic-print-speed-optimized-sinus-support-material-integration-interface-possible-tp16383p16458.html
Sent from the OpenSCAD mailing list archive at Nabble.com.
OpenSCAD mailing list
Discuss@lists.openscad.org
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org