You are not logged in.
I do not use any browser cache clearing plugins or anything...just a stock Firefox on CentOS6 installation....I also tried Debian.
I am not sure what is going on...It seemed things were okay for a while...but I may never have closed the browser totally.
But today again when I went in fresh my supports were gone.
Why store things on the browser side (not sure but I think that is what you meant) and not on the Pi like the built in supports...seems like on the Pi would be the logical way
to do things..I do not use a browser login, I don't even always use the same browser or OS or computer...I use a similar system for my FDM printers and similar info is stored
on the cloud (not practical here for a free product) or on the Pi which acts as a server same as nanoDLP.
Maybe I need a complete reinstall? I have done many updates maybe something is just wrong with my installation but this has been an issue since day one with this install.
Another issue that seems to happen an may not be related is the updater often hangs..the system goes down but does not always reboot or restart...sometimes I can ssh in
and maybe reboot, but often it drops offline totally (presumably to reboot) and never comes back...power cycle is the only answer.
I have had this issue for some time.....
I typically use OS X sometimes Windows and was told that newly designed supports should remain from plate to plate.
However there might be some issues with my browsers or OS (I have tried every common browser I can find all have issues)
So I finally got Firefox working on a Linux box and I thought all my issues would go away and it looked for a while like that might
be true. Alas my problems have returned....I design a support and it might remain for a while but eventually it disappears when
I go back to use it.
Would it be possible to just get my support added to the standard support list? Other might find it useful too.
I don't know why my created ones should be any different but the standard ones the basic ones never vanish only the ones I make.
I call my support Needle...It is thin .7mm with a 3mm head cone tapering to .2 with .1 penetration. I keep the base
the same as the body and use the unify supports once they are all placed. The reason for this is that the bases obscure the
support placement....Also I find the stock supports a bit thicker and harder to remove than my needle support which work
well for the type of prints I make.
Thanks
Seems fine now.
Latest version...this is a model I have done previously but this plate has multiple copies....I have also changed profiles in that I turned on dimming this time to see if it could
prevent some parts of the model from over curing....Error seems happen just as the dimming process starts so I will try turning it off.
2017/06/17 17:57:12.982762 {"Layer":"1","module":"STL","level":"Notice","msg":"Extracting Layer 101 - Z Level -13.48915"}
panic: runtime error: integer divide by zero
goroutine 365 [running]:
projects/printer/app/renderer/dimming.DimmablePos(0x5a0, 0xa00, 0x1, 0x0, 0x1a4241d7, 0x14ec4000, 0xe10000, 0xe10000, 0x1, 0x443fb63a, ...)
/home/pi/go/src/projects/printer/app/renderer/dimming/dimming.go:52 +0x2f8
projects/printer/app/renderer/dimming.Dimming(0x5a0, 0xa00, 0x65, 0x1, 0x64, 0xffffb201, 0x6996ff, 0x14ec4000, 0xe10000, 0xe10000)
/home/pi/go/src/projects/printer/app/renderer/dimming/dimming.go:12 +0x11c
projects/printer/app/renderer.(*LayerDrawer).Render(0x10a33f00, 0x65, 0x1615ce00, 0x18, 0x0, 0x0, 0x0, 0x0, 0x5a0, 0xa00, ...)
/home/pi/go/src/projects/printer/app/renderer/render.go:132 +0x43c
projects/printer/app/format/stl.(*STL).renderLayer(0x10b48240, 0x1615ce00, 0x18, 0x65, 0xc157d38f, 0x15f8a000)
/home/pi/go/src/projects/printer/app/format/stl/stl.go:364 +0x6ec
projects/printer/app/format/stl.(*STL).renderLayers.func1(0x10b48240, 0x1615ce00, 0x18, 0x65, 0xc157d38f, 0x15f8a000)
/home/pi/go/src/projects/printer/app/format/stl/stl.go:813 +0x44
created by projects/printer/app/format/stl.(*STL).renderLayers
/home/pi/go/src/projects/printer/app/format/stl/stl.go:815 +0x1e8
pi@D7nanoDLP:~/printer $
I agree some sort of lift tap maybe on the corners or sides of the Unified Support Base you generate with the support system.
Alternately since I often use a large scrapper maybe one whole side of the unified support could have a step or ledge...
While I like how "add plate with support" now passes through the configuration dialog, I think probably choosing EXIT from the plate setup should probably not pass through this dialog but return to the Plate page directly...as you are not probably going to now add a plate...might be wrong here and you will instead add as if if you were just not using support but it seems odd to choose exit then forced to submit you could add an exit to the simple add plate which seems like it might be a good idea but clicking exit twice seems odd too.
well if you leave the infill off then it seems most any reasonable number would work I use Hex, 5, 4, 5, 80
This issue may have been corrected in the recent betas...at least t hasn't come up for me In the last day or so....
If you are thinking g something like the help popups I agree that would be good. However I think certain staticly displayed values would be good for "at a glance" type info. Right now I try to put that info in the name of the resin profile but that May not be correct as as the profile evolves. I think a combination approach. Certain obvious things like layer and cure time should always be there. Other details can be popped up on demand.
Thanks for the feedback, I am not sure how the lifting idea helps....If you plunge a model with an open cylinder (as created by infill) into a vat full of resin then expose it such that the tube is closed off by the current layer then the tube will be filled to the level of the resin in the vat...yes if it is thick resin or the vat level is low it might be less than full before the cap layer seals if off.
Because my printer doesn't yet have an auto resin level system I tend to want to fill the vat fairly high to prevent running low on resin and having gaps or incomplete prints.
I already actually lift my models quite high to allow fresh resin to mix in as this seems to help prevent over exposure on thin gaps near heavy exposures. I do this in conjunction with dimming which also helps with this same issue. Maybe I will try the formula you gave and see how things turn out I might be totally wrong on what is happening....I admit I haven't looked at the whole formula power of nanoDLP so could be I am not using the tool at it's full potential. I am not sure what this formula does or how to read it.....seems like it is trying to lift more based on Layer number?
The model where this came up was a big boxed cylinder type thing...so basically while it was mostly hollow with wide open infill, the last 15 mm of the cylinder ended up with resin trapped in the bottom as it was sealed off by the cap...now not normally a big problem (I could normally rotate the object while post curing to distribute the resin on the inside) however the resin sorta gelled in the bottom making the part heavy at that end once cured....which as it turned out was the near the top of the part making it kinda top and side heavy though it looked ok...printing it inverted would be the obvious solution but would probably have required more support structure and post finishing to hide the support points as they would have now been more obvious.
Again this is probably a future refinement not a must have feature...there are ways to minimize this with pre hollowed objects with include drain points etc....I just prefer to keep my models separated from the printing/casting/milling process such that the model can be used anywhere but is then processed for the specific production environment.
just curious...
In an LCD system how is this different from just turning off the light source?...does it actually power down the LCD is there a lag time to power it on before it can block the UV? They consume very little power is this worth it?
I gather this cuts the HDMI signal to the LCD....does that help on the Pi? like power down the video drivers?
Had this come up today....
A larger model that didn't need much internal structure thus had a wide spaced infill pattern.
But I wanted it to look good and generally be closed...but didn't want to capture a great deal of resin.
So I was thinking if the cap layers (in my case the last layers being printed) could have had smaller holes instead of no holes (current implementation) or open infill (as I mentioned in another post)
if it could have a smaller drain holes pattern centered on the infill...this would mostly close off the cap but leave places for resin to drain.
I think it could be accomplished by setting a min drain hole parameter and then over the course of the cap layers tapering or just changing from the infill grid size to the min drain hole size.
Really cool would be a harder but nicer finishing step that would find the Lowest point and place a drain hole there then under the cap layers create a gap (rather open like horizontal infill or just
infill columns that don't quite reach the cap layer on all six sides) that allows resin to drain from other infill columns to the low point and out the drain hole. This would allow a hollowed out model
with very few drain holes that still seems generally solid.
Issues would be with models that have the last layers with fine details or very uneven stepped last layers and figuring out where to place the drain holes...maybe the in supports layout there could be a method for
drilling holes at the various low points (easy to see with in that view with the slicing plate feature already there) and the user could then choose were to put the holes....assuming the interior would have
a gap on the other side of the cap layer as mentioned above.
I know this is may be not a high priority for most users but thought I would toss it out as a future feature
Thanks for all the effort that has already gone into NANODLP!!!
The same warning would probably be sufficient. Something like "Resin Profile has changed since Layer Creation" would be good for both profile alteration and completely different profile selection.
It really doesn't hurt too much to recreate layers if one is uncertain. Since changes like dimming, infill, layer height, and even color affect the layers these really need to be marked to notify the user.
However I agree other changes that do not affect the layers it is nice you can tweak them without recreation or even during a print.
Maybe there needs to simply be two categories of Resin Parameters...maybe color code them or separated them into different sections in the Resin Profile....One set that has no affect on layers and thus never
generates a warning and another set that does cause a warning message to be displayed...I'd almost say it should just remove the layers but I think a warning is good enough and some people might for some
reason want to keep the old layers until they manually recreate them...perhaps they accidentally tweaked a parameter and the warning would tip them off to go back and fix it but not force recreation.
I would like to see the plate details column contain some of the resin profile info...at least layer thickness and cure times...dimming and infill on or off might be nice too.
when editing a profile the infill parameters seem to be getting tested for valid values even when infill is turned off...
While this might be ok in theory it would be nice if at least the default values of zero would be accepted...or sensible defaults be the default.
It should be possible to set the Cap layers to Zero to leave one or both ends of the infill open.
I think really there needs to be a TopCap and a BottomCap....with different values....
It will depend on whether this is a topdown or bottom up printer how you want to use them.
I might want the first few layers to have a cap as it promotes better adhesion but leaving infill open all the way to the final layer will allow drainage.
Sometimes I might want to close both ends and post cure any trapped resin if my model needs to be closed.
Other times I might have good adhesion on the first layers even with the infill but need to close the last ones...presumably I could then drain once I remove from the platform.
And all that said the Current implementation seems to not totally follow the current cap layers count sometimes giving less that I specify.
Mark plate as invalid or generated with old profile if you use the edit button on the plate page and change the selected profile...It may work depending on how different the
old and new profiles were but I think it should warn you...usually of course you would immediately recreate after making such a change but still seems like a good idea.
hmmm rebooting the pi via ssh results in nano coming up but before I can delete a plate it crashes....and I can't tell from the log I posted which plate might be the offender...
would be nice if slicing didn't restart immediately after reboot maybe wait a minute or make restart of the slicing process a manual operation.....mark any half generated plates as invalid or something.
Though I would do a check for updates....I do not think anything was slicing at the time as it has been a day or so since
I worked with the printer....
Update kicked off but then the system crashed on reboot.
I ssh(ed) into the pi and kicked off the printer app again and got this (which looks to be a slice with infill in progress:
2017/06/06 22:13:30.913372 {"Layer":"1","module":"Hardware","level":"Notice","msg":"Initializing build # 1467 - generic"}
2017/06/06 22:13:30.915642 {"Layer":"1","module":"Terminal","level":"Notice","msg":"Terminal Reader Activated"}
⇛ http server started on :80
2017/06/06 22:13:31.043853 {"Layer":"1","module":"WIFI","level":"Warning","msg":"WIFI interface wlan0 detected"}
2017/06/06 22:13:31.186046 {"Layer":"1","module":"WIFI","level":"Warning","msg":"Connecting to Darren's Wifi"}
2017/06/06 22:13:31.828392 {"Layer":"1","module":"Terminal","level":"Notice","msg":"Received Data From RAMPS: start↵"}
2017/06/06 22:13:31.836177 {"Layer":"1","module":"Terminal","level":"Notice","msg":"Received Data From RAMPS: Detected EEPROM version:17↵"}
2017/06/06 22:13:31.836344 {"Layer":"1","module":"Terminal","level":"Notice","msg":"Received Data From RAMPS: Free RAM:4958↵"}
2017/06/06 22:13:31.836486 {"Layer":"1","module":"Terminal","level":"Notice","msg":"Received Data From RAMPS: SelectExtruder:0↵"}
2017/06/06 22:13:31.840180 {"Layer":"1","module":"Terminal","level":"Notice","msg":"Received Data From RAMPS: FlowMultiply:100↵"}
2017/06/06 22:13:35.923605 {"Layer":"1","module":"Terminal","level":"Notice","msg":"Received Data From RAMPS: ok 0↵"}
2017/06/06 22:13:40.916364 {"Layer":"1","module":"Infill","level":"Warning","msg":"Generating infill structure"}
2017/06/06 22:13:40.916403 {"Layer":"1","module":"STL","level":"Notice","msg":"Start Reading ASCII STL File"}
2017/06/06 22:13:40.993497 {"Layer":"1","module":"STL","level":"Notice","msg":"Analyzing STL file"}
2017/06/06 22:13:40.995398 {"Layer":"1","module":"STL","level":"Notice","msg":"Start Rendering Layers"}
2017/06/06 22:13:41.000248 {"Layer":"1","module":"STL","level":"Notice","msg":"Extracting Layer 1 - Z Level 0.008333334"}
2017/06/06 22:13:41.013148 {"Layer":"1","module":"STL","level":"Notice","msg":"Extracting Layer 2 - Z Level 0.058333334"}
2017/06/06 22:13:41.031011 {"Layer":"1","module":"STL","level":"Notice","msg":"Extracting Layer 3 - Z Level 0.108333334"}
2017/06/06 22:13:41.031100 {"Layer":"1","module":"STL","level":"Notice","msg":"Extracting Layer 4 - Z Level 0.15833333"}
2017/06/06 22:13:41.151702 {"Layer":"1","module":"STL","level":"Notice","msg":"Extracting Layer 5 - Z Level 0.20833333"}
2017/06/06 22:13:42.075870 {"Layer":"1","module":"STL","level":"Notice","msg":"Extracting Layer 6 - Z Level 0.25833333"}
2017/06/06 22:13:42.096502 {"Layer":"1","module":"STL","level":"Notice","msg":"Extracting Layer 7 - Z Level 0.30833334"}
2017/06/06 22:13:42.115718 {"Layer":"1","module":"STL","level":"Notice","msg":"Extracting Layer 8 - Z Level 0.35833335"}
2017/06/06 22:13:42.136994 {"Layer":"1","module":"STL","level":"Notice","msg":"Extracting Layer 9 - Z Level 0.40833336"}
2017/06/06 22:13:42.257664 {"Layer":"1","module":"STL","level":"Notice","msg":"Extracting Layer 10 - Z Level 0.45833337"}
2017/06/06 22:13:42.472938 {"Layer":"1","module":"Infill","level":"Warning","msg":"Infill structure generated"}
2017/06/06 22:13:43.054879 {"Layer":"1","module":"STL","level":"Notice","msg":"Extracting Layer 11 - Z Level 0.5083334"}
2017/06/06 22:13:43.177624 {"Layer":"1","module":"STL","level":"Notice","msg":"Extracting Layer 13 - Z Level 0.6083334"}
2017/06/06 22:13:43.197963 {"Layer":"1","module":"STL","level":"Notice","msg":"Extracting Layer 12 - Z Level 0.5583334"}
2017/06/06 22:13:43.238284 {"Layer":"1","module":"STL","level":"Notice","msg":"Extracting Layer 14 - Z Level 0.6583334"}
2017/06/06 22:13:43.258073 {"Layer":"1","module":"STL","level":"Notice","msg":"Extracting Layer 15 - Z Level 0.70833343"}
2017/06/06 22:13:44.134349 {"Layer":"1","module":"STL","level":"Notice","msg":"Extracting Layer 16 - Z Level 0.75833344"}
2017/06/06 22:13:44.292024 {"Layer":"1","module":"STL","level":"Notice","msg":"Extracting Layer 17 - Z Level 0.80833346"}
2017/06/06 22:13:44.344594 {"Layer":"1","module":"STL","level":"Notice","msg":"Extracting Layer 19 - Z Level 0.9083335"}
2017/06/06 22:13:44.365048 {"Layer":"1","module":"STL","level":"Notice","msg":"Extracting Layer 18 - Z Level 0.85833347"}
2017/06/06 22:13:44.382862 {"Layer":"1","module":"Infill","level":"Warning","msg":"Hatching layer 2"}
panic: runtime error: index out of range
goroutine 7 [running]:
projects/printer/app/renderer/infill.hatchingLayer(0x2, 0x2, 0x1, 0x10a14600, 0x78, 0x78, 0x384000, 0x10c94000, 0xe10000, 0xe10000)
/home/pi/go/src/projects/printer/app/renderer/infill/hatching.go:89 +0x150
projects/printer/app/renderer/infill.Process(0x5a0, 0xa00, 0x3e, 0x78, 0x1, 0xa, 0x28, 0x0, 0x0, 0x1, ...)
/home/pi/go/src/projects/printer/app/renderer/infill/hatching.go:50 +0x464
created by main.(*monitorStruct).run
/home/pi/printer/app/slice-monitor.go:121 +0x40c
okay got things going again....trying an actual print before bed.
tried that and rebooted...same story, no display...I notice that in the projector cal tab all the call patters seem to be too wide for the box they are in...I don't remember this being the case before but don't go here often...but I know a full white used to be easy to see on the printer but not anymore....hmmm...could this be related to overscan setting in raspi-config...I don't think that changes with the flash card .....
darn....I had this problem before when I started with nanoDLP...there is no image on the display....I solved this before my installing a prebuilt image but trying to avoid that now....I am guessing this has something to do with the type of printer I am using (LED lamp/lcd mask with RAMPS board) and the fact that it is somehow oddly oriented for nanoDLP. ... I may have reinstall the image then copy back the db directory...not sure what the guys that made the image did to get things working.
did the beta upgrade....seems to be back in business...I will give it a try...thanks for the assist.
okay it came back up and even the wifi is back....but on the std release not beta....should I try the beta upgrade again?
I am rebooting now to see what happens
okay....I had only done this from the image before but I see you have instructions for an already working pi...I will try that...I have backed up my ~/printer directory already...I don't want to loose my profiles if I can help it.