Asked — Edited

3D Model Files Not Working

I've been trying to work with the STL files from the official ARC team, but for whatever reason they're downloading as .htm files. The file itself seems to contain STL data, but there's a bit of HTML at the bottom, and opening it in any 3D Modeling software crashes the program, even after removing the extra stuff at the bottom. Has anyone else experienced this or know what to do about it?

Example:

solid P22_HD L Multi Female Bracket_R02 (Mar 26, 2014) öÿþYøúõùA4-A >â-úAuAÚ>A4-AöÿþYøA4-A >â-úAuA/ù=ÄAÚAöÿþYøAÒäArþaAÂAöÿþYøaAÂA> AAöÿþYøA4-AöÿþYøA4-ArþA4-ArþðíA


ARC Pro

Upgrade to ARC Pro

Your robot can be more than a simple automated machine with the power of ARC Pro!

#1  

The issue is with the 3D model printing files that appear to be corrupted.

PRO
Synthiam
#2  

Where are you experiencing this happening? We are unable to reproduce the situation.

#3  

If it saves as the wrong file Ext try renaming it .stl , if the data is the same maybe that will fix the issue, otherwise maybe you are saving the web page instead of the model

edited for poor grammar, thanks Iphone

PRO
Synthiam
#4  

Yah i think that's what the poster is doing - right clicking and saving as rather than pushing the button to download?

#5  

No, I'm pushing the download button. The file shows up as (whatever number).stl.htm, and the computer thinks it's an HTML file with '.stl' in the name. There's also this bit of code at the bottom of the file, which is why it seems to be saving as .htm.

<!DOCTYPE html>

<html xmlns="http://www.w3.org/1999/xhtml">; <head><title>

</title></head> <body> <form method="post" action="./4adea126-fdc8-4816-adc2-a1182f35e742" id="form1"> <div class="aspNetHidden"> <input type="hidden" name="__VIEWSTATE" id="__VIEWSTATE" value="/wEPDwULLTE2MTY2ODcyMjlkZDNgYzOx8OXzI65o9rolQJhMjmFS7tWXE8lN4jnoM1bh" /> </div>

<div class="aspNetHidden">

&lt;input type=&quot;hidden&quot; name=&quot;__VIEWSTATEGENERATOR&quot; id=&quot;__VIEWSTATEGENERATOR&quot; value=&quot;5F06ECA4&quot; /&gt;

</div> <div> </div> </form> </body> </html>

#6  

I too have tried to download and run several .stl files ( Six & JD) and I am unable to open any of them in Cura. If the files are ok then what am I doing wrong for future reference.

Thanks

#7  

Hello all,

Great discussion so far! :) Thanks for all the help.

My observations:

  1. When downloading any file from the Community 3D Printing store, the .stl that is downloaded after clicking the "Download STL" button results in an .stl file being downloaded, but named incorrectly. Below are some examples of the file intended to be download vs. the file that was actually received:

A. Hexapod Dome.stl -> 4adea126-fdc8-4816-adc2-a1182f35e742.stl B. P207 A-01.STL -> 86819d3a-aa3d-4d20-a6d6-0a39f7191ee9.stl C. P6 A-01.STL -> 513c837e-1cee-4997-936c-bf1eef667edb.stl

  1. When attempting to open these files, I receive these errors in the following programs:

A. Windows 3D Builder: Couldn't load that (Error code: 0x80004005) B. MakePrintable: Unable to load file C. NetFabb: FAILED: failed to load mesh (invalid STL file)

  1. I've attempted to download the files using the following browsers:

A. Google Chrome B. Firefox C. Internet Explorer

The combination of the hashed name when downloading, the inability to open the file across multiple 3D modeling programs, and the consistency of the issue across browsers leads me to believe there must either be an issue where the file is hosted. I'm able to download and successfully open .stl files from other sources (thingverse / grabcad / pinshape).

Let me know if there's anything else I should be trying -- or maybe something simple that I'm missing:)

I appreciate the help,

Brian

PRO
Synthiam
#8  

Are you using a downloaded browser extension? We are unable to reproduce this situation with any browser we test with. All tests of downloading and loading stl files work on our end. Let’s find out what you got running and get you roboting:)

What extensions? Firewall? Proxy? What links are you downloading from? Etc etc

Loading...