You are not logged in.
Pages: 1
I can't get NanoDLP to print ANYTHING past about 100 layers. It's crashing, seemingly consistently, at 113 layers.
I've uploaded the debug zip to DropBox here.
Does anyone have any ideas?
Shahin?
Offline
Unfortunately, debug indicates serious issue within program. Memory corruption terminate the program.
My guess is it could be hardware or file issue on your rpi before nanodlp itself as you constantly experience same issue in early layers.
Have you tried different plate?
Does rpi's red led blink during printing?
Could you provide screenshot of nanodlp dashboard after crash?
Offline
The RPi freezes totally, and doesn't respond at all to anything other than a reset.
The debug log is all I can get, and then only after a reboot.
Offline
Unfortunately, debug indicates serious issue within program. Memory corruption terminate the program.
My guess is it could be hardware or file issue on your rpi before nanodlp itself as you constantly experience same issue in early layers.Have you tried different plate?
Does rpi's red led blink during printing?Could you provide screenshot of nanodlp dashboard after crash?
I've tried several plates, and each plate fails at a different point, but they all fail. I haven't checked the LED, but the unit is completely unresponsive to anything until I reboot it by pulling the power plug and plugging it back in.
I've got a brand new, unopened RPi. I can try a completely fresh, untouched install with a brand new SD card. My thought is that there's a glitch in the graphics subsystem or something. It seems to have appeared only with the latest build(s).
What, exactly, are you seeing in the logs? I'm not seeing much to indicate what CAUSED the problem, just the notification that there IS a problem.
Offline
Based on log file content, problem happens during wait for RAMPS board. So program crashed before or after image display, virtually doing nothing, so it could not do anything with graphic subsystem.
I did not know that rpi itself freezes, in such cases usually program's log files are useless as errors could be random. There is no indication of freeze on syslog itself which usually indicate hardware or power issue.
Power (RED) LED should be on constantly, any blinking indicates power supply problem.
Troubleshooting kind of problem is hard and time consuming, if red LED is stable and you can rule out power issue. Keep rpi on for couple of hours to see if it also crash when it is idle or not. If not crashed, disconnect RAMPS, remove [[WaitForDoneMessage]] and print couple of plates, to see if it works without problem.
Offline
My setup is VERY simple.
I'm using an arduino nano running GRBL 0.9j with the solidray patches and a few of my own that help with the Z-axis homing.
The arduino and easystep driver 4.4 are hooked up to a powered USB hub, so they don't draw off the RPi and create power problems.
The only thing I'm thinking COULD cause a power problem is the HDMI to VGA converter I'm using, but if that was the case, why does it only happen after 100+ layers?
The RPi is powered with its own 3A micro-USB power supply. Nothing else pulls power from the RPi.
Offline
I am not sure about HDMI to VGA power consumption. But there are reasons to investigate it further.
https://www.raspberrypi.org/forums/view … =28&t=9819
Could you try printing same plate with hdmi disconnected?
I have load your config files locally, could not reproduce problem.
I have not seen the plate which you are trying to print. But if after 100 layers, model gets more complex, it could increase rpi's power consumption.
Offline
Ok, I've completely removed anything that COULD have caused a problem.
The Arduino Nano, EasyStepper v4.4, and HDMI-to-VGA converter are all powered off a powered USB hub. Nothing, at all, draws power from the RPi.
I also went ahead and replaced the RPi itself with a brand new one, and the 64GB SD card with a brand new one.
I'll get to the print stage at some point, but I've noticed a few other oddities. Essentially, NanoDLP isn't displaying anything correctly.
I knew there was bound to be an issue with the HDMI converter when it came to overscan, so I installed Raspbian and this script. I spent WAY too long getting the exact correct overscan settings, and right now everything is correct, you can even see that it is at boot time. However, once NanoDLP is running, it's basically ignoring the overscan settings.
I remade a calibration plate here as NanoDLP's built in ones are at 1920 x 1080 and I need them at 1024 x 768. When it's displayed it's cut off exactly the same way as if the overscan settings are commented out.
More than that, the settings for the XY resolution aren't working correctly either. My displayed area is 50mm x 37.5mm, which means my XY resolution is 48.83 microns. When generating calibration plates, it's just 100% not correct at all. A 20mm x 20mm cube measures out at 35mm x 35mm. When I change the resolution to 60+ microns, it DOES come out, at least closer to what it's supposed to be. I'm THINKING if I can figure out how to get NanoDLP to respect the overscan, it wouldn't be an issue.
Any ideas?
Offline
Can I assume the crash problem has been solved?
Projector calibration images have fixed fullhd resolution. Other than that we do not have any hard coded fullhd resolution in the program.
The script which you have found write to /boot/config.txt, it is something nanodlp or any other program could not ignore.
Do you install nanodlp after running the script? because nanodlp could overwrite config.txt file.
Offline
I installed Raspbian specifically to find the correct overscan settings. When I went back to NanoDLP, I used a brand new SD card and installed the nanodlp.img directly from the download link using ApplePiBaker for OS X.
NanoDLP wasn't installed by script, or dirty flashed, specifically to avoid issues. The ONLY thing I did between flashing the card and booting the Pi was to edit config.txt using the command line editor nano to change the HDMI settings.
I'll post the config.txt here shortly.
Last edited by backXslash (2016-04-23 13:39:51)
Offline
Can I assume the crash problem has been solved?
No idea about the crashing problem yet. Needed to solve the calibration problem first, honestly. My build volume isn't big enough to let me ignore it.
I've found that even though my resolution is 1024 x 768, and my XY resolution is 48.83 microns, if I set the resolution to 1024 x 550 and the XY resolution to 60 microns, everything I print comes out exactly correct dimensionally. However, even though 20mm x 20mm is correctly DISPLAYED at 20mm x 20mm on the print plate, the objects are not displayed in the correct PLACE. By that I mean even though the object is the right size, it's placed very far to the lower right of the screen.
This supports my assertion that NanoDLP isn't respecting the overscan settings somehow.
Something funny is going on, I don't know what, and I don't even know how to start tracking it down, but I'm game to try literally anything you tell me to.
Offline
I wiped the entire SD card, installed a 100% fresh copy of NanoDLP, logged in via SSH, ran your update command from the other thread, and am not running build 1144.
1) It's STILL not displaying right.
2) It's also got the words " [ OK ] Started LSB: Start NTP Daemon " stuck on the screen permanently, at all times, unless I tell it to display something else.
Ideas?
Offline
Ok, after careful matching with new images, and nearly blinding myself, I've figured out what it's ACTUALLY displaying. It appears to ACTUALLY be displaying 800 x 600.
Uhhh... why, WHY is it doing that?!
Offline
Good news, I figured it out.
Bad news, it's the counterfeit DMD chip in my projector. The projector is SUPPOSED to be 1024 x 768. The DMD chip it has is (obviously) 800 x 600.
So... that. Gonna murder the vendor that sold it to me, and... that solves that I suppose.
On to the freezing issue!
____________________________
The above is all lies. While I've got a sneaking suspicion that the DMD chip IS counterfeit, even setting everything to 800 x 600 and regenerating calibration images at that resolution STILL doesn't fix ANYTHING. The calibration images are STILL displayed completely out of whack.
Shahin, what the hell man?
____________________________
Ok, I changed the setup to define the projector as 800 x 600. Then I changed the printer profile to define the xy resolution as 75 microns. I then generated a calibration plate at 20mm x 20mm. The resulting square IS 20mm x 20mm.
That said, NONE of those settings are correct, they shouldn't work AT ALL. Again, Shahin, what the hell man?
Last edited by backXslash (2016-04-24 03:12:50)
Offline
Calibration images has fixed resolution of 1920x1080 as mentioned above, so do not expect to see it completely for anything below fullhd. (even on calibration image itself 1920x1080 has been written)
You can replace calibration images by putting your own ones here /home/pi/printer/public/general
Offline
I DID replace the calibration images with custom ones. That didn't work. I even tried copying the built in images, scaling them to 1024 x 768 and 800 x 600 and neither one works. They display exactly the same.
Do you mean that all calibration functions are hard coded at 1920 x 1080? If that's the case... can we fix that?
How is NanoDLP intended to be calibrated? Did you not take in to account non-HD projectors? Where / which are the config files I'd need to change to get things working at 1024 x 768? Why is NanoDLP acting like it's straight up ignoring the overscan settings?
Offline
You mean even with 800x600 image, a part of image being displayed? If it is the case, resolution still is not correct. What below command reports?
tvservice --statusOnly calibration images are hardcoded, adding support for other resolution require onfly calibration image generation. I have it on my task list but I am not sure when it will implemented.
Based on data available on online dashboard, under 5% of nanodlp users are using anything other than fullhd. And many of them are using 2K and 4K resolution.
You need to set correct resolution on setup page. But it would not effect calibration images.
If you want to do calibration, as Adam has been suggested on another post, majority of users are printing cube form and measure it to enter correct print resolution.
Calibration images mostly used to check focus for bottom up printers. Which partial image is also fine for that job.
nanodlp could not ignore or bypass any settings on config.txt file including overscan settings. Currently it does not even check resolution and display settings let alone controlling that directly. It just decode a layer and write it to memory pass the pointer to GPU firmware and nothing else.
Offline
Well, I gave up trying to solve the actual problem, and instead focused on resolving the symptoms instead.
I let the RPi boot up with no overscan, and no forced HDMI mode. The Pi seems to think it's displaying at 1920 x 1080, so... OK I guess. I just fiddled with the numbers until everything worked.
My process was this:
1) Set my digital calipers to 30mm on the nose, and lock them in place
2) Go to the "Setup" tab and change the projector resolution to 1920 x 1080
3) Go to the "Plates" tab and select my printer profile as the active one, set the "Plate Depth", "Width" and "Height" to 30mm. Also set the "Pillar Width", "Pillar Shear", and "Extend Pillars' Base Layers" to 0, and use 60 as the only value in the box marked "Comma Separated Cure Times". Once all of that is set, click "Generate"
4) Back in the "Plates" tab, click "Print Calibration Plate"
5) Once the image is displayed on the build platform, measure it with my calipers. If the image displayed is square, and all the corners meet the tips of the calipers correctly, I'm done. If not, go to step 6
6) If the displayed image is not of the correct dimension, go to the "Printer Profiles" tab and change the "X/Y Resolution" value (Not sure if it's correct, but a smaller value seems to create a larger square, a larger value creates a smaller one)
7) Save the new setting, then start this whole process over again from step 3
NanoDLP SEEMS to think that my X/Y Resolution is 44 microns, and that my display is 1920 x 1080. None of that is true, I don't think. I think my ACTUAL X/Y Resolution is more like 55 microns, and my display is 1024 x 768, but hey, if it works it works I guess.
MY next step is going to be tuning my G-Code so that the print works correctly. Then I'll re-try some test prints.
Offline
I would like to blend into the discussion, because I'm experiencing a similar problem,
I made 2 test prints with the projector off (acer p1500, 1920x1080),
one with 280 leyer, the second in 1800 leyer, rpb (pi 3) worked fine without crashing;
with the projector turned on, about every 200 leyer It happens a block, so in my case, it is not the breadboard prototype, as I thought, but rather, something that has to do with the HDMI connection ...
Offline
It could be the power supply 5v 2000 ma is not powerful enough?
Offline
It could be the power supply 5v 2000 ma is not powerful enough?
Near as I could tell, my issue was a power issue, AND a software bug. The software bug has been fixed I think.
I solved the power supply issue by running everything off seperate supplies. The RPi has its own dedicated 5v 3a supply. My EasyStepper has its own 5.35v 3a supply. Everything else is plugged into a powered USB hub, which has its own 3.5a supply.
Nothing pulls power off the RPi itself. After I did that, and updated NanoDLP, the freezing seems to have disappeared.
Offline
Thank you so much backXslash,
I will do the same
Offline
Pages: 1