Slicing bigger than nozzle size for different printing technique #6076
Comments
|
Hello. It amazes me what various people use PrusaSlicer for :-) First of all, are you sure that your technique requires FDM path planning and that it cannot use the SLA slicing which essentially produces black-and-white PNGs? The whole FDM process is built for... well, FDM. Not that I knew much about laser-induced polymerization, but it clearly works differently. The errors are not something that can be simply dismissed. The algorithm assumes that the extrusion is always squished by the nozzle so it is wider than the nozzle, part of the material is pushed sideways and calculates the extrusion rate accordingly. This requires that the layer height is smaller than nozzle diameter and it is the part that would fail had the checks been removed. When you say that you can process an FDM gcode, what do you mean by that? Do you use the G1 E value for anything? Or is it just E>0, we lase, E<=0, we don't? In that case it might be possible to suppress the errors (in the code) and set some fixed extrusion rate instead of the calculation that will not work.
Neighboring lines must still touch each other, no? So extrusion width and overlaps should matter.
Layer height should be the the step in Z-direction, otherwise I don't get it. Thinking about it, can't you just tell slicer that the nozzle diameter is the XY dimension of your voxel, set the layer height small enough so slicer works and then only process every 5th layer or so? It would require setting top/bottom layers to higher value and probably other things too, but it might be a way. |
|
or you can just down scale the model in Z 10x in PrusaSlicer UI and up
scale the Z in your firmware.
čt 18. 2. 2021 v 17:55 odesílatel Lukáš Matěna <notifications@github.com>
napsal:
… Hello. It amazes me what various people use PrusaSlicer for :-)
First of all, are you sure that your technique requires FDM path planning
and that it cannot use the SLA slicing which essentially produces
black-and-white PNGs? The whole FDM process is built for... well, FDM. Not
that I knew much about laser-induced polymerization, but it clearly works
differently.
The errors are not something that can be simply dismissed. The algorithm
assumes that the extrusion is always squished by the nozzle so it is wider
than the nozzle, part of the material is pushed sideways and calculates the
extrusion rate accordingly. This requires that the layer height is smaller
than nozzle diameter and it is the part that would fail had the checks been
removed. When you say that you can process an FDM gcode, what do you mean
by that? Do you use the G1 E value for anything? Or is it just E>0, we
lase, E<=0, we don't? In that case it might be possible to suppress the
errors (in the code) and set some fixed extrusion rate instead of the
calculation that will not work.
Extrusion parameters, overlaps, brims and all the other parameters are not
important for us due to the different technique.
Neighboring lines must still touch each other, no? So extrusion width and
overlaps should matter.
We use the nozzle size as distance between two voxels in Z-direction.
Layer height should be the the step in Z-direction, otherwise I don't get
it.
Thinking about it, can't you just tell slicer that the nozzle diameter is
the XY dimension of your voxel, set the layer height small enough so slicer
works and then only process every 5th layer or so? It would require setting
top/bottom layers to higher value and probably other things too, but it
might be a way.
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
<#6076 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ABMPSI7LGZ52PB3XIYIA2ODS7VBAJANCNFSM4X2QHFAQ>
.
|
|
@lukasmatena They are really just using PrusaSlicer to control the laser. It is something that for example https://peopoly.net are doing. They wrote their own kind of SLA support generator http://wiki.peopoly.net/doku.php?id=moai:asura and then the generated geometry is processed by Cura to produce movements of the galvos controlling mirrors reflecting the laser. |
|
Thank you so much to both of you for your input. I will test your suggestions on our machine and come back if those didn't work. :)
You can imagine the process like going with a imaginery pinhead through honey. Everywhere where the pinhead was a solid structure is left. The honey is than washed away. That's why we need the FDM slicers.
That's how it currently works but I also have to talk to our machine partner to optimize it a bit as this feature is really new in our small community of people with these printers.
Sorry I meant overhang and yes extrusion parameters matter than.
Yes my fault, half the voxel height is our step size (layer height). That way we are sure our voxels overlap and we don't get a staircase effect.
That sounds like a super simple and easy solution. I will try that one directly 👍 |
|
Just an idea: you could cheat the diameter. Set it as 1/3 more than your height and that's all. Did I missed something? |
|
The proposed solution to shrink the model in Z in the slicer and to expand it in our printer again works like a charm. Thanks for your help! |
Version
PrusaSlicer 2.3
Operating system type + version
Any
3D printer brand / version + firmware version (if known)
Femtika Laser Nanofactory
Behavior
Hi PrusaSlicer maintainers,
I am a researcher from Germany and I need your help. We are working with a two photon polymerization printer, which is very precise (resolution ~200 Nanometer). In short we polymerize material in the focal spot of a laser. This spot we call voxel is comparable to a printer nozzle. Imagine it like a needle head moving in a drop of honey. Every point where the needle head was is solid afterwards and the honey can be washed away. That way we get a 3D model.
So we run our printer with a similar software that also slices STL files. Unfortunately it is not as powerful as FDM printer slicers like PrusaSlicer. But we can use externally sliced gcode (in short where a FDM printer extrudes we polymerize with our laser). Currently we can slice code with the PrusaSlicer and print it. We just simply scale everyting by 1/1000. Unfortunately our voxel looks a bit different to the printer nozzle geometry. See the following image, where the black line is our voxel (polymerized volume - like a printed line) and the image is a cut through in XZ direction. So in Z our printed volume can be 5x bigger than in XY direction.
Our voxel is much longer in Z than the line one would print with a nozzle.
And here is my question:
The PrusaSlicer is giving us errors if we use slices bigger than the nozzle size and no output in form of gcode is given. We use the nozzle size as distance between two voxels in Z-direction.
Is there a way to ignore most of the errors? Command line or something else?
Are there any hidden or non-obvious parameters we could change to just get a toolpath?
We only care about the general slicing and infill parameters. Extrusion parameters, overlaps, brims and all the other parameters are not important for us due to the different technique.
Our next step, if there is no easy solution, would be to fork PrusaSlicer and try to make a version for our printing process but this involves a lot of work and time.
We also printed a Benchy (12µm long) and the octopus to see if his arms would move (they do!).
Thanks for your help!
Is this a new feature request? Yes
The text was updated successfully, but these errors were encountered: