A visual guide to dynamic lift speeds in NanoDLP

lenne0815 · 2017-07-03 05:39:49

1125lbs wrote:

would we use some ceil or float before * in equation, could releaf "brain stress" for pi deal with movements?
i think the float numbers would not affect so much when dealing with velocity, in case you working with direct control with dynamic speeds , velocities could influence in rounding errors depending of the driver capabilities. as direct control may have been coded with pulse train, do you think it could improve anyway?

I think for feedrates shahin does that already, feedrates get reported as full values aswell. But for flat curing times its not in there ( 4.5s curing time gets reported as 4,498678976 something seconds ) and dynamic lift heights are cut to early at the first value.

I suspect cure times would be fine as *.**s and lift heights would work as either *.**mm or full microns which would equate to *.***mm

1125lbs wrote:

"is it possible to handle [[Slowsection]] in dynamic speed?"

I dont think theres a call which reports Slowsection as there is for base layers now, but you could do it manually like i did in the picture for the base layers.

Last edited by lenne0815 (2017-07-03 05:46:14)

Shahin · 2017-07-03 06:58:25

lenne0815 wrote:

Dynamic lift height ( which i get with [[ZLiftDistance]] ) only calculates full values not the decimals.

Fixed, try again.

DrNK · 2017-07-03 14:59:19

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 ) }

lenne0815 · 2017-07-03 16:18:03

Shahin wrote:

lenne0815 wrote:
Dynamic lift height ( which i get with [[ZLiftDistance]] ) only calculates full values not the decimals.
Fixed, try again.

Confirmed working ! This actually explains a lot of problems i had in the past, i never checked it thoroughly so i didnt realise it wasnt working and i was just unable to get it dialed in,now that it works i already shaved of another 5 minutes of one of my 45min testprints with it Thank you very much for the quick fix Shahin !

( i think especially the new details section helps a lot with figuring out dynamic lifts / speeds, again thank you very much for your work ! )

DrNK wrote:

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 ) }

Upgrade to 1556 and give it a try, it should atleast do something. I dont have a D7 so you need to dial it in by yourself, it works very similar to the dynamic lift speed for which i already made a lengthy explanation.

One more thing, maybe its specific to my setup but auto populating the name of a new plate by filename stopped working.

Last edited by lenne0815 (2017-07-03 16:20:56)

Shahin · 2017-07-03 17:08:08

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

lenne0815 · 2017-07-03 17:16:11

Shahin wrote:

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

Shame on me, was a browser cache problem in chrome fixed.

DrNK · 2017-07-03 19:18:28

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

lenne0815 · 2017-07-03 21:12:07

DrNK wrote:

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

Your link is broken.

1125lbs · 2017-07-04 00:38:32

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 ) }

binfordboy · 2017-07-04 09:11:06

Is it possible to tie the dynamic lift result to the next multiple of the Z-Axis step resolution to avoid chaining stepping errors?

lenne0815 · 2017-07-04 13:27:01

binfordboy wrote:

Is it possible to tie the dynamic lift result to the next multiple of the Z-Axis step resolution to avoid chaining stepping errors?

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)

binfordboy · 2017-07-04 15:26:13

If i print a 160mm part with 20 micron layerheight i get 8000 layers resulting in totaly 16000 up and down movements. Worst case error accumulating according to your example by 0.001mm is then 16mm - 10%.
I might be totally wrong here too :-)

lenne0815 · 2017-07-04 16:34:12

binfordboy wrote:

If i print a 160mm part with 20 micron layerheight i get 8000 layers resulting in totaly 16000 up and down movements. Worst case error accumulating according to your example by 0.001mm is then 16mm - 10%.
I might be totally wrong here too :-)

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)

binfordboy · 2017-07-04 17:58:26

Microstepping beyond 8x is gambling. You cant get better results then your stepper motor Hardware tolerance. Microstepping is usefull for smoother motion and not for tricking physics. Microstepping Resolution looks nice on printer specs. Stepper Motors handle Full and halfstep accuratly.

I'm using direct control with halfstep and 5mm Screw. My Initial question was about some kind of mathformula to round the result from your great Formula ( Btw. : thank you) to my hardware Resolution to avoid errors. I'm a Kind of Inverted MathNerd.

Shahin · 2017-07-04 18:23:31

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.

lenne0815 · 2017-07-04 18:54:51

Yeah, shahin answered that pretty much, its as expected, nanodlp already solves rounding "errors" when pulsing directly internally.

Interesting question nonetheless !

