ReplicatorG & Large STL Files

[sjlane7160]

Stephen Lane wrote:
       I have 1 computer 12mths old i7 16Gb RAM just upgraded to Win8Pro from Win7 & it can load 500Mb STL's & process them to gcode (takes about 20mins)

[sjlane7160]

So the complete message is
now I don't have a cat that arrived unannounced & managed to press the tab key & the return key in the correct order to post just the 1st line of description of the problem

On Sunday, 17 February 2013 05:39:04 UTC+10:30, sjlane7160 wrote:

Stephen Lane wrote:
       I have 1 computer 12mths old i7 16Gb RAM just upgraded to Win8Pro from Win7 & it can load 500Mb STL's & process them to gcode (takes about 20mins) using Repg39Sailfish

          I have a 2nd computer just built for a friend same basic spec (but faster with newer components) & it can't touch anything bigger than a 60Mb STL also using Repg39Sailfish
          the new computer is a fresh install with new download of Java, python & Sailfish, older one just brought everything forward.
          RepG stops functioning & then plays up on reload (which is solved by loading a simple file from the examples & shutting down & restarting) but I just can't get it to load the detailed STL & showing it a 500Mb one was a real waste of time its not the STL as I can open it in the old machine just fine & look at it in Repatier - Update Makerware also falls over too with the same files on the new PC but the old PC allows me to load & manipulate the 500+MB file

         Has anyone witnessed this behaviour & have a remedy I found what I thought was a reference from about 18months ago suggesting that it might have been the RAM put aside for Java but I have been into that & put a Gb away for that in its runtime variables & no I can't lower the size/resolution of the print, it is a "Lithophane" & the details what makes it work (500mb is a medium size I might add)

[Bill Culverhouse]

I don't have any help for you but I'd be interested in what you are printing that is a 500MB
STL.

That is easily way more detail than ever could be represented using a DIY printer
with even a .35mm nozzle

-b

--
You received this message because you are subscribed to the Google Groups "MakerBot Operators" group.
To unsubscribe from this group and stop receiving emails from it, send an email to makerbot+u...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

[Alex Huff]

obviously this isnt printable, but at work once I opened a half complete GM model of the XTS. it had all the wiring, windows, doors, everything except the drive train. it was 12GB. Took a top of the line dell with 32gb ram and a 500gb ssd 4 hours to open it in solidworks. incredible amount of data

[Doogiekr]

You were on track with the Java issue...

The problem is in RepG ... the front end is based in Java and it has a very small amount of memory allocated to it under windows (hard coded in the program, so not just a windows setting change).

This causes it to run out of memory when opening large files. I found the source of the problem in the program, but I don't know enough about programming in Java to fix it correctly.

I did cure it on my own machine by running RepG inside the ant programming environment and manually assigning more memory to it on opening, but in order to be fixed the right way, it will need to be fixed inside RepG's program code.

I originally thought that changing the amount allocated to it in the windows setting would fix it, but it seems that if it has hard coded values in the program, then that overrides whatever the windows default is even if its smaller.

[sjlane7160]

Stephen Lane wrote:
    I am printing what is called a Lithophane which is essentially a Photo converted to a Mesh - funnily enough the name of the program that does it is called exactly that you either print it Flat or wrapped into a shape & put a light behind it & you have the photo rendered in your print, the demo print is of Einstin's head & looks very detailed & is 30+Mb in size I grabbed just any old photo of my Wallpaper directory Lexa Doig as it turned out & created the 500Mb file I mentioned (more than willing to play with it to get the size down but thats not the point of this thread) anyway that big file loads, slices in RepG 39 Sailfish & prints (takes just on 2 mins to load half an hr to slice & 2 hrs to print) & when I showed the blokes at work they recognised the face from my Wallpapers (they didn't know the name tho.
    When I get home I will post a Photo & links

Regards
Stephen

[sjlane7160]

Stephen wrote
      Well actually it is printable & loadable because I have done it when I get home I'll post screen shots & the item.
       The point here is that 1 older computer that has been upgraded to Win8 can do it but a brand new (made for 48 hours with better speed etc) won't touch it. Very frustrating

Regards
Stephen

[sjlane7160]

Stephen wrote:
       Thanks for the confirmation on that I wonder what my older machine has over the new machine I too don't know much about programming in Java otherwise I would have a look myself. I'm not sure what to even compare now between old & new to see what might be allowing me to do it in the old machine not the old one.

Regards
Stephen

[Doogiekr]

Not sure... and it might not even be your problem with this model... but it is a problem in RepG. I tested it a bunch by slicing models (like the yoda bust) at lower layer heights (down to .05mm) to get the files size to grow until it locked up the regular RepG ... then I would open RepG in ant and force more memory to the JVM when it opened and it could open the bigger STLs with no issue at all.

