Exposure Delay Anomaly

[DDLLC]

In some recent work I've been doing characterizing the Elegoo Standard Gray Resin I noticed that the delay parameters entered before slicing were not being followed by the Mars Printer. Sometimes the delay was completely absent or the time deviated from what was intended.

In the chart below you are looking a series of runs with a variety of parameters. I've extracted a few examples. The Runs labeled 18, 19, 20 and 21 where when actual parts were being printed. The ones labeled 21-XX were runs without a build plate and resin tank. The "XX" is for the number of seconds programmed into the run. The designation M means it happened after some modifications to the machine that are not related to anything having to do with the exposure setting. All of the runs were sliced on Chitubox 1.7 except the run that has a v1.8 designation.

The blue bar is the up- down time calculated for the particular speed parameters. The orange bar is the value entered into the slicer that is the "effective delay plus the up-down time. and the gray bar is the measured time I recorded.

As you can see for all 21 samples the delay time is ignored.  For 18 and 20 they have the same up-down time and effective delay time added but the measured delays are dramatically different. Run 19 has the same up-down time as 18 and one half the effective delay of 18 added but it's measured delay is much larger than 18.

Is there a way to see on the Mars printer which parameters it has read from the Chitubox file? Or is there an independent reader for the file?
I have looked at some of these files on the Photon Validator and I think it is seeing the delay parameters (the Photon descriptors are lacking but the numbers seemed to match the delay times).

Has anybody else see such behavior? If so do you have a fix?

Greg

[c_n]

Are you aware of UVtools?

[DDLLC]

C-N,

I am now..thank you.

It did show that the chitubox has programmed the correct delay times for the data in the graph. Not sure why I'm not measuring longer delay times, but at least one source of error is removed.

Greg

[DDLLC]

I've been able to deduce a little more about the delay function on the Mars unit. First let me note that I'm using the Chitubox 1.81 version which does seem to encode delay's for both the bottom and subsequent layers (and they can be different values.) The Elegoo Mars ignores anything entered for the bottom delay and instead will use the value entered for layers and apply to the bottom layers as well.

There is a seemingly static delay  of about 9s built in for the very first layer printed. It's hard to measure accurately as there is only a stopping of the plate movement after zeroing.

I have cases where the off-on time is less than it should be with a zero entered into the print parameters. For example if the combination of lift speed, lift distance and retract speeds (i.e., zero delay added) calculates out to 11.2 seconds, time between the print image turning off and then back on is circa 7 seconds. This difference occurs on both bottom layers and subsequent layers. That suggests that at least one of the speed parameters defaults to a higher value than entered

My data shows that putting in a delay reduces the variances of the print thickness. The amount of scatter in the data has forced me to running 3 replicates of any trial parameter sets. The different colored points in the following two charts represent a given run. The print parameters for all values in a given graph are identical. The difference between the two graphs is that one has  a 9 second delay and the the other has a 13.2 second delay. The graphs also group the parameters of each trial as to the physical location moving clockwise from the left rear corner to the middle of the left side of the rectangle (95 x 65 mm open rectangle with design height of 5 mm). The individual data points map similarly from run to run even with different delay times. (I've had some shift where the back edge was thicker than the front on other trials most likely a function of some machine mods, but there are no machine mods between these two plots).
The average thickness and percent standard deviations on the 22 (13.2 second delay) are 5.30 mm and 1.4% while on the 23 (9 second delay) are 5.48 and 2.1% respectively.

I'm convinced that a delay will improve thickness control, but can say yet what the best amount of delay should be. There's more work to be done.

[cliffyk]

I played with the delay settings sometime back, my thinking as yours that extending same might add some stability due to the viscosity of the resin--though I did not get as far into it as you, I just used the Chitubox "estimated print time" (EPT) as a gauge. I too found that settings of 0-7 s made no difference in the EPT.

my methodology:

Using a 40 mm dia. cylinder 50 mm high (1001 layers), regular delays of 0 to 7 s produced a 4h51m3s (17463 s) EPT; then at 8 seconds an EPT of (5h4m1s (18241 s))--an increase of 779 s (from 1001 layers?). A 9 s delay made the EPT 19236 s; an increase v. 8 s of 995 s (getting closer). Bumping the delay to 10 s added another 995 s (v. 9 s delay).

Moving to 11s delay once again added another 995 s (v. 10 s); 12 s was the same, another 995 s. That's as far as I went 'cause i got bored.

In any event it is clear to me that Chitubox ignores user defined delays of 0 to 7 s, instead using some hard-coded value.

The bottom layer delay behaved similarly, except that 0-6 s had not effect; at 7 s EPT increased by 4 s (w/ 5 bottom layers)--an 8 s bottom delay increased EPT by 5 s  v. the 7 s EPT (as to be expected wit 5 bottom layers. 9 s and upward (bottom layer delays) also produced 5 s increases in EPT.

However as these are "happy-home-owner", consumer class devices--utilizing free software--methinks we may be expecting too much of them...

[cliffyk]

I realized the above narrative was a bit difficult to follow so for clarity I loaded my handwritten log book data into a spreadsheet:



As in the narrative, EPT (s) is Chitubox's Estimated Print Time (as displayed after slicing) expressed in seconds.

The chart makes the ineffectiveness of the 0-7 s (regular) and 0-6 s (bottom) inter-layer delay settings quite clear.

[DDLLC]

Just to be clear, I do think that Chitubox is encoding the delay values (based upon viewing with UV tools and Photon Validator and seeing the delay parameters), but I think that the Mars unit ignores the base delay times and just uses the layer delay time for all layers. No way to be certain. I see your info suggests that the fault might be with Chitubox based upon the print times so I'll look at that also. The good thing is that there's one less variable for the DOE.

The lack of the up-down timing not correlating tightly to the mathematical determination from the speed parameters is an annoyance in designing experiments, but now that I know it exists, I can deal with it.

I think I'm within one or two more trial sets to see where additional delay no longer has a material effect on the standard deviations.

The print pattern itself is likely a bigger factor at this point. I'm guessing that is coming from nonuniform illumination which won't be easy to address. Not even sure it's worth trying.

Greg

[cliffyk]

My observations do not intuitively support that "...Chitubox is encoding the delay values..."--though "intuition" often sucks as a confirmational observation--nonetheless one would think if it were including same in the output file they would be considered in the EPT calculation. IT would be odd coding to specifically exclude those values.

I have not saved the files and assessed them with UVTools or other. I need to do that...

[DDLLC]

I agree that your data does not suggest that Chitubox is encoding the delay. I've attached a screen shot of UVtools opening a file with a trial that has a 10 second delay (and zero for the base layer). If you look along the bottom of the image you can some print parameters and again in the scrolling parameter window on the left below the one image.

The numbers do represent what was entered into Chitubox v1.8.1, but of course that doesn't really mean they were encoded in the file that the Mars runs.
I've seen the same results on files generated on an earlier Chitubox (I think it was 1.7.3 off the top of my head).

Greg

[cliffyk]

Per my observations a delay of 10 s would be calculated and presumably included in the output file. It is user selected (regular layer) delays of 0 to 7 s that are ignored--0 to 6 s for bottom layers...