Re: ReplicatorG 0040 hangs at Toolpath generation

[Jetguy]

Lots of times, it's a fault in the STL file. Did you make it yourself
or download it?
An STL is a 3d point cloud of connect the dots. If walls do not
intersect, then it is not manifild (aka water tight) skinned and thus
the carving prgram has issues in connecting things to fill in the area
when the point cloud has errors. When this happens, it easy to use
Netfabb online STL repair wich does DRC(design rules checks).
http://www.netfabb.com/stl_repair_fixing.php

The actual online repair site: http://cloud.netfabb.com/

On Nov 20, 2:23 pm, Arkady Tan <arkady...@gmail.com> wrote:
> Hi Guys,
> hope someone can help with this prob.
> 3D Printer: Replicator 2
> ReplicatorG Version: 0040
>
> I'd installed ReplicatorG 0040 and printed from SD successfully for a few
> times.
> But just know when I tried to generate the Gcode, it stopped during
> generating toolpath.
> The Total Progress bar does not reach 100% but at the bottom, it states
> that the file was exported. A seperate window showing the Skeinlayer will
> be opened and if I close it, the generating toolpath dialog will close.
>
> If I continue to Build file for SD card, the result will be a 1kb file. See
> attached Water Pipe Cover repg.s3g
>
> I changed the settings  to Skeinforge 47 and it worked fine and produces
> Water Pipe Cover repg2.s3g.s3g
>
> Can anybody advise on what went wrong?
> Thanks in advance :)

[Arkady Tan]

Hi Jetguy, the same stl file can be processed by Makerware. I also tried with stl files that I'd printed before.

[Arkady Tan]

Did a reinstall of ReplicatorG.
Seems to solve the problem :)

[Darrell jan]

Hmm, I had very similar behavior when I was trying to use Multiply. See 

 

https://groups.google.com/forum/#!searchin/makerbot/darrell/makerbot/wWzVgRovebM/9qQl74rNRY4J

Dan told me "You likely exceeded virtual memory for Java on your platform...."

But maybe I should try reinstalling.

[Doogiekr]

If it is... "You likely exceeded virtual memory for Java on your platform...."  then reinstalling will not help... it is coded into RepG (for the windows version anyway, not sure about other OS) ... I have fixed the issue on my own copy of RepG but I have had no luck being able to rebuild the code for others to use. I was gonna mess with it some more this week, but after that I think I am going to give up and just hope makerbot fixes it for the rest of you guys someday...

[Dan Newman]

On 20 Nov 2012 , at 6:00 PM, Darrell jan wrote:

> Hmm, I had very similar behavior when I was trying to use Multiply. See
>
>
>
> https://groups.google.com/forum/#!searchin/makerbot/darrell/makerbot/wWzVgRovebM/9qQl74rNRY4J
>
> Dan told me "You likely exceeded virtual memory for Java on your

> platform…."

And that was based upon my understanding that for you the gcode got to about 99%
done suggesting that SF ran fine and you were stuck at the step where RepG tries
to read it all back in. When RepG hangs or dies there for a large amount of
gcode, then it's often Java running out of virtual memory. (And since you're
using multiply, there's going to be more gcode than usual for that model.)

Did you follow my suggestion of trying multiply with something small and
simple such as the 20 x 20 x 10 calibration cube?

Dan

[Darrell jan]

I just returned from travel to try this. Even with just the 20 mm calibration example, the same thing happens. The window says "It took 16 seconds to export the file", but the Total progress is stuck at what looks like 90% or so. 

One this new, or that I didn't notice before, is that a Python window popped open, labelled "20 mm_Calibration_Box_export.gcode - Skeinlayer" with what appears to be a graphic of the tool path.

Darrell

[Darrell jan]

When I closed the Python window, the gcode finished! But the 1x2 file didn't make anything. However, 2x2 did print out 4 cubes.

[Dan Newman]

On 21 Nov 2012 , at 8:48 AM, Darrell jan wrote:

> When I closed the Python window, the gcode finished! But the 1x2 file
> didn't make anything. However, 2x2 did print out 4 cubes.

Are you still using Python or did you switch to PyPy? If you did switch
to PyPy, then you may want to try going back to Python. If things then
work better with Python, then this may be some glitch with the build
of PyPy you are using and your operating system. (The PyPy I use works
just fine for me on OS X 10.7.5.)

Dan

[Dan Newman]

> One this new, or that I didn't notice before, is that a Python window
> popped open, labelled "20 mm_Calibration_Box_export.gcode - Skeinlayer"
> with what appears to be a graphic of the tool path.

That's enabled by editing the slicing profile,

Selecting "analyze" instead of "craft"
Activating either "skeinlayer" (2d view) or "skeiniso" (3d view).
If you have either of those activated, then that may be your problem: RepG
doesn't believe that the print has finished slicing until those viewers
fire up and then you exit them. That's because SF is waiting for them
to exit before it declares itself done.

Dan

[Darrell jan]

I guess that must be it. Not knowing what those were, I must have hit it by accident. Another case of operator malfunction!

Thanks.

[Arkady Tan]

The problem is back again.
I'd submitted a support ticket to ReplicatorG ticket #335