nanoDLP

Sorry Shahin, I am not sure what you are asking for. The USB serial port address that I have connected to the projector? If so, I am using /dev/ttyUSB0

I think I have figured out the cause, although not a solution. My Acer 6510BD projector seems to be the culprit. When I unplug the serial cable to the projector these errors go away. When I hard reboot the projector the errors also go away for a while, but eventually return. I have tried every combination of baud rate, parity, stop bits, etc. and nothing seems to fix the error message, although the serial controls still seem to work.

Sorry for the delay in getting back to you. I got the M codes from the muve3D installation guide.

Shutter open:
M280 P2 S160
Shutter closed:
M280 P2 S10

The values control the angle, so you will need to test them to get the correct angles for open and closed.

No, you can use as large a pixel size as you want, although the cure time will change. However, you need to scale up your vat to accommodate a larger pixel size (and hence a larger projected size), so there is a practical limit to how large a pixel size you would want to use.

As far as I know there is no single list. What you are looking for is a projector that projects the correct bandwidth of light to cure the resin (which most DLP printers seem to do to various degrees), and has a very short close focusing distance. Some of the printers I know that work are:
Acer 6510BD
Acer P1500
Viewsonic PJD7820HD
Viewsonic PJD7822HDL
Viewsonic PJD7828HDL

If you look on http://www.projectorcentral.com you will see that they all have the same throw ratio of 1.15-1.50 and zoom ratio of 1.3. This allows them to create a focusable image that is small enough to have a build area ranging from around 50-100 microns. Let's compare this to a different projector, one that I mistakenly bought based upon some information I read on muve3D's website.

The Viewsonic PJD7720HD has a throw ratio of 1.49-1.64 and a zoom ratio of 1.1. This does not allow it to create a small enough focusable image. I would estimate that the smallest build area was around 150 microns. So, I had to modify the project by adding spacers behind the front lens so that I could focus it down to 50-100 microns.

The issue is that many of these projectors are not made anymore. It seems like the Viewsonic PJD7828HDL is the only one readily available (on Amazon for example).

I am getting the same serial errors as in my message #6 on this thread, running builds 1261 and now 1279. I have disconnected the servo completely, yet still get this error. My printer seems to print ok, but it is hard to see many of the status messages in the log  since it is filled up with serial error messages after each layer (and at startup). I tried 3 different USB cables with no effect. Any suggestions on how to troubleshoot? Thanks.

I would assume that this feature would only work with an external (i.e. not nanoDLP's) slicer, so let's assume that the user would need to provide either .SLC, .SVG, or .PNG files (i.e. it won't work with .STL files).

What I propose is for nanoDLP to be able to import a table (.txt, .csv, or some other easily editable format) that details how to handle each and every layer, with columns for:
Layer Ignore (yes or no)
Layer Height (e.g. 10-100 microns)
Cure Time (seconds)
Pixel Dimming (on or off)

So, if I have a print that is 300 layers tall, I would like to import a table that has 300 rows, with values for each column. nanoDLP would be able to read this table file and print it accordingly. Does that make sense? Thanks!

Thanks for the reply Shahin, I will try another servo and report back.

I guess I don't understand the purpose of a shutter that only closes at the end of a print. Isn't the purpose of the shutter to block ambient light coming from the projector (which is always illuminating the entire build area, even though some of the areas are black) in order to prevent fast-acting resins from hardening/degrading? Are you saying that you don't see any difference in print results with/without a shutter?

Ok, I think I solved the problem for now. It wasn't the RAMPS/Arduino boards or the USB cable. Here is what I tried and my final working solution in the hopes that it might be of help to someone else. Note that in between each step I restarted the RPI3 each time.

1. My servo for the shutter (an SG90 servo) seems to be right on the edge of drawing too much current, which is perhaps why it worked in the beginning (for about a month) but thereafter started to cause problems with resetting the Arduino. Perhaps the gears are starting to get sticky, which can cause the servo to draw more power?
2. I unplugged the servo, but I was still getting the connection errors.
3. I tried changing the baud rate to the Arduino to 250000. While this didn't work, resetting it back to 115200 did (i.e. it cleared the connection errors in the log).
4. I replugged in the servo, and tried adding a 470uF capacitor on the +5V and GND connections. The connection errors came back.
5. I unplugged the servo (again), and again I was still getting the connection errors.
6. I changed the baud rate to the Arduino to 250000 and then back to 115200. Again, this cleared the connection errors in the log.
7. I wired an external 5V power supply to the servo, and now everything works.

Ok, I have tried disconnecting (unplugging) the servo completely and still get "Serial Communication Error EOF" errors. I then tried a completely new Arduino and RAMPS1.4 PCB combo (purchased brand new), reprogrammed with the latest muve3D Marlin firmware, and still with no servo plugged in, and am still getting "Serial Communication Error EOF" errors. Any other suggestions? Thanks!

I don't really understand it (or use it right now) either, but I believe Dean at muve3D worked with Shahin to add it to nanoDLP to help with large solid areas from overcuring.

If you join the muve3D Google group there are a few posts from Dean about it.