You are not logged in.
Pages: 1
I am trying to do a fairly wide thin hex infill on a part as I want it lite but still somewhat strong.
However I also want the perimeters like the outside walls and walls around holes to be somewhat thick for sanding and drilling.
I thought I understood how the parameters work (I have to say I think they could be improved and renamed)
but now after a few trials I think maybe I am confused.
I thought the infill worked like hollowing but with hexed infill.....
My assumption was that "outer wall" parameter would be the variable to adjust to get thicker perimeters.
However it seems to have no effect.
The perimeter wall thickness seems to just follow the "wall size" variable which I expected
to only affect the inner hex infill walls not the outer walls...similar to the wall gap which I use to increase the coarseness of the hex grid.
Am I confused...is this operating as expected? If so can I achieve my thin wide infill would some nice thick outer walls? Or maybe something is
not working correctly? I have two versions of nanoDLP but both seem to operate the same...so I think maybe I do not fully understand the parameters.
Thanks
Darren
Offline
Please, suggest better names for parameters.
Your assumptions are correct. And bug cause program ignore high outer wall. Will push update tomorrow.
Offline
"outer wall" is okay now that I know it is supposed to work as I thought but just didn't....though I might use "perimeter width or thickness" as that is what other slicers use.
"wall size" is too vague....maybe "infill wall thickness". The real issue is maybe how infill is specified....I would maybe go with a percentage but I do like having total control of both the wall thickness and open space
between walls, now that I understand how it is supposed to work....maybe call the other parameter "infill pattern size"
On a side note I use a linux machine for my remote slicer...it says there is an update available but has no builtin update I can find (actually it generally seems to be missing much of the interface I see on the Pi)
Is there an easy way to update to the latest development build....I got the latest from the download page but it is the same that I have installed..maybe I need to look at a Raspian distribution for my linux box but prefer not to change that.
Offline
nanodlp desktop version used by few people so it is not worth developing update mechanism. Will update desktop versions shortly.
By the way nanosupport has integrated slicer which slice and push it to nanodlp.
Offline
Okay thanks I will look for the nanodlp desktop version update .... I too only use it as a remote slicer so as long as I keep on top of it doing a download to update is not a big deal.
I do wish there was more update info available...like webpage or something that shows the latest release and beta versions and when they were posted, and maybe a bullet point list of changes.
It doesn't have to exhaustive just something to know when I have the latest and if a particular change might have been implemented.....I think I recall this was on the Pi version though
since I have started using a Phrozen printer I can't see that....I am considering giving up the Phrozen code and on printer control to use a real nanoDLP releases.
Oh and I have been playing with the Mac version of the nanosupport application but until auto support works I have to use another program for that purpose.
Look forward to not having to do that and just having a simple step or at least a single tool family to drive my printers.
I use Astrobox/Astroprint for the FDM machines...you might look at their model as a guide..they started with a pi box to drive a printer and have developed
it into a web based system that is pretty good ... They are also doing a mobil app and full computer application but I think the web method is the way to go...it is not dis-similar to how
nanoDLP has been implemented.
Thanks for all the work
Darren
Last edited by macdarren (2019-02-01 20:09:44)
Offline
Yes, please update the labels and help text for the hex infill pattern... it is not at all intuitive.
"Outer Wall" -> "Outer Wall Thickness" Help text: "Width in pixels for the outer surface wall of the model."
"Wall Size" -> "Infill Pattern Wall Size" Help text: "Width in pixels of the infill pattern walls, interior to model."
"Wall Gap" -> "Infill Pattern Cell Width" Help text: "Width in pixels of the infill cell pattern."
The overall help for infill should also note that the user should estimate the appropriate pixel widths for the settings above based on the resolution and physical size of their print bed and the physical dimensions they are targeting in the printed model. (different pixel widths correspond to different end thicknesses on different size/resolution of screens or projectors).
Also, it would be good to put a note in the overall help for infill explaining the delayed second pass processing of the infill and that it won't show up immediately in the slice view. At least until the UI for the plater is updated to report infill progress.
I had a heck of a time figuring out what these fields do, mostly because my pi drops off the network when I try to slice infill on beta builds and needs a hard reset, even with remote slicer available. (~2001). It slices ok on 2001 on Windows though.
Offline
Darren,
Thank you the suggestions, will try to improve our offerings. Unfortunately we do not have control over phrozen version and could not add changelog back to it. But we can add it to website so everybody could check.
Erik,
Names has been modified, thank you for the suggestions.
Offline
Thanks!
Slicing with hex infill works with a plain cube, but the hex infill seems to get confused on more complex geometry easily, and doesn't put the hex infill where it should; many areas that should be infill are solid, and it is inconsistent from layer to layer where it wants to put infill.
Even if I use meshmixer makesolid operation to clean up the model a bit, nanodlp still does a poor job of figuring out where to put the infill. For example, _GC_Street_sidewalks_partial_sideB_FINAL.stl from Thingiverse 3379996 (can't post links, but it's easy to find by number) is particularly bad when rotated 90 degrees for printing in the build volume of a wanhao D7 or similar.
Also, I can slice with infill on the Windows version of nanoDLP (build 2046), but my raspberry pi (build 2044) tends to crash and stop responding until I power cycle it shortly into starting slicing. It doesn't crash with normal, solid slicing. I'm using 25 micron layers, with 8 top/bottom cap layers, 15pp outer wall, 4pp pattern wall, and 60pp cell width.
Offline
Decrease 8 layers top/buttom caps see if it makes any difference.
Offline
sadly I got the same result with 8 as 10
Offline
Decreasing to 4 top/bottom caps does not make any difference on the infill generated being solid in the wrong places. It does however stop my raspberry pi from immediately crashing during an infill slice though (will see if it actually completes slicing in the morning). I would speculate that the crash is related to running out of memory, (as the help says it's more memory intensive) ? Top and bottom caps are pretty important. Need to be able to control the thickness of the model all around the outer shell... it wouldn't be strong enough (or even bridge the surface well) if you end up too thin on the top of the model for example.
What are the dependencies on looking ahead for these?
Can we change the algorithm to use less memory?
Should be able to do it inplace if you do 5 passes: 1)slice it for solid (no antialias) using black(empty) and white (solid), 2) process the images from bottom up, hollowing in green and marking the bottom cap in red (allowing both to be set in a RGB pixel to track both), 3) process from top down, marking the top cap in blue again preserving rgb values, 4)mark infill cell pattern in white over top of any pure green pixels, then 5) Bottom up collapse pure green pixels to black and any other nonwhite pixels to white, then antialias each layer if that is set. Printing could not start until step 5 starts completing layers (technically 4 could be combined at start of 5). The lookahead is tracked in pixels on disk in the image layers this way. Top and bottom cap need separate colors to track, to allow for some optimization of lookahead such as playing around with the values in rgb to indicate how many more layers need to be written for a topdown pixel column or bottomup pixel column, so you can lookahead/lookbehind only one layer up and down rather then all of them. In this way you could remove the memory constraint on top/bottom cap.
What is it doing now?
Erik
Offline
Please, retry the latest beta.
Offline
rev 2045 seems much improved....I do get errors while slicing in the log....and after the slice complete they seem to come up every 10 seconds.
Info 1 2019-02-26 15:05:18.202918 Logging Suppressing duplicate logs
Error 1 2019-02-26 15:05:08.20504 System High memory usage, force GC 859 762 40
Error 1 2019-02-26 15:04:58.202064 System High memory usage, force GC 859 762 40
Error 1 2019-02-26 15:04:48.201002 System High memory usage, force GC 859 762 40
Error 1 2019-02-26 15:04:38.206305 System High memory usage, force GC 859 762 41
Error 1 2019-02-26 15:04:28.20496 System High memory usage, force GC 859 762 25
Error 1 2019-02-26 15:04:18.20569 System High memory usage, force GC 859 762 26
Error 1 2019-02-26 15:04:08.202628 System High memory usage, force GC 859 762 26
Error 1 2019-02-26 15:03:58.204394 System High memory usage, force GC 859 762 27
Error 1 2019-02-26 15:03:48.201325 System High memory usage, force GC 859 762 27
Error 1 2019-02-26 15:03:38.20516 System High memory usage, force GC 859 762 28
also this is if I slice on the Pi....using the remote siicer nothing has changed but it is build 2046, and I haven't updated if there is a newer version.
Last edited by macdarren (2019-02-26 07:10:00)
Offline
Both must behave identical, update desktop version too, the last commit fixed the infill issue. I have plan to decrease infill memory usage.
Offline
I crash immediately when trying to slice the same model with hex infill (Thingiverse 3379996).
PS D:\3dprint\Tools\nanodlp.win64\nanodlp> .\nanodlp.exe
2019/02/26 00:05:20.690894 {"Layer":"0","module":"Hardware","level":"Notice","msg":"Initializing build # 2047 - generic"}
2019/02/26 00:05:20.691895 {"Layer":"0","module":"SLAVE","level":"Error","msg":"Serial port could not be activated The system cannot find the path specified."}
2019/02/26 00:05:20.692896 {"Layer":"0","module":"Terminal","level":"Notice","msg":"Terminal Reader Activated"}
⇨ http server started on [::]:8080
2019/02/26 00:05:44.168900 {"Layer":"0","module":"Plate","level":"Warning","msg":"Removing old layers"}
2019/02/26 00:05:44.194898 {"Layer":"0","module":"Slicer","level":"Notice","msg":"Start slicing plate 1"}
2019/02/26 00:05:44.197899 {"Layer":"0","module":"Slicer","level":"Warning","msg":"Local slicing has been started."}
2019/02/26 00:05:44.197899 {"Layer":"0","module":"Infill","level":"Warning","msg":"Generating infill structure"}
2019/02/26 00:05:44.197899 {"Layer":"0","module":"STL","level":"Notice","msg":"Parsing STL file"}
2019/02/26 00:05:44.198899 {"Layer":"0","module":"STL","level":"Notice","msg":"Start Reading ASCII STL File"}
2019/02/26 00:05:44.203900 {"Layer":"0","module":"Infill","level":"Warning","msg":"Infill structure generated"}
2019/02/26 00:05:45.274063 {"Layer":"0","module":"STL","level":"Notice","msg":"Finish Reading STL File"}
2019/02/26 00:05:45.274063 {"Layer":"0","module":"STL","level":"Notice","msg":"Analyzing 3D structures"}
2019/02/26 00:05:45.274063 {"Layer":"0","module":"STL","level":"Notice","msg":"Arrange triangles."}
2019/02/26 00:05:45.343065 {"Layer":"0","module":"STL","level":"Notice","msg":"Start removing duplicate triangles."}
2019/02/26 00:05:45.422065 {"Layer":"0","module":"STL","level":"Notice","msg":"Rendering Layers"}
2019/02/26 00:05:45.423067 {"Layer":"0","module":"STL","level":"Notice","msg":"Extracting Layer 8 - Z Level -34.08192"}
2019/02/26 00:05:45.423067 {"Layer":"0","module":"STL","level":"Notice","msg":"Extracting Layer 6 - Z Level -34.14192"}
2019/02/26 00:05:45.424071 {"Layer":"0","module":"STL","level":"Notice","msg":"Extracting Layer 5 - Z Level -34.171917"}
2019/02/26 00:05:45.423067 {"Layer":"0","module":"STL","level":"Notice","msg":"Extracting Layer 7 - Z Level -34.11192"}
2019/02/26 00:05:45.424071 {"Layer":"0","module":"STL","level":"Notice","msg":"Extracting Layer 4 - Z Level -34.201916"}
2019/02/26 00:05:45.427066 {"Layer":"0","module":"STL","level":"Notice","msg":"Extracting Layer 3 - Z Level -34.231915"}
2019/02/26 00:05:45.433074 {"Layer":"0","module":"STL","level":"Notice","msg":"Extracting Layer 2 - Z Level -34.261913"}
2019/02/26 00:05:45.433074 {"Layer":"0","module":"STL","level":"Notice","msg":"Extracting Layer 1 - Z Level -34.291912"}
panic: runtime error: index out of range
goroutine 113 [running]:
projects/printer/app/slicer/renderer.(*LayerDrawer).isHallowable(0xc0000c82c0, 0x7dae24, 0x10, 0xc001199eff, 0x438, 0x780, 0xc0000c8300)
/home/shahin/go/src/projects/printer/app/slicer/renderer/render.go:233 +0x128
projects/printer/app/slicer/renderer.(*LayerDrawer).transparentInside(0xc0000c82c0, 0xc000116102, 0x10)
/home/shahin/go/src/projects/printer/app/slicer/renderer/render.go:201 +0x166
projects/printer/app/slicer/renderer.(*LayerDrawer).Render(0xc0000c82c0, 0x8, 0xc001188460, 0x15, 0xc00002a200, 0x0, 0x0, 0x0, 0x780, 0x438, ...)
/home/shahin/go/src/projects/printer/app/slicer/renderer/render.go:166 +0x3bd
projects/printer/app/slicer/format/stl.(*STL).renderLayer.func1(0xc000284240, 0xc001188460, 0x15, 0x8, 0x777c20853e3, 0xdb9)
/home/shahin/go/src/projects/printer/app/slicer/format/stl/stl.go:173 +0x22c
created by projects/printer/app/slicer/format/stl.(*STL).renderLayer
/home/shahin/go/src/projects/printer/app/slicer/format/stl/stl.go:168 +0x14f
Offline
OK, I had wiped my nanodlp directory on the off chance that something got corrupted in the configuration, and forgot to re-set up the machine parameters (screen resolution, xy dimensions, etc. since I don't have the printer connected directly to my PC). Anyway, I got past that crash by setting 1440x2560 resolution and setting the xy resolution to 47.1 micron... Probably there is a bug in not checking something derived from the machine setup for validity; it doesn't crash with solid slicing.
Hex infill is now working for me. Now to do some prints with it and work out settings that make sense for my models. I typically like to print hollow models with 0.5 to 1 mm thickness outer walls. With 25 micron layers on my printer which has 47.1 micron xy resolution, I would need about 30 bottom/top layers to come out to roughly the same thickness as the other walls if I understand how it works correctly? Hopefully the memory reduction you have in mind will enable that.
This infill looks like it will give a lot better/more practical control over hollowing and infill than using meshmixer, and take a whole lot less messing around!
Thanks!
Offline
I have updated both my systems...the latest for LINUX appears to be 2047 while the RPi beta update appears to be 2045.
Both appear to slice the same....and both seem to work as expected.
A few points.....
First is there some technical limitation restricting the Top and Bottom thickness to 10 layers?
I would like to do 20 to achieve 1mm thickness all the way around my model with a .05 layer and .075 pixels....
While not that critical I think maybe these and other hollowing parameters be specified in mm and then calculated to the nearest pixel/layer rounding up.
put in a 1 and it generates enough layers or pixels to get 1 mm wall...put in .5 and it computes half as many....would save getting out the calculator, but not a big deal.
Next ... This has caught me a few times...I think if you edit the plate and change something like the Resin Profile it should give
a similar warning to the 'obsolete profile' warning....somethng like 'sliced with different profile plates may not match currently selected profile'
This comes up when changing between hollowed and not hollowed profiles but there is no warning and without looking at the plates you would not know.
I know the point is in theory you don't have to reslice just because of minor profile changes, but a warning would be nice especially if it could know that profile is different
in a way that would affect the plates....in that case maybe it just re-slices automatically...but if not at least a notification.
I am not sure when the estimated times get calculated....maybe that is some final pass after slicing but sometime it seems to be missing.
Also I think this came up before but the stats about resin use do not seem to change when shifting between hollow and solid....even after a re-slice.
Finally I haven't tried it but I think the advice that you can begin a print even though remote slicing is happening and is not complete might be misleading...certainly
you can not view the layers yet so I presume you could also not print them....I have found it always best to await slice completion before printing anyway....but if you
want it to remain possible to print while slicing I would suggest the message not come up until it is actually possible and/or an indicator that remote slicing is occurring which
I would like in any case....in fact I would like a switch on the plate screen to move between remote and local...but that is probably useful mostly for people testing things.
Thanks for all the effort that goes into NanoDLP...it just keeps getting better.....can't wait for NanoSupport to mature and link up..:)
Last edited by macdarren (2019-02-26 16:04:16)
Offline
Erik,
I have plan to decrease memory usage for infill to 64MB for 4K display with max 255 layer on each side.
Darren,
Thank you for tips.
It is difficult from transition point to modify options to mm as it will cause problem on existing resin profiles. Maybe we should take the bullet and broke all profiles.
For printing plates without waiting slicing get finished. It used to takes half hour to slice plate which right now takes around 3min. The pi hardware improved and slicer performance improved substantially. Even last month it got around 8% faster with 10% less memory usage.
So as personally used to start print without waiting for it get finished, there is control mechanism applied to nanodlp logic, which could pause printer until individual slice get ready for print.
About NanoSupport I would like to hear your opinion on it specially compare to other available solutions.
Offline
I am just getting into nanoSupport as it has started to do auto support, however on my mac it crashes so often that it is hard to do much, plus I found it a bit odd, not sure why but it seems like it wants to put my models under the bed.
I think that is the first most important thing I could not figure out....some sort of auto placement...it would be really good if I could click a models surface and have it place that flat on the bed.
Once I get placement going without crashes I will try to play more with the actual auto support.
I would not change the interchange format of profiles at this point....as you say it might be too late anyway and break things....instead maybe add a line where you can input mm and have it autofill the pixels and layers based on the pixel size and layer thickness....you could still edit pixels and layers if you like and just save that info in the profile as before?
Offline
Sure we can do that
Offline
Pages: 1