You are not logged in.
With halfstep and 5mm lead Screw i get a Real Hardware Resolution from 0.0125 mm which is cool for me printing with 0.025 layer. When i use dynamic lift and the Formula result is not a multiple of this real 0.0125 reproducable stepping resolution, the result per lift is wrong and get wronger on each lift about 0.0125mm because the stepper can hold on full and half steps. So on each 0.025 Layerheight there is a possibility from 50% to get the next Layerheight wrong by more then the half Layerheight.
So if get shahin right nanodlp handle this automaticaly internal and everything is ok.
If you're that worried about it check out the rebuild log I posted for my printer. I use a Nano Zero stepper controller from MisFit Tech, give me closed loop control and a guaranteed error of less than .3 degrees of rotation.
Good to know it get solved. Nanodlp is single binary program so upgrade process could not cause serious issues.
That's the theory I suppose, but I was lumping in the actual OS updates and such. I used the NanoDLP image downloaded fresh from the site and didn't apt-get update / dist-upgrade or anything. Just allowed NanoDLP to update itself then hand copied my settings over to avoid a potential issue in the generated files from my previous version.
It will takes couple of days to confirm the issue. But I have asked around, apparently no one with similar setup experience this issue. But I will test with your exact print profile too.
Well, this one may remain in the mystery pile. After swapping the RPi, new SD card, and fresh flash of NanoDLP the issue seems to have been resolved. I can only surmise that it's some kind of freak compounded upgrade bug.
Well, I've swapped in a brand new RPi3 and a brand new SD card with a 100% untouched NanoDLP image freshly downloaded from the site. Once it booted for the first time, I selected NanoDLP generic, rebooted, expanded the file system, rebooted, allowed the built in updater to upgrade to the beta, and I'm now trying a test print.
We'll see what happens.
Thank you, trying nanodlp printing and movement by direct control for few days. If I could not reproduce will switch to your settings and test again.
Any news?
Unfortunately wide range of issues from OS to the software and hardware issues could cause this kind of error message. So it is not helpful until I can reproduce the issue locally.
If it helps, I've been testing. It seems to fail fairly consistently around 350 layers. Once restarted it's again fairly consistent at ~300 USB layer intervals.
Unfortunately wide range of issues from OS to the software and hardware issues could cause this kind of error message. So it is not helpful until I can reproduce the issue locally.
Anything I can do to help? I can set my unit up for SSH for you, if need be.
I am not sure if it is the software issue, will stress test direct control modules to see if I could crash it or not.
Seems to be something similar to this issue.
Shahin wrote:I am not sure if it is the software issue, will stress test direct control modules to see if I could crash it or not.
Another crash log here, further along in the same print as the previous one.
Looks like printer.log is empty. Here's the relevant crash info -
2017/07/01 06:41:34.374173 {"Layer":"606","module":"Image","level":"Warning","msg":"Display layer public/plates/53/606.png"}
2017/07/01 06:42:09.844458 {"Layer":"607","module":"Image","level":"Warning","msg":"Display layer public/plates/53/607.png"}
2017/07/01 06:42:45.287105 {"Layer":"608","module":"Image","level":"Warning","msg":"Display layer public/plates/53/608.png"}
2017/07/01 06:43:20.623799 {"Layer":"609","module":"Image","level":"Warning","msg":"Display layer public/plates/53/609.png"}
2017/07/01 06:43:55.993994 {"Layer":"610","module":"Image","level":"Warning","msg":"Display layer public/plates/53/610.png"}
2017/07/01 06:44:31.503874 {"Layer":"611","module":"Image","level":"Warning","msg":"Display layer public/plates/53/611.png"}
2017/07/01 06:45:07.002906 {"Layer":"612","module":"Image","level":"Warning","msg":"Display layer public/plates/53/612.png"}
net.runtime_pollWait(0x740c0fa8, 0x72, 0x0)
net.(*conn).Read(0x10a0e050, 0x10ce2000, 0x1000, 0x1000, 0x0, 0x0, 0x0)
/usr/local/go/src/net/net.go:181 +0x58
net/http.(*connReader).Read(0x10de0120, 0x10ce2000, 0x1000, 0x1000, 0x248ff4, 0x10b7a640, 0xd0e9445e)
bufio.(*Reader).fill(0x10de0150)
/usr/local/go/src/bufio/bufio.go:97 +0xf4
bufio.(*Reader).Peek(0x10de0150, 0x4, 0xe, 0x29618357, 0x6c6f60, 0x0, 0x0)
/usr/local/go/src/bufio/bufio.go:129 +0x58
net/http.(*conn).serve(0x10a98780, 0x6a1c70, 0x10c40aa0)
/usr/local/go/src/net/http/server.go:1850 +0x7a0
created by net/http.(*Server).Serve
/usr/local/go/src/net/http/server.go:2668 +0x234
goroutine 4232 [IO wait]:
net.runtime_pollWait(0x740c1098, 0x72, 0x11431000)
/usr/local/go/src/runtime/netpoll.go:164 +0x44
net.(*pollDesc).wait(0x10ae7f3c, 0x72, 0x69f9f0, 0x69d798)
/usr/local/go/src/net/fd_poll_runtime.go:75 +0x28
net.(*pollDesc).waitRead(0x10ae7f3c, 0x11431000, 0x1000)
/usr/local/go/src/net/fd_poll_runtime.go:80 +0x24
net.(*netFD).Read(0x10ae7f00, 0x11431000, 0x1000, 0x1000, 0x0, 0x69f9f0, 0x69d798)
/usr/local/go/src/net/fd_unix.go:250 +0x148
net.(*conn).Read(0x10a0e948, 0x11431000, 0x1000, 0x1000, 0x0, 0x0, 0x0)
/usr/local/go/src/net/net.go:181 +0x58
net/http.(*connReader).Read(0x1141e360, 0x11431000, 0x1000, 0x1000, 0x248ff4, 0x10ae7f00, 0xd0e94472)
/usr/local/go/src/net/http/server.go:754 +0x168
bufio.(*Reader).fill(0x1141e390)
/usr/local/go/src/bufio/bufio.go:97 +0xf4
bufio.(*Reader).Peek(0x1141e390, 0x4, 0xe, 0x1cba5670, 0x6c6f60, 0x0, 0x0)
/usr/local/go/src/bufio/bufio.go:129 +0x58
net/http.(*conn).serve(0x10a988a0, 0x6a1c70, 0x10b87000)
/usr/local/go/src/net/http/server.go:1850 +0x7a0
created by net/http.(*Server).Serve
/usr/local/go/src/net/http/server.go:2668 +0x234
trap 0x0
error 0x0
oldmask 0x0
r0 0x0
r1 0x1544
r2 0x6
r3 0x0
r4 0x76df7094
r5 0x358ff460
r6 0x0
r7 0x10c
r8 0x1
r9 0x34
r10 0x11020960
fp 0x358fec04
ip 0x358ff920
sp 0x358fead0
lr 0x76ce6f44
pc 0x76ce6f70
cpsr 0x20000010
fault 0x0I am not sure if it is the software issue, will stress test direct control modules to see if I could crash it or not.
Another crash log here, further along in the same print as the previous one.
Sure for the terminated process you can run nanodlp.
Could you share another debug file after crash? If it is not hardware issue, main suspect is the pulse generator logic.
Of course. I just pulled it down and haven't even opened it yet myself. It's here.
Some loops are so tight doing anything inside them will cause serious slow down. As you are direct control user I suspect it is movement loop issue which we have tightest loop on nanodlp
The crash issue has persisted across several updates though. And I'm not using dynamic lift. I use dynamic cure, but it never fails on the parts that are actually dynamic (my dynamic cure formula plateaus after 20 layers or so and cures every layer past 20 for 25 seconds).
I suppose I can reboot, kill the NanoDLP process that is spawned on boot, and then start NanoDLP from the command line with "sudo /home/pi/printer/printer > ~/nanodlp-live-log.txt"
What is your suggestion for debugging this before I try that?
During crash all stack information being written to file called /var/log/printer.log .
Is there any difference between previous and current crashes?
Not sure yet. There doesn't appear to be anything being written to printer.log during operation. Is there a way to make NanoDLP log everything to a file in real time? My gut tells me the fastest way to track this down is to log everything in real time and pick over that log when it crashes, not wait for it to crash and trust it to log post-crash.
Shahin wrote:My guess is SD card.
Tracked it down. Shitty power supply. Replaced it with a beefier one. Problem disappeared.
I've spoken too soon. It looks like the NanoDLP process is crashing, not the actual RPi now. Happened about 350 layers into a print last night.
I was able to SSH into the printer though, and found there was no printer process running.
Is there a way to enable verbose logging in NanoDLP?
My guess is SD card.
Tracked it down. Shitty power supply. Replaced it with a beefier one. Problem disappeared.
Network could not have serious effects on NanoDLP. We need more data to troubleshoot this issue but considering you are only one reporting this serious issue, there is a high chance of hardware issue.
Fair enough. What are the most likely suspects?
It is the other-way around, it probably freezes and network connection drops.
Is there a way to verify? I've got AT&T aDSL, in a ritual area. It's the literal worst. Plus the router itself will glitch out like all the time.
New data. It seems as though NanoDLP does not handle network disconnection gracefully, though I can't tell for sure. Essentially, it looks like if the network connection drops, the printer freezes.
What's the intended behavior?
Very Odd, I use same build with similar config without any issue.
Do you remember which version was reliable before?
Do you experience this issue just after upgrade?
Just a Do you have extra SD card, RPi and Power Supply around to try?
Have you noticed any pattern? For example it fails every 300 layers or so.This time if it crashes check out process number indicator before restart, it could give us some clue.
How do I check the process number indicator?
How often it happens? Have you seen resource indicators before restart?
All the fricken' time really. Two may three times per print. It's aggravating as all hell. I didn't catch any indicators other than the temp before the last crash.
I can't pin down what's causing this crash. I'm on 1540 beta. I originally thought it was a temperature related crash, so I added a cooling fan to the RPi and it never broke 41 degrees celsius. Then I figured it might be a WiFi related issue, so I ran an ethernet hard line.
I can't figure what may be causing it. The debug zip is attached here.
Nice guide!
I would like to give Sollidray's patched firmware a try but I can't find it anywhere online.
Any leads?
It's on GitHub I believe. Shahin linked it in a few posts I think.
I have everything running now. I have done about ten dry runs to make sure the Z cal is ok, and it is right on. The only problem now is that the layer showing on the nanodlp site and on the screen on my printer is a solid line down the middle of the display. I have redone the sd card at least 15 times to try and get a proper display so it will print what I load. I have tried to load about 10 different STL files to the printer and every time it is not displaying the object I want to print, but a solid bar about 3/4 of an inch wide down the middle of the display. Any ideas?
Milt
Check the display settings in your config.txt.
I ended up changing the settings for mine to force the RPi to always output 1920x1080 at 60Hz. I set the color space and some other stuff too, but it guarantees that when the projector comes on, it's receiving a good signal from the RPi. That way, if there's a display issue, I can pretty much eliminate NanoDLP as the problem.
backXslash wrote:yangbo wrote:Currently,Nanodlp using top-down mode to build 3d model with projector on Top.
does nanodlp support bottom-up mode with UV light from bottom ?
thanks for your help.
I just completed my write up of my conversion from top-down to bottom-up.
It's here.
Thanks for sharing.
Which part need to change in Nanodlp's setup page to convert from top-down to bottom-up ?
my print platform will go to bottom when printing finished,this action will kill my LCD srceen(I am using 7' LCD + UV light position-fixed at bottom).
Is there some way to remove the last "go bottom" command in the printing process ?
thanks again.
I just reversed the setting for the direction pin on my stepper. If you can't do that, just swap the coil pairs.
Whatever you do, make sure your end stop is at the TOP of your axis, and just do a good z calibration by using the measure z-axis feature.
Currently,Nanodlp using top-down mode to build 3d model with projector on Top.
does nanodlp support bottom-up mode with UV light from bottom ?
thanks for your help.
I just completed my write up of my conversion from top-down to bottom-up.
It's here.