nanoDLP

I tried to help my friend padaman for over a month now. I even bought another Pi 3 to test out and both Pi 3 have the exact same behavior. No matter the file size ... it always crash. Updating makes the printer unusable at. Control not working. Slicing doesn't work either.. I'm sure we're missing something here but what .. ?

here are some examples of the files we are trying to slice and makes Nanodlp crash...
Running version 0517 from 3dprinterswiki for the D7. Updating nanodlp is not an option as we never were able to manage to make it work with the D7. Unless someone can provide tutorial on how to make it work properly I will take any advice. 

https://drive.google.com/open?id=0B3DVy … nRWYXNHOHM
https://drive.google.com/open?id=0B3DVy … EV0OXRtVHM
https://drive.google.com/open?id=0B3DVy … lFwOFJCeVE

Will give that a shot. 
I have another question that comes to my mind regarding the D7. I saw/read that it is doable to use a RPI 3 with a stepper motter drv for direct control over Nanodlp. From what I understood it complety remove the need for any g-codes and thus, eliminate the need for RAMPS controller. Is this a true thing and that would explain why we run into so much trouble ?

Ok, even though we can'T seem to find any pattern in our troubleshoot since the very beginning the D7 came in. Do you have any advice to give on this page that could potentially pinpoint why we are having so much trouble with Nanodlp + Wanhao D7 ?

https://3dprinterwiki.info/d7/d7-nanodlp-settings-2/

All we do is burn the image nanodlp_0517, expand filesystem , upload machine settings and resin profile. This brings us to 2 issue.... random crash will slicing and updating is making the D7 unusable. Not sure if slicing is our main problem here or more of a config / g-code or plain misunderstanding on how the whole thing works.

Hmmm this is interesting. What should we conclude from there? Lower the resolution to 1080p and we should be fine?

No need to lower resolution. Just try to file bug issues with crashes. I do think it is a easily fixable issue which is not reported yet.

You are on very old version, please upgrade to latest version and see if the problem still persists.

Thank you, it looks legit. I have prepared special version to throw error could you try this version and share debug file after crash.
(wget https://www.nanodlp.com/nanodlp.debug.tar.gz --no-check-certificate -O - | tar -C /home/pi -xz);cd /home/pi/printer;sudo ./setup.sh

Hi, I tried updating with your command. I might be missing something so here's how I entered the command.
1 : wget https://www.nanodlp.com/nanodlp.debug.tar.gz --no-check-certificate -O - | tar -C /home/pi -xz
2 : cd /home/pi/printer
3 : sudo ./setup.sh

When I did that I saw the download and then NAnodlp never worked afterwards. Numerous reset haven'T change a thing.
I did found something interesting regarding the config.txt of the image we're using. gpu_mem was set to 192. I found a pretty neat ref guide for raspberry pi config.txt and found out I can put gpu_mem_512 to add more memory. So from the image on 3dprinterswiki I expanded filesystem after a clean flash of the image and then update to the latest version. Prior to all that I modified the memory to gpu_mem_512 in config.txt. Turns out an 875 layers slice was done without issue. I am still interested trying your image so if you can confirm my methodology is correct that would be nice from you

This is where I sourced the gpu_mem tweak : https://raw.githubusercontent.com/Evilp … config.txt

Since I modified this, I was able to slice files up to 12mb without crashing Nanodlp. NEaring completion of a voronoi style skull by the time I'm replying here.
487/576 layers completed so far. But I think gpu_mem is clearly the issue here. I saw there are few tweaks to do in the RPI config.txt like overclock and this one :

################################################################################
##  CMA - Dynamic Memory Split
##
##  CMA enables dynamic management of the ARM and GPU memory split at runtime.
##
##  The following options need to be in cmdline.txt for CMA to work:
##    coherent_pool=6M smsc95xx.turbo_mode=N

I'm no expert and maybe my finding is just a simple band-aid on the real issue but at least I got it working
What do u think ?

Well, that's the reason as to why I'm posting my interogations over here
As I said, I ain't an expert but since I changed the memory value in config.txt in boot folder of the RPI, all of my issues are now gone.
Add to that the fact that considering the way I use Nanodlp.... ( add plate, wait for it to complete and then print ) After that I only monitor and don't play with Nanodlp during print time.
I am a bit lost in translation understanding the relationship of the RPI config vs Nanodlp behavior.
I haven't tried yet a 50Mb file yet but will do soon.
I will update as well Nanodlp with your test version for sure because I failed initially to do it. For an unknown reason I was unable to start Nanodlp process (maybe my lack of knowledge with RPI bash is the cause of it) .