Slow 2D/3D preview confuses

vmario89

Hi,

i just stumbled upon the buttons "2D Preview" and "3D Preview" which i did not use before. After first try i thought they would not work because nothing happened after clicking them. Then i realized it takes 30 to 60 seconds to display the according previews (on an Raspberry Pi). Because this behaviour is confusing i thought about adding some visual feedback that UI tries to load the requested data so the user knows something is happening

Repetier

More confusing is that it takes 30-60 seconds for you. For me it takes less then a second. And in 2d view I can also slide through z layers more or less instantly even with a 70mb gcode.

Could you open debug tools->network and see if request take that long in your case to get answered. All these functions use regular downloads to retrieve the data. Question one is does requesting files start immediately and when does download start. It is no time intensive work so should only depend on sd card and web speed and a bit of the size. But 3d preview is just a 380kb image so not really that long.

vmario89

hi,

this time it was quicker but took 12 seconds (Repeated multiple times). if the menu is once loaded 2D/3D switchting is quick

the SD card on raspi is a SANDISK High Endurance Micro-SDHC Speicherkarte, 32 GB, 100 MB/s, UHS Class 3, V

the system load while the operation is loading:

iftop does not show anything else than the file transfer between browser <> apache <> Repetier Server. I tested it with http and https accessing localhost. Made no difference.

mhh. Maybe my local network is just slow. using an older cheap Router TL-WR842N by TP-Link

vmario89

edit: http is directly on port 3344 - no apache between

Repetier

You see the middle file took nearly 12 seconds to download. Assuming firefox green is time for data transfer. So that is the bottleneck. When you reload the page with debug open you should see timings for all files and see if other files are also that slow.

The other thing I wonder if that is a object in vase mode - that might also explain the delay. Vases have not a few hundred layer but many thousand layers as they change Z all the time. That makes the layer file quite big (I see 17mb in your case) and that file is not just copied but it gets converted from a small binary to a json formatted file which also slows down sending a bit. In that case it could be the bottleneck to convert it to json. I tested it with a vase and for the 8.4mb it took 2.5 seconds on a pi 4.

Maybe I should add a extra test that a new layer must be at least > 0.01 mm above layer start height. In my example I had an average layer height of 0.000484 mm. That makes not much sense anyway and is the reason the vase looks so transparent. Not that 0.01mm would change much for this.

vmario89

Hi,

indeed i sliced with spiral vase mode. Repetier is running on a RPi v3  and the regular layer height for that job is 0.7 mm (usually i am going to have 1.0 mm - using an E3D SuperVolcano high output hotend with 80 watts). Its a vase with 400 mm in height and the gcode is 20.8 mb. The layer height of Repetier Server for this job is 324615.

Repetier

Ok, so no error just unusual many layers since every extrusion at new Z is a new layer in servers definition of layer. Will see if I can get server to limit it to 0.01mm. But it is not easy so no guarantee.