Also if you run RepG inside ant without increases the Java allocation, it shows the out of memory errors when it locks up loading large stl files (since normal RepG doesn't tell you anything, it just freezes)

Anyway.... if there are any Java programmers out there that wanna mess with it, I think i got it tracked down to the build files for Java in RepG

In github its in this file ReplicatorG / build / windows / launcher / ReplicatorG.xml

Specifically lines 35 and 36 .... for me, when I run it in ant, i force it to load with 2048 max instead of 750 and that seems to cure all of the lockups so far. But for programming it, I think there would need to be some sort of option to change it in RepG in case someone wanted to use more memory, or less memory. (and on a side note... I tried just changing the windows default for Java to 2048, but RepG's JVM opens with its own limits... so those need to be changed)

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39

<launch4jConfig>   <dontWrapJar>true</dontWrapJar>   <headerType>gui</headerType>   <jar>lib\ReplicatorG.jar</jar>   <outfile>ReplicatorG.exe</outfile>   <errTitle></errTitle>   <cmdLine></cmdLine>   <chdir></chdir>   <priority>normal</priority>   <downloadUrl>http://java.com/download</downloadUrl>   <supportUrl></supportUrl>   <customProcName>false</customProcName>   <stayAlive>true</stayAlive>   <manifest></manifest>   <icon>application.ico</icon>   <classPath>     <mainClass>replicatorg.app.Base</mainClass>     <cp>./lib</cp>     <cp>./lib/j3dcore.jar</cp>     <cp>./lib/j3dutils.jar</cp>     <cp>./lib/jcommon-1.0.16.jar</cp>     <cp>./lib/jfreechart-1.0.13.jar</cp>     <cp>./lib/miglayout-3.7.4.jar</cp>     <cp>./lib/mrj.jar</cp>     <cp>./lib/RXTXcomm.jar</cp>     <cp>./lib/vecmath.jar</cp>     <cp>./lib/filedrop.jar</cp>     <cp>./lib/ReplicatorG.jar</cp>   </classPath>   <jre>     <path>java\</path>     <minVersion></minVersion>     <maxVersion></maxVersion>     <jdkPreference>preferJre</jdkPreference>     <initialHeapSize>256</initialHeapSize>     <maxHeapSize>750</maxHeapSize>     <opt>-D32</opt>   </jre> </launch4jConfig>

[Joseph Chiu]

Oh, ok, now I don't feel so bad about my CAD model of an optical test system that took 5 minutes to open on my laptop...

[sjlane7160]

Stephen wrote:
            Thanks for that info a nice outcome would be for Dan & Jetty to build the bigger environment into RepG Sailfish as they obviously have the building of RepG down to a fine art and its one of the most usable versions of RepG.
            In the mean time I have downloaded the Statue of Liberty Lithophane that went up on TV a couple of days ago the interesting thing I noted the original file is 39Mb & it doesn't open in the middle of the build area when you move it & save it as RepG wants to do after a move the file size sky rockets to 135Mb no changes just a move so I don't know whats going on there & tried another one made from the Photo to Mesh prog the stl made by the prog was 120Mb then after the move it grew to 515Mb ????? I can still slice & print it but the size jump really puzzles me can anybody offer suggestions ???

Regards
Stephen

[Jetguy]

One word- Netfabb.
http://www.netfabb.com/getatrial.php
Simply open the STL, Repair it, reduce the resolution, then export
STL.

One tool and done.

> > In github its in this file ReplicatorG <http://makerbot/ReplicatorG> /
> > build <http://makerbot/ReplicatorG/tree/master/build> / windows<http://makerbot/ReplicatorG/tree/master/build/windows>/
> > launcher <http://makerbot/ReplicatorG/tree/master/build/windows/launcher>/
> > *ReplicatorG.xml*

> >>>> it work (500mb is a medium size I might add)- Hide quoted text -
>
> - Show quoted text -

[sjlane7160]

Stephen wrote:
         I thought of that but I couldn't work out how to reduce the resoloution, I can open it in Netfabb repair it & if I save it it appears to go from 500mb back to 120mb but still un usable on one machine but Ok on another - I couldn't see how to reduce the resolution even though some form of reduction obviously occoured

Thanks for the idea though, I am sure the resoulution thing will jump out at me eventually unless its in the paid version of netfabb.

Regards
Stephen

[Doogiekr]

Actually, Dan and Jetty have enough on their plate already... Pretty sure they just add the needed drivers to RepG for Sailfish and try to stay out of the rest.

I think the main RepG is controlled by MBI but I could be wrong. If so then it should be an MBI fix, if not then I guess we need to figure out who to contact for fixes...

This is all based on if the item slices fine and just crashes RepG when loading the visual preview... If it crashes while slicing, then its likely not a RepG/Java issue...

[Dan Newman]

On 20 Feb 2013 , at 6:55 PM, Doogiekr wrote:

> Actually, Dan and Jetty have enough on their plate already... Pretty sure they just add the needed drivers to RepG for Sailfish and try to stay out of the rest.

Yes.

> I think the main RepG is controlled by MBI but I could be wrong.

I suspect that MBI is trying to wash their hands of RepG. However, it never hurts
to ask (them). To me, the underlying problem is that RepG has Object Oriented Disease
coupled with an untuned JVM.

Dan

[CtrlKX]

I can shed a little light on the STL file size changing.....
An STL file can be stored in 2 main formats..
1. Ascii (Human Readable Text) is stored directly in the file like an xml or csv file. Basically you can open the file with notepad to read the text.
2. Binary, Instead of human readable ascii numbers, the numbers are converted into binary floating point numbers which the CPU can understand and use directly.

Ascii files are usually ALOT bigger then the binary versions, sometimes 5 times larger.
Binary versions can be loaded much quicker then the ascii version, because ascii versions must be converted to binary anyway (which MUST happen for the CPU to do ANYTHING with it)

Now RepG can open either ascii or binary formats, however will only save in ascii format!!
If it was me I would force RepG to always save in binary format. But this can not be done by the end user,,.. it's hard programmed.

I found this thread because I am having the same issue with file sizes... and RepG for me will not load a gcode file over 20meg!
I thought the info regarding ascii/binary versions of STL files was relevant to this thread...

I will try Netfabb to reduce the resolution of the STL and try again..
My other option is to use the SDCARD to print off... this would be the easiest...
I may even write my own program to send and handle the S3G commands to and from the printer, this way the file size can be any size and it will work....
There is no reason to load the entire file into memory, even though with today's computers this is indeed an easy task....
The problem is always with the memory management of the program in question, and I hate it when a program does not tell you it is having a memory issue....

[Dan Newman]

On 24 Jul 2013 , at 8:03 PM, CtrlKX wrote:

> I can shed a little light on the STL file size changing.....
> An STL file can be stored in 2 main formats..
> 1. Ascii (Human Readable Text) is stored directly in the file like an xml
> or csv file. Basically you can open the file with notepad to read the text.
> 2. Binary, Instead of human readable ascii numbers, the numbers are
> converted into binary floating point numbers which the CPU can understand
> and use directly.
>
> Ascii files are usually ALOT bigger then the binary versions, sometimes 5
> times larger.
> Binary versions can be loaded much quicker then the ascii version, because
> ascii versions must be converted to binary anyway (which MUST happen for
> the CPU to do ANYTHING with it)
>
> Now RepG can open either ascii or binary formats, however will only save in
> ascii format!!
> If it was me I would force RepG to always save in binary format. But this
> can not be done by the end user,,.. it's hard programmed.
>
> I found this thread because I am having the same issue with file sizes...
> and RepG for me will not load a gcode file over 20meg!

Yes, but this has nothing to do with the format of the STL file and rather
is because every semantically significant line of gcode, RepG instantiates an
object. And, RepG first must digest the entire gcode file before it will
translate it to s3g/x3g. For large gcode files, RepG overflows the maximum
allowed 32bit Java heap size (2 GB on OS X and Linux; about 1.4 GB on Windows).
Indeed, the "standard" RepG only allows a maximum heap size of 750 MB and
thus is further handicapped.

> I may even write my own program to send and handle the S3G commands to and
> from the printer, this way the file size can be any size and it will

> work….

Look into Wingcommander's GPX tool. It is a gcode to s3g/x3g converter
which is quite fast and lightweight. It does not have these size constraints.

Dan

[CtrlKX]

Yes i'm aware the file format of stl or any other file type is not of question.
I just wanted to clear the air regarding previous unanswered questions and provide further relevant detail about the STL file size changing :)

Thank you for the suggestion to try Wingcommander's GPX tool. I will look into this.

Regards, Dean.

On Friday, July 26, 2013 12:01:08 AM UTC+10, dnewman wrote:

Yes, but this has nothing to do with the format of the STL file and rather
is because every semantically significant line of gcode, RepG instantiates an
object.  And, RepG first must digest the entire gcode file before it will
translate it to s3g/x3g.  For large gcode files, RepG overflows the maximum
allowed 32bit Java heap size (2 GB on OS X and Linux; about 1.4 GB on Windows).
Indeed, the "standard" RepG only allows a maximum heap size of 750 MB and
thus is further handicapped.