You are not logged in.
It's mostly done here: http://sitecake.com/
Really, that library + a little data formatting a clever use of a json or something ought to do it I think.
If the sitecake interface can be set up to essentially generate a json file for the printer profile, I guess it's just a matter of parsing that file to inform NanoDLP of the G-Code it actually needs to use.
Do you have any suggest to make interface clear?
Kinda, actually.
What helped me was breaking the print process down in its constituent parts, then putting it back together like legos. I think some kind of if-this-then-that style interface where users can snap their build process together like legos might be more useful.
As a for instance, my printer is top down, and HELLA simple. I need to display the current layer, dip 6mm, wait 2 seconds, send the platform to the correct height for the next layer, wait 6 seconds, display the current layer.
The "snap" process might look something like START > [Action Block] > [Action Block] > ... > [Action Block] > END with each action block containing its own modifiable parameters rather than having them separate from the G-Code text boxes.
Example:
START > [Display Layer] > [Wait (X) Seconds] > [Move Z Axis (Up | Down) By (X) mm OR Move To (Current | Next) Layer] > [Wait (X) Seconds] > [Move Z Axis (Up | Down) By (X) mm OR Move To (Current | Next) Layer] > [Loop Till Done]
The Printer Profile tab would then be switched to a flowchart style interface with a "toolbox" of sorts containing the 6 or so unique "blocks", drag and drop as needed, each block contains its own modifier settings.
Should be universally understandable and easy to use for novice and expert users alike.
So the built in NanoDLP G-Code guide is ok, but I had to spend a TON of time figuring out how the interface actually works. My printer is a VERY simple clone of the Chimera printer on Instructables. The set up is GRBL 0.9j with the SolidRay patches running on a chinese Arduino Nano clone and an EasyStepper v4.4 driver driving the carriage from a PlayStation 3 Blu-Ray drive. My build platform is perfboard, my vat is a glass cup.
To save others the trouble, this is a quick run through of what worked for me. I've tried to annotate the G-Code as much as possible, so each function is clear. I'm happy to clarify if anyone needs it.
**G-Code - Bootup :**
None
**G-Code - Start Of Print:**
$X ; Unlock GRBL in case we're in an alarm state
G90 ; Put GRBL in absolute mode
$H ; Home GRBL so we can start from a known place
G4 P0.1 ; SolidRay movement sync
[[WaitForDoneMessage]] ; Wait done message
G92 X0 Y0 Z0 ; Set our new homed position as the origin
[[PositionSet 0]] ; Set the current position as 0 in NanoDLP
**G-Code - Before Each Layer:**
G01 Z[[LayerPosition]] F100 ; Move to the correct layer height
G4 P0.1 ; SolidRay movement sync
[[WaitForDoneMessage]] ; Wait done message
[[PositionSet [[LayerPosition]]]] ; Save the current position in NanoDLP
**G-Code - After Each Layer:**
[[Delay 1]] ; Wait 1 second for the resin to “settle”
G01 Z{[[LayerPosition]] + [[ZLiftDistance]]} F100 ; Dip the platform by the lift distance
G4 P0.1 ; SolidRay movement sync
[[WaitForDoneMessage]] ; Wait done message
[[Delay 3]] ; Wait 3 seconds for the resin to settle and air bubbles to pass
[[PositionChange [[ZLiftDistance]]]] ; Again update position
**G-Code - End Of Print:**
$X ; Unlock GRBL just in case
G01 Z0 F100 ; Bring the platform above the resin level
**G-Code - Resume Print:**
$X ; Unlock GRBL in case we're in an alarm state
G90 ; Put positioning in absolute mode
G92 Z[[CurrentPosition]] Y0 X0 ; System crashed so we need to recover current position from NanoDLP and set it in GRBL
G1 Z[[LayerPosition]] F100; Move to layer position
G4 P0.1 ; SolidRay movement sync
[[WaitForDoneMessage]] ; Wait done message
---------------------------------------------------------------
Because my set up is so simple, the build platform is attached to the drive sled with a rare earth magnet, it's leveled by bending its attachment post. The resin is poured to be just barely BELOW the homed position of the build platform, and all of my models include a "raft" like structure at their base so that even if the printer "misses" a few layers it'll still start with a non-critical part. To start a print, I manually push the build platform to near the bottom of the resin tank. This is because the G-Code is going to home the platform anyway, and it ensures that there's a very thin layer of resin on the platform. Because the platform starts technically above the resin level the final end of print G-Code returns the platform to 0 and the printed piece rises from the resin, ready for post curing.
I've had a number of excellent prints with this current set up, my only issues are 100% software based. I still need to tweak the cure time, as well as the amount of time to let the resin settle. I'll post pictures of some prints, as well as the castings they'll be turned into soon.
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.
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?
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?
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?!
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?
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.
Mike,
Before changing OS, do you have time to checkout patched version?
If he doesn't I will. That was my thread you linked to up there.
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.
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?
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.
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.
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.
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?
I built a VERY simple top down DLP.
NanoDLP is actually running it like a champ, but my GCode for the actual printing is utter shite. Here are the specs:
Mitsubishi XD221U projector with color wheel relocated, UV filter removed, and 3mm spacer added to optics to shorten throw
GRBL 0.9j w/ SolidRay and a few of my own patches to help with NanoDLP stuff running on an Arduino Nano
EasyStepper 4.4 driver board
BluRay drive carriage from a Sony PlayStation 3 for the Z axis
Glass cup filled with resin for the vat
The printer itself is an even more barebones iteration of the Chimera from Instructables. I couldn't figure out how to get everything working correctly in absolute mode, so I just did this instead:
Start Of Print:
$X ; Unlock GRBL just in case
G91 ; Put positioning in relative mode
$H ; Home GRBL
G4 P0.1; SolidRay movement sync
[[WaitForDoneMessage]] ; Wait until movement completed
After Each Layer:
G91 ; Put positioning in relative mode just in case
G1 Z-5 F100; Sink to dip position
G4 P0.1; SolidRay movement sync
[[WaitForDoneMessage]] ; Wait for the movement finished
G4 P2 ; Wait for 2 seconds to ensure the resin has coated the print
[[WaitForDoneMessage]] ; Wait for the movement finished
G1 Z4.95 ; Raise the platform 0.05mm lower than the last exposure
G4 P0.1; SolidRay movement sync
[[WaitForDoneMessage]] ; Wait for the movement finished
G4 P7 ; Wait for resin to settle
[[WaitForDoneMessage]] ; Wait for the movement finished
End Of Print:
$X ; Unlock GRBL just in case we hit the bottom endstop
G01 Z+1 F100 ; Move away from the end stop so GRBL doesn't freak out
$H ; Home the Z axis to bring the print up out of the resin
G4 P0.1; SolidRay movement sync
[[WaitForDoneMessage]] ; Wait until movement completed
Basically, before starting a print, I home GRBL to set a repeatable start level and "level" the resin in the cup with the build plate by adding or removing resin. Then I open the terminal and sink the platform 15mm into the resin, this ensures there's definitely resin on the platform. Once the print starts, NanoDLP will unlock and home GRBL to return it to the resin surface. The layer is then exposed according to the configuration settings. Once the exposure is done, the platform is sunk 5mm below the resin level, and held there for 2 seconds. After that, the platform is raised to 0.05mm lower than it previously was, and held there for 7 seconds to let the resin settle. Then the next layer is exposed, wash, rinse, repeat.
I KNOW this is shitty GCode, but it DOES work. I'd much rather have it setup correctly, with absolute positioning and fallbacks in case of failure, but I honestly just couldn't wrap my head around it.
Can anyone help?
