Slow to load some STL files

Hi all I'm wondering if anyone else has this issue.
Some STL files that I open take a really long time to load in to Rep-Host. Such as this tree frog model, will take 20-25min before it opens.
Opening the same file in RepG or other programs takes 3-4 sec.
It seems related to the file size but 20min is way too long especially if other programs are near instant. I don't have issues with all files just the files that are around 8mb or more.
I'm using v1.0.5 but I think I had the same issue with past versions.
Is this normal? Any known fix's to reduce load time?

Let me know if any more info is needed.



  • Just tested your mentioned tree frog with 1.0.5 and I opened it within 2 seconds.

    There was a version that had problems with some stl files but that has been solved for 1.0.5.

    Testing machine was Win7 64 bit, also that should not really matter. Where does the progress bar start to get slow? What does it say on top of the bar?
  • I press the load button and in the object placement tab it will say "Importing treefrog_45_cut.stl"
    The progress bar will not move for a good 2-3min, it will just say "loading...." and with no progress. If i try to click anything in the Rep-host window it will claim "not responding" but after the said 20-25min it will still load.
    I'm also using win7 64 bit. I will try a complete reinstall of rep-host, Could having old versions installed in other locations cause this?
    Thanks for the feedback thus far.
  • I uninstalled Rep-host and removed all other unused versions. I then reinstalled using V1.0.6.
    I still have the same issue.
  • Sound like the hang happens on opening the file. Maybe the antivirus is blocking for a while, also I don't understand why it should take so long. But as far as I understand them, they check files beeing opened.

    There is also a difference between binary und ascii stl files. Files are always opened assuming binary format. If the header does not match binary format, file is closed and reread as ascii file. So maybe you have problems with one of those, since ascii would reopen directly after close. On the other side, this no illegal behaviour and should work - and in fact does work normally. But you never know what protection software thinks or does.

    So if you can start with antivirus disabled and see if it still happens. If it helps, please let me know what you are using. We are using Kaspersky here and have no problems.
  • I have turned off my real time protection of Microsoft security essentials.
    I updated to the latest Java and removed old versions.
    Same issue.
    I opened the STL file with not pad and it looks like this:
    solid Default
      facet normal -3.325848e-01 7.776186e-01 5.335698e-01
        outer loop
          vertex 1.052500e+01 -7.555001e+00 1.053128e+01
          vertex 1.062500e+01 -7.375001e+00 1.033128e+01
          vertex 1.013500e+01 -7.365001e+00 1.001128e+01
    ........ and so on
    I then exported another random file as a ascii STL and as a binary STL useing Cubify Design.
    Opening both in notepad++ i just see alot of NULs in both.
    I did not really expect the notepad to open it but from this test it looks like the original treefrog file is not Binary OR Ascii??? Or perhaps this is not a good way to deduce what type of STL a file is.

    I found a Ascii?? to Binary converter by Brian Ekins.

    Converting the Treefrog file lets me open it in the normal 2-3sec. The old file was 11.5mb and the converted one is 2.2mb.
    This work around works for me but it will would be nice to know what is going on and to not need another program to open some files.
    I'm not sure if it was the issue was a wrong file type issue of just purely the file size?

    If you or anyone else wants more info to try and track down the issue let me know, till then I will just use the converter.

    Thanks for pointing in the right direction for a workaround:)

  • Ok, so it is in deed the ascii stl version that makes the trouble, most likely because of the double open. I will inverstigate the code to see if there could be a lock on the file from previous open.

    Just to be sure, the file is on the normal hard disk - not any network device whcih could have additional locking?
  • The stl is on my main hard drive, it is also a SSD drive so I dont this is a bottleneck.
    Im not sure what your talking about by double open or locked. If your talking about windows "this file is used by another program" kind of thing then i dont think that is the case. During my troubleshooting i have restarted my pc and done nothing else but open rep host and try to open the file.
    Thanks again for looking in to this.
  • Yes, thats what I mean with lock. For ascii files I close the file and immediately reopen it to read it in ascii mode. So maybe with the fat ssd the os has marked it still opened when the second open comes simply because the close was not completely handled by the os. Only a theory and my best since I have no ssd so I'm slower and have no locking there. I will see if I can switch to ascii reading without closing and reopening. That may help in this case.
  • I tried moving the STl file to a none SSD (same PC) with the same effect. I also installed another copy of RH 1.0.6 on to the none SSD also the same issue.
    Just to be clear I do get a progress bar that moves but I have to wait 5-7min before any progress is shown. It jumps to like 6% and after another 10min it will jump to 35% and so on. So it acts like it has it has access to the file its just really slow is all.

    Like I said I have a work around by using the Converter so this is not a big deal and it does not seem to be a widespread problem for people so I understand if you want to move on to other problems. However if you want to pursue this and need any feedback or want me to try something else feel free to ask.
  • Hi, I just encountered this same issue. I've just moved to an SSD (with fresh win7 install) and v1.0.6. Was previously using V1.0.5 on a normal drive so not sure which is the most pertinent factor. Exporting stls as binary rather than ascii solved the issue.

  • I have the same after moving Repetier to a new machine (No SSD but much faster drives/cpu) that all my old stl that I could load in a few secs now takes 10+ minutes, switching to binary fixed it but not ideal.

  • We tested it on a new computer with ssd with success. I think fast ssd/computer is one criterion, but there must be one more criterion to make it slow to reopen a file. I think I will prepare a test version with some changed handling and post it here for those having the problem, so we can see if it solves the problem. After all it seems to come from os + installed sftware that reopening a file gets delayed without reason. So all I can do is trying to find a trick that allow it again in a fast fashion.
  • Yes there will be more it it as I have 2 out of 3 have the same issue, 1 slow and 1 fast have the problem have the issue and the ok one is in between.
  • edited December 2014
    I got a new PC with a fresh Windows install, new H/W Motherboad, CPU, GFX card, RAM and Hard drive (still SSD).
    I have the same issue as before.
    I will check back later for a alternative version to test.
    Thanks again for looking in to this.
  • Hello,

    I'm having the exact same problem as mentioned above.
    I was wondering if anyone has ever managed to solve this problem, as there is no fix given is this topic.

  • So far we could not reproduce it. STL has analog and binary format. It seems like switching reading between the formats is the problem. I think binary STL files are fast but closing stream and reopening it directly afterwards is the problem for some machines. Unfortunately even our SSD machines do not have this problem.

    Can you confirm it is ascii stl that has the problems? You could open them in text editor and it will make sense.

    What OS/computer are you using and are files stored on local drives or on some remote drive?
  • Computer setup:
    Windows 7 x64
    Intel Core i7-3630QM
    6 GB RAM
    GeForce GT650M
    Samsung SSD 850 EVO 250GB

    I've tried two different STL's wich were about the same size

    Treefrog takes forever to load (30 min +), where #3DBenchy takes about 5 seconds.

    I searched for the difference between ASCII an binary STL in wikipedia and then opened the STL's in notepad
    The Treefrog is definately ASCII, starting with:

    solid Default
      facet normal -3.325848e-01 7.776186e-01 5.335698e-01
        outer loop
          vertex 1.052500e+01 -7.555001e+00 1.053128e+01
          vertex 1.062500e+01 -7.375001e+00 1.033128e+01
          vertex 1.013500e+01 -7.365001e+00 1.001128e+01
      facet normal 2.942300e-01 -8.051769e-01 -5.148970e-01
        outer loop
          vertex 1.013500e+01 -7.365001e+00 1.001128e+01
          vertex 1.020500e+01 -7.365001e+00 1.005128e+01
          vertex 1.052500e+01 -7.555001e+00 1.053128e+01
      facet normal -6.965671e-01 5.969890e-01 3.979930e-01
        outer loop
          vertex 1.013500e+01 -7.365001e+00 1.001128e+01
          vertex 9.795000e+00 -7.475002e+00 9.581279e+00
          vertex 9.775000e+00 -7.485001e+00 9.561279e+00
      facet normal -2.443190e-01 -8.703389e-01 4.275729e-01
        outer loop
          vertex 9.775000e+00 -7.485001e+00 9.561279e+00
          vertex 1.020500e+01 -7.365001e+00 1.005128e+01
          vertex 1.013500e+01 -7.365001e+00 1.001128e+01

    The #3DBechy I really don't know, it doesn't look like the examples on wikipedia at all:

    solid Shape0                                                                    ªq ù5¿    *¯ =mçÓ@   ¿ƒA“Ô@w¾Ÿ¿ žAmçÓ@    ƒA  ù5¿    *¯ =mçÓ@   ¿ƒAmçÓ@    ƒA
    ×Ó@   ¿ßOA  ù5¿ÕÁ&*¯ = Ó@¾Ÿš¿ÃõšA)\Ó@¤p¿j¼›AmçÓ@    ƒA  ù5¿†ª©¦*¯ =)@¤p¿j¼›A•Ó@d;Ÿ¿…œAmçÓ@    ƒA  ù5¿‚€%*¯ =mçÓ@    ƒA•Ó@d;Ÿ¿…œA
    ×Ó@   ¿ßOA  ù5¿@™è¦*¯ =ffÒ@¬Œ¿Â˜A¾ŸÒ@ÓM’¿Õx™AmçÓ@    ƒA  ù5¿Ì;ü¦*¯ =¾ŸÒ@ÓM’¿Õx™AHáÒ@yé–¿?5šAmçÓ@    ƒA  ù5¿fí'*¯ =mçÓ@    ƒAHáÒ@yé–¿?5šA Ó@¾Ÿš¿ÃõšA  ù5¿-Ž™§*¯ =ÁÊÑ@ßOm¿òÒ–AçûÑ@¤p}¿˜n—AmçÓ@    ƒA  ù5¿^·y¥*¯ =çûÑ@¤p}¿˜n—A?5Ò@Ý$†¿{˜AmçÓ@    ƒA  ù5¿£))'*¯ =mçÓ@    ƒA?5Ò@Ý$†¿{˜AffÒ@¬Œ¿Â˜A  ù5¿øŒ¥*¯ =ßOÑ@F¶3¿–C•AÕxÑ@'1H¿j¼•AmçÓ@    ƒA  ù5¿h+ª&*¯ =ÕxÑ@'1H¿j¼•AË¡Ñ@Zd[¿‰A–AmçÓ@    ƒA  ù5¿Ï7±'*¯ =mçÓ@    ƒAË¡Ñ@Zd[¿‰A–AÁÊÑ@ßOm¿òÒ–A  ù5¿Æî§*¯ =ÃõÐ@‰Aà¾-”AVÑ@®¿áz”AmçÓ@    ƒA  ù5¿ú–¦*¯ =VÑ@®¿áz”A/Ñ@?5¿Ù”AmçÓ@    ƒA  ù5¿Åâ€&*¯ =mçÓ@    ƒA/Ñ@?5¿Ù”AßOÑ@F¶3¿–C•A  ù5¿Å¸¦*¯ =ÍÌÐ@u“¾²“AþÔÐ@‘í|¾j¼“AmçÓ@    ƒA  ù5¿8Â’'*¯ =þÔÐ@‘í|¾j¼“A`åÐ@²¯¾‘í“AmçÓ@    ƒA  ù5¿2©q'*¯ =mçÓ@    

    The files are both stored on my local SSD, I also copied them to my conventional HDD but it made no difference.

  • I've used an online tool to convert the Treefrog to binary STL, the file now looks very similar to the 3#DBenchy, so that must have been binary.

    Also, the file now takes a few seconds to load, so if the problem proves hard to fix within Repetier Host this might be a nice work around.

    The online tool is available at
  • Converting is not the problem - i could read the ascii file in 2 seconds. I have made a patch that does not close the stream but rewinds it now. Could you try if this is also fast for ascii version. Download link is

  • Thanks for your help!

    I am printing some parts now, when it's done I'll install the patch and let you know!

  • I've uninstalled Repetier Host completely and reïnstalled the one in the link, unfortunately it didn't solve the problem.

Sign In or Register to comment.