nanoDLP

You can create any new file under /etc/udev/rules as long as it follow the same name structure ("NN-your_rule_name.rules", where NN is a two digit number). In any case, I would use a high one (you might even edit 99)

By the way, seems like this could be a power supply issue which force RAMPS to reset when activating servos. How are you powering the servo? Directly from RAMPS or Raspberry PI? Servo motors can drain a lot of current when moving (or holding torque). These usually really short time frames with high current requirement may exceed your power supply rating and cause a voltage drop, resetting RAMPS or RPi.
Try using an external power source for the servo (remember to also connect ground to your RAMPS or rpi ground) and check if the problem persist. If you are using 5V servos, which I suppose, you can use a spare 5V phone charger, for example.

I have been experimenting a little more.
I added a customized button which does the following:

[[Net http://127.0.0.1:8080/camera/take]]
[[Exec ln -sf "$(find /home/pi/printer/public/shots/ -maxdepth 1 -name '*.jpg' |sort -t_ -nk2,2|tail -n1)" /home/pi/printer/public/shot.jpg]]

It succeed to update the symbolic link, but taking photo using net function do not work. I guess it might be related with password protection. Would it be possible to selectively disable password if requests come from 127.0.0.1?

Thanks in advance for the help!

I will try adding it to the official marlin docs in the next days.
Short version:
To enable it, you need to enable a couple of options/flags in config_adv.h before compiling Marlin source code. (Other options should be configured according to your printer, please check your previous config).
At the end of config_adv.h you will find:

• define NANODLP_Z_SYNC : uncomment this one to enable Z_move_comp output for the following commands:

  • G1: only if command includes Z axis;

  • G4: always;

  • G28: only if homing Z or all axis;

• define NANODLP_ALL_AXIS: uncomment also this line if you want Z_move_comp output from the following commands:

  • G1: always;

  • G4: always;

  • G28: always.

PS: if it's not too much effort and cost to set up and maintain, have you considered the possibility of a wiki? This might help the community to contribute to documentation. You made a great work, but first approach is often a bit hard as there is no extended documentation. We have the forum, which is great, but sometimes you have to read though many topics to understand features. A wiki might help to resume all that info spread across the forums.

I will test it again as soon as possible, but seems like ln -sf fails/do not work, at least when taking photos manually. If I delete it before hitting the button, shot.jpg is not generated at all. I guess it should when printing, but I should confirm using it.
Gonna try new beta if available.

About caching problem: yesterday I found that using chrome (at least on Windows, gonna try more combinations next week) makes caching problem worst. Hitting refresh is not enough you will need to hold Shift down while pressing refresh button to force the cache to clean or old photo/plates will keep showing.

I just noticed that you also need to force refresh (F5) in order to show correct plate preview during printing if you change something in a plate and repeat a print.
For example I regenerated the calibration plate using less time values (less pillars) and the preview still showed the old ones as being exposed. Checking on the printer revealed that the updated plate was being actually projected.
I was wondering why and try to check /public/plates directory, where layers where actually updated; then I just hit F5 and the correct images started to display in the UI. Seems like a caching  problem.

I just find out it only works if "Save last image only" is selected, not working if saving all image.
Is it possible to check it out?
Thanks in advance.

So I will use ExecReturn to get the value for the formula, thanks.
About being able to visualize it, any chance to show ExecReturn value in a pop-up when pressing a Button? Or otherwise to update it manually? I could not find where the value is stored.

The commands were just for that.

It seems the problem is on Raspberry Pi side (or at least raspbian OS) and not NanoDLP.
You first need to get HDMI output at 4K resolution. No experience case, maybe someone else might help.

Just out of curiosity, do the screen succeed to configure at 4K with a normal PC? Use the same cable to try, just in case.
Edit: did you try running the same commands without changing default config?

You have two partition in the SD:

1. Boot partition, FAT32

2. Linux partition (Ext3 or ext4, I guess)

Main filesystem is on n.2, while you are probably looking at n. 1. You will need to access it from a linux system or install a windows driver. Otherwise, if you enable it, you can just SSH into your device and make changes from command line or remotely connect through SFTP and explore folders.

You are right, sorry for the big mistake. I can only access the printer when at lab, but usually I find time to post here when not there. I should have double checked but I never downloaded the plate images. So I was relying on visual memories, and without being able to zoom the image enough from the UI. Thanks for the clarification.

In theory, doubling resolution might help only with diamond oriented pixels. In practice, by the way, I guess it should not work. I try to explain why, please correct me if I am wrong.
HDMI port will be set at a given resolution, your display maximum. So, even if projecting a bigger image, NanoDLP outputs it to HDMI; this means it goes through Raspberry Pi GPU which will adapt it to HDMI resolution, making a first anti-aliasing. I guess there is no way to send a double resolution image to your LCD without being first rasterized to its maximum resolution.

Yes, I get the point but I would like to be sure about how NanoDLP works. I will explain how I understood it, correct me if I got any part even slightly wrong.

You push STL to NanoDLP and slicer generates the Plate (a stack of images, -PNG I guess-). All images in the stack would have the same resolution of the projector setting (let's say 1920x1080).
In that case, when using a projector with straight-oriented pixels (non-diamond oriented) PNG pixels will coincide with projector ones.
So I ask, do generated image only have black and white pixels or are there different grayscale values to achieve subpixel resolution? Something like in this example:

If images are only B/W, could the same effect be obtained by increasing resolution of projected image (so GPU will anti-alias border pixels making them different grayscale value)?

Just a clarification: if using USB/serial projector, is lamp hour updated each time the variable [[LampHours]] is evaluated (every layer print)? Or it is just at slicing time? Or during some events, like before printing start? Or only manually?

If any of the latter, it would be good to have a way to update the LampHours value from GCode (Something like [[LampHoursSet N]]). This way value could also be cheked from the interface.
Right now I can have the actual value from external program with something like [[ExecReturn ./getLampHours]] and use the expression in a formula to get exposure time for the layer. But I think running the external program as many times as layers in the print might slow things down and increase the number of steps which depends from external programs.
Being able to set it once before printing might more reliable option.