nanoDLP

For calculating Realtime maybe it lessens the burden on the pi if you break up the exponential function into maybe just 5 hard points, that should be sufficiently precise for a very smooth peel and a just as smooth stop after retract in the vat for the next layer.

So much thanks !

I thought about other ways of doing it "manually" but nothing came to my mind quickly

Maybe real time is feasible as we only move a single axis between to fixed points, but precalculating while slicing could work aswell, for the calculators we would need the possibility to tie the accel "rates" to [[buildarea]].

Is there a certain daughterboard you recommend for using with pi and Nanodlp ?

Ah i see, it would be a great feature if we could pull values from certain ui input boxes, that way we can retain functionality while still driving the machine via scripts.

In this lift speed example i did it manually: {([[LayerNumber]]<=10)*30 + (([[LayerNumber]]>10)*( 30 + 40 / ( 1 + ( 2.718 ** -( 2 - ( 0.0008*[[TotalSolidArea]]) + 2))))) } Gives 10 Burn in layers which need to be changed manually according to needs.

Ideally it would look like this: {([[LayerNumber]]<=[[Input_var_from_Amount_of_Burn_in_Layersfield]])*30 + (([[LayerNumber]]>[[Input_var_from_Amount_of_Burn_in_Layersfield]])*( 30 + 40 / ( 1 + ( 2.718 ** -( 2 - ( 0.0008*[[TotalSolidArea]]) + 2))))) }

Lift height would look a bit different to retain full burn in input compatibility:

{([[LayerNumber]]<=[[Input_var_from_Amount_of_Burn_in_Layersfield]])*[[Input_var_from_Burn_in_Layers_lift_height_field]] + ([[LayerNumber]]>[[Input_var_from_Amount_of_Burn_in_Layersfield]])*(0.8 / (1 + ( 2.718**-(0.0003*[[TotalSolidArea]] - 3))) +2.5) }

Thanks for that info shahin, so i do have to trust you I just noticed that long borders running along the pixel intersections give problems with antialiasing but that might be more an aligning problem than a software one, i just wanted to see how supersampling would deal with it.