Wrong height when slicing

GPM · 2017-08-23 16:14:04

Hi all,

I 'm running a system based on arduino mega and ramp 1.4 to drive z axis with one end stop at the bottom (patched marlin firmware) through RPi .The system works.
The problem begins when I put different Layer Thickness in Burn-in Layers option.

Here is an example: I have to slice a cube with 10mm height at 25 microns.

Option 1 [Layer Thickness for Burn-in Layers and Normal Layers are 25 microns each] Slicer calculates 400 layers for total height which is correct.

Option 2 [Layer Thickness 100 microns] for [10 Burn-in Layers] and [25 microns for the Normal Layers] slicer also calculates 400 layers which is wrong. In that case total height is 10.75mm. That means that slicer adds 0.75mm in total height stretching first 10 layers for 0.075mm each.

Is there a problem with my nanodlp settings (G-code) or is a bug through slicer calculations.

Please advise

Shahin · 2017-08-23 17:43:01

You need to regenerate plate after each resolution change.

GPM · 2017-08-23 18:26:20

Thanks for the quick replay.

How do I regenerate plate? Is part of the g-code sequence?

Shahin · 2017-08-23 18:41:19

No, on plates page click on regenerate button.

GPM · 2017-08-23 19:06:43

I see. I can't have different layer thickness for burn-in and normal layers in the same profile. So if I understand correct, I create a profile for 100 microns then slice the object. I start printing and during printing after 10 layers I change profile to 25 microns and hit recreate. Correct?
I was hoping for an automated procedure but thanks again.

leitnin · 2017-12-01 09:34:05

Burn-in layer thickness is not correctly handled by the slicer.

I am seeing the same issue.

For me, the Z-axis cannot physically reach Zero, only 0.2mm. Therefore, I set the home position as 0.2 mm which is possible through the start code with G92 and the PositionSet command, and then can simply set 1 burnin layer as 200um with normal layers at 100. For a 10mm object, this should result in 99 layers. But it does not, instead there are still 100 layers as if everything is 100um layers.

Setting 1 burnin layer at 0.4mm should result in 97 layers, but it is still 100.

I have recreated the plate and started from Add with the same result. Burnin layer thickness is simply not taken into account. Tested on nanodlp-image for Rpi and build 1742 on PC. Same behavior.

Number of Low Quality Layers also seems to have no effect on number of layers, although it should.

Are these only taken into account during printing (I will check if the layers are correctly skipped now, but I can't image this is the case)?

Last edited by leitnin (2017-12-01 09:37:29)

GPM · 2017-12-06 01:24:26

I'm sure that wrong slicing thickness is a gcode issue. I'm not that good with gcode..

So I'm using an external slicer now for better handling.It cost me 100 euro but it's working smooth (fast slicing, no errors during slicing and quick upload to nano).

Then I upload the png files (slices) to nanodlp and print.

Shahin · 2017-12-06 02:42:54

Reason to have different height for burn-in layers is to handle possible issues with floor calibration and PDMS. It is intended behavior to have same height as normal layers. It is easy to handle slice in different heights, but would not possible to handle floor calibration issues this way.
I am not sure what you want to achieve by having different values.

About the low quality layers, it could speed up process during support area by skipping some layers.

nanoDLP

#1 2017-08-23 16:14:04

Wrong height when slicing

#2 2017-08-23 17:43:01

Re: Wrong height when slicing

#3 2017-08-23 18:26:20

Re: Wrong height when slicing

#4 2017-08-23 18:41:19

Re: Wrong height when slicing

#5 2017-08-23 19:06:43

Re: Wrong height when slicing

#6 2017-12-01 09:34:05

Re: Wrong height when slicing

#7 2017-12-06 01:24:26

Re: Wrong height when slicing

#8 2017-12-06 02:42:54

Re: Wrong height when slicing

Board footer