search

area515 / Photonic3D

Control software for resin 3D printers
http://photonic3d.com
GNU General Public License v3.0
131 stars 115 forks source link

Exposure Times Too Long #245

Closed jmkao closed 7 years ago

jmkao commented 7 years ago

Projector based setups with DLP lamps set to high resolution modes, 25-37 microns, have very short exposure times, sensitive to 0.1 seconds (100 ms).

On an RPi 2, there are delays between when the slice image is displayed and when the blank occur. At the beginning of a print, this delay can be long and variable (200 - 4000ms), but even after steady state, it seems to still be over 100ms:

2016-08-07 03:51:51,075 INFO o.a.r.j.AbstractPrintFileProcessor [PrintJobProcessorThread-3] ExposureTime:239
2016-08-07 03:51:51,294 INFO o.a.r.j.AbstractPrintFileProcessor [PrintJobProcessorThread-3] { "layer": 112, "exposureTime": 102, "liftDistance": 3.66, "liftSpeed": 43.68872639270057 , "layerAreaMM2": 485.6762471610932 }
2016-08-07 03:51:52,003 INFO o.a.r.j.AbstractPrintFileProcessor [PrintJobProcessorThread-3] ExposureTime:216
2016-08-07 03:51:52,275 INFO o.a.r.j.AbstractPrintFileProcessor [PrintJobProcessorThread-3] { "layer": 113, "exposureTime": 102, "liftDistance": 3.66, "liftSpeed": 43.68609283806707 , "layerAreaMM2": 486.1852925052862 }
2016-08-07 03:51:52,995 INFO o.a.r.j.AbstractPrintFileProcessor [PrintJobProcessorThread-3] ExposureTime:218
2016-08-07 03:51:53,198 INFO o.a.r.j.AbstractPrintFileProcessor [PrintJobProcessorThread-3] { "layer": 114, "exposureTime": 102, "liftDistance": 3.66, "liftSpeed": 43.68925300079786 , "layerAreaMM2": 485.57443809225464 }
2016-08-07 03:51:53,917 INFO o.a.r.j.AbstractPrintFileProcessor [PrintJobProcessorThread-3] ExposureTime:223
2016-08-07 03:51:54,121 INFO o.a.r.j.AbstractPrintFileProcessor [PrintJobProcessorThread-3] { "layer": 115, "exposureTime": 102, "liftDistance": 3.66, "liftSpeed": 43.689982093886925 , "layerAreaMM2": 485.43347168924737 }
2016-08-07 03:51:54,898 INFO o.a.r.j.AbstractPrintFileProcessor [PrintJobProcessorThread-3] ExposureTime:218
2016-08-07 03:51:55,102 INFO o.a.r.j.AbstractPrintFileProcessor [PrintJobProcessorThread-3] { "layer": 116, "exposureTime": 102, "liftDistance": 3.66, "liftSpeed": 43.691683055562294 , "layerAreaMM2": 485.10455008223033 }

Doing some remote sample based profiling of the code running on the RPi shows:

image

The big suspect here is org.area515.resinprinter.job.AbstractPrintFileProcessor.calculate(), which is called inside of performPostSlice() to calculate the duration of the print. Since this could be a significant JavaScript function (in the case of my Titan 1 calculator, it is), it seems that this might be better done before the image is illuminated, which would require some refactoring of performPostSlice().

I'm testing an implementation of that to see if it makes a difference.

jmkao commented 7 years ago

Looks good, by putting the calculate outside of the timing loop, initial variability and latency is significantly reduced:

2016-08-07 05:06:59,582 INFO o.a.r.j.AbstractPrintFileProcessor [PrintJobProcessorThread-1] ExposureTime:511
2016-08-07 05:07:00,139 INFO o.a.r.j.AbstractPrintFileProcessor [PrintJobProcessorThread-1] { "layer": 0, "exposureTime": 500, "liftDistance": 8.5, "liftSpeed": 15.0 , "layerAreaMM2": 864.703578980343 }
2016-08-07 05:07:00,649 INFO o.a.r.j.AbstractPrintFileProcessor [PrintJobProcessorThread-1] ExposureTime:265
2016-08-07 05:07:01,114 INFO o.a.r.j.AbstractPrintFileProcessor [PrintJobProcessorThread-1] { "layer": 1, "exposureTime": 260, "liftDistance": 7.6899999999999995, "liftSpeed": 41.484437248126845 , "layerAreaMM2": 865.2204557913697 }
2016-08-07 05:07:01,575 INFO o.a.r.j.AbstractPrintFileProcessor [PrintJobProcessorThread-1] ExposureTime:203
2016-08-07 05:07:01,972 INFO o.a.r.j.AbstractPrintFileProcessor [PrintJobProcessorThread-1] { "layer": 2, "exposureTime": 200, "liftDistance": 7.59, "liftSpeed": 41.47762350532282 , "layerAreaMM2": 866.2777038139243 }
2016-08-07 05:07:02,426 INFO o.a.r.j.AbstractPrintFileProcessor [PrintJobProcessorThread-1] ExposureTime:176
2016-08-07 05:07:02,797 INFO o.a.r.j.AbstractPrintFileProcessor [PrintJobProcessorThread-1] { "layer": 3, "exposureTime": 173, "liftDistance": 7.49, "liftSpeed": 41.47424049753442 , "layerAreaMM2": 866.8024120917847 }
2016-08-07 05:07:03,610 INFO o.a.r.j.AbstractPrintFileProcessor [PrintJobProcessorThread-1] ExposureTime:160
WesGilster commented 7 years ago

Wow, that's actually significantly more accurate than what I thought we could get with sleep(). I was planning on fixing this with a scheduled executor which will be about as exact as possible. However, you are down to a max 11 millisecond variability! I love knowing we have more options, but I'm just not sure it needs to be more accurate than that...