nanoDLP

Shell I Change anything in this for Wanhao D7?

{ ([[IsBurninLayer]])*3.5 + ([[IsBurninLayer]]==0) * (1 / ( 0.7 + ( 2.718**-(0.02*[[LargestArea]] - 3))) +1.7 ) }

It is working. Open inspector tool's console area and see if it displays any issue.

Sorry for the question but am I correct  put these values in

are the fields of those settings correct? Dynamic Speed & Dynamic Lift
https://www.dropbox.com/s/1gnjotc6k3xg5 … 8.png?dl=0

nano [[IsBurninLayers]]?
yes it is.

{ ([[IsBurninLayer]])*3.5 + ([[IsBurninLayer]]==0) * (1 / ( 0.7 + ( 2.718**-(0.02*https://youtu.be/0fYL_qiDYf0 - 3))) +1.7 ) }

Honestly thats the last thing i would worry about, step errors gonna happen no matter what final value ur driving the stepper to. If you want servo like movement either use a servo or one of these nifty piggyback magnet winding sensors.

I dont think it would work anyway as the ramps does the step p mm calculation so you would need to customise the firmware to be even able to get a reliable mm per step translation back to nanodlp at all.

With direct driving it might be possible but the internal microstepping translation makes it again impossible, so you would need to drive in full stepping mode.

At 16x microstepping and a 3mm pitch leadscrew the ramps can accurately translate values down to 0.001mm errors acumulating in that range are easily offset by a variyng power grid in the neighbourhood i think

For a full 160mm print this means if you miss every single time the whole print would be 0.08mm off, less than a single missed step, the very moment you take that of the plate resin shrinkage would have outpaced that by a huge amount.

I might be totally wrong here though, maybe shahin can clear this up.

Last edited by lenne0815 (2017-07-04 13:48:33)

actually your more right than i was ( I forgot the up and down movement ) but its only 8mm because a rounding error is 50% worst case.

But it still stands; it would only work with direct driving the stepper with a stepper driver on full step settings which causes all kinds of problems ( https://www.youtube.com/watch?v=dmk6zIkj7WM ) reducing the overall accuracy to just 0,015 for my example.

Im not even sure how the stepper driver themselves handle these inaccuracies, i would guess they "remember" unsolvable pulses with microstepping and add / substract them on the next possible movement.

If driven by a ramps i would guess that the ramps takes over this function and only sends out possible movements, queuing unsolvable movements and executing them the next time possible.

No matter how you look at it trying to get pulses and movement distances in sync via nanoDLP seems like a complete waste of time, switching over to a 0,9° stepper and a 2mm pitch screw alone would drive worst case error accumulation down to 0,62mm for 8k slices in comparison to 8mm shrink with a low shrink ( 2% ) resin.

Last edited by lenne0815 (2017-07-04 17:13:34)

I agree with lenne, vast number of other issues effecting quality of prints much more than rounding and math issues. Nanodlp internally keep everything in terms of pulses. So rounding on software side is not a big issue.
So nanodlp converts dynamic lifting value to pulse and keep it.

I am not sure about RAMPS but I expect in absolute mode pulse to mm would not cause any problem. About hardware stepper drivers my impression is that even though microstepping is not accurate, correctly calibrated driver should not show any measurable mistake in completed pieces.

Also consider same driver and RAMPS boards being used on CNC with order magnitude more movements during process.

With halfstep and 5mm lead Screw i get a Real Hardware Resolution from 0.0125 mm which is cool for me printing  with 0.025 layer.  When i use dynamic lift and the Formula result is not a  multiple of this real 0.0125 reproducable stepping resolution,  the result per lift is wrong and get wronger on each lift about 0.0125mm because the stepper can hold on full and half steps. So on each 0.025 Layerheight there is a possibility from 50% to get the next Layerheight wrong by more then the half Layerheight.

So if get shahin right nanodlp handle this automaticaly internal and everything is ok.

Shahin, big problem !

I dont know if this is exactly the problem but i think once [[TotalSolidArea]] reaches 1000 the speed calculation completely tilts, i used this:

{([[IsBurninLayer]])*35 + ([[IsBurninLayer]]==0)*(110/(1+(2.718**-(2-(0.008*[[TotalSolidArea]])+2))))}

For dynamic speed which worked fine for a small part but now ive ran a bigger part and everything over 1000mm2 gets calculated at F500 ( should be around 1,9 ) which in turn means F2000 for retracts so my printer luckily just tilted on the retract movements and nothing happend

This definitely didnt happen before so i think there must be an error in the recent additions.

Last edited by lenne0815 (2017-07-06 13:04:25)

Heres the plate:

https://drive.google.com/file/d/0B8hfq7 … sp=sharing

And here the Debug info ( sliced the plate right before, exibited the same error )

https://drive.google.com/file/d/0B8hfq7 … sp=sharing

Thank you Shahin !

The speed difference should be exactly the other way around as calculated by my script, for the large layers is should only add feedrates of about F1 to F2 to the basic F35

Check this; at 1000 Total solid area it should give out a value close to 0

https://www.google.de/search?q=(100%2F( … x)%2B2))))

Last edited by lenne0815 (2017-07-07 06:53:40)

It goes into the dynamic lift speed box, i never touched cure times

Heres the full profile: https://drive.google.com/file/d/0B8hfq7 … sp=sharing

Just double checked, if i put it into the cure box it works correctly here aswell, just not in the speed box.

And checked again, the only way to get this error showing is when i use this:

{([[IsBurninLayer]])*35 + ([[IsBurninLayer]]==0)*(100/(1+(2.718**-(2-(0.008*[[TotalSolidArea]])+2))))}

So now i guess it has nothing to do with the size of the total area but it happens when a feedrate calculation goes below 1

This works fine f.e.

{([[IsBurninLayer]])*35 + ([[IsBurninLayer]]==0)*(50 + 60/(1+(2.718**-(2-(0.008*[[TotalSolidArea]])+2))))}

The added offset of F50 masks the problem in that case.

For some reason Wait before print is ignored for the base layers aswell, it shows correctly in the slice preview but isnt applied while printing.

Last edited by lenne0815 (2017-07-07 10:58:52)