5mm pitch seems pretty steep for someone asking questions about rounding errors though, get a 0.9° stepper and change your leadscrew to something like this https://tech.thk.com/de/products/thkdlinks.php?id=359 the 10x2 seems like a fine solution for prints taking north of 24hrs to finish.

I consistently drive gcode with 250000+ movements without ever noticing stepping / rounding errors, even though im sure atleast some occur. ( and thats with "gambling" at 16x microstepping with a completely underpowered nema 23 driven 80kg+ gantry )

binfordboy · 2017-07-04 19:47:44

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.

backXslash · 2017-07-06 12:52:58

binfordboy wrote:

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.

If you're that worried about it check out the rebuild log I posted for my printer. I use a Nano Zero stepper controller from MisFit Tech, give me closed loop control and a guaranteed error of less than .3 degrees of rotation.

lenne0815 · 2017-07-06 13:03:49

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)

Shahin · 2017-07-06 19:16:12

Could you download a plate with mentioned spec and share it? you can remove STL file from downloaded file as it does not required.

As I remember there is no change on calculation logic recently.

lenne0815 · 2017-07-06 20:18:35

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 !

Shahin · 2017-07-06 20:34:04

On the early layers [[TotalSolidArea]] is around 1100. After layer 81 it becomes around 160. Which explains this speed difference.

lenne0815 · 2017-07-06 20:36:34

Shahin wrote:

On the early layers [[TotalSolidArea]] is around 1100. After layer 81 it becomes around 160. Which explains this speed difference.

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)

Shahin · 2017-07-07 04:40:03

Layer
    1/280
Total Solid Area
    1121.2798
Cure Layer
    35.000000

Layer
    9/280
Total Solid Area
    1121.2804
Cure Layer
    0.758685

Layer
    182/280
Total Solid Area
    133.22514
Cure Layer
    104.444644

I have added your formula to dynamic cure times and double check values. Calculations are correct.
Where do you put your formula? Inside gcode box?

lenne0815 · 2017-07-07 06:15:02

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)

nanoDLP

#26 2017-07-03 05:39:49

Re: A visual guide to dynamic lift speeds in NanoDLP

#27 2017-07-03 06:58:25

Re: A visual guide to dynamic lift speeds in NanoDLP

#28 2017-07-03 14:59:19

Re: A visual guide to dynamic lift speeds in NanoDLP

#29 2017-07-03 16:18:03

Re: A visual guide to dynamic lift speeds in NanoDLP

#30 2017-07-03 17:08:08

Re: A visual guide to dynamic lift speeds in NanoDLP

#31 2017-07-03 17:16:11

Re: A visual guide to dynamic lift speeds in NanoDLP

#32 2017-07-03 19:18:28

Re: A visual guide to dynamic lift speeds in NanoDLP

#33 2017-07-03 21:12:07

Re: A visual guide to dynamic lift speeds in NanoDLP

#34 2017-07-04 00:38:32

Re: A visual guide to dynamic lift speeds in NanoDLP

#35 2017-07-04 09:11:06

Re: A visual guide to dynamic lift speeds in NanoDLP

#36 2017-07-04 13:27:01

Re: A visual guide to dynamic lift speeds in NanoDLP

#37 2017-07-04 15:26:13

Re: A visual guide to dynamic lift speeds in NanoDLP

#38 2017-07-04 16:34:12

Re: A visual guide to dynamic lift speeds in NanoDLP

#39 2017-07-04 17:58:26

Re: A visual guide to dynamic lift speeds in NanoDLP

#40 2017-07-04 18:23:31

Re: A visual guide to dynamic lift speeds in NanoDLP

#41 2017-07-04 18:54:51

Re: A visual guide to dynamic lift speeds in NanoDLP

#42 2017-07-04 19:47:44

Re: A visual guide to dynamic lift speeds in NanoDLP

#43 2017-07-06 12:52:58

Re: A visual guide to dynamic lift speeds in NanoDLP

#44 2017-07-06 13:03:49

Re: A visual guide to dynamic lift speeds in NanoDLP

#45 2017-07-06 19:16:12

Re: A visual guide to dynamic lift speeds in NanoDLP

#46 2017-07-06 20:18:35

Re: A visual guide to dynamic lift speeds in NanoDLP

#47 2017-07-06 20:34:04

Re: A visual guide to dynamic lift speeds in NanoDLP

#48 2017-07-06 20:36:34

Re: A visual guide to dynamic lift speeds in NanoDLP

#49 2017-07-07 04:40:03

Re: A visual guide to dynamic lift speeds in NanoDLP

#50 2017-07-07 06:15:02

Re: A visual guide to dynamic lift speeds in NanoDLP

Board footer