RepG 40r16 - Sailfish @ dropbox

[Dan Newman]

We've just uploaded to dropbox RepG 40r16 - Sailfish:

OS X: https://www.dropbox.com/s/wow33oxms4j8lrj/replicatorg-0040r16-mac.dmg
Linux: https://www.dropbox.com/s/xg8lwcdveoi7n9f/replicatorg-0040r16-linux.tgz
Windows: https://www.dropbox.com/s/25xj6364f7pfhle/replicatorg-0040r16-windows.zip

1. Support for M322, a new "pause @ Zposition" mcode

2. delsydsoftware's revised SF-50 Fill plugin, http://www.thingiverse.com/thing:65624 .

3. Start & end gcode files as well as replace.csv files have been converted to Vol 5D;
no more use of RPM-related commands. Note that M108 Tn may still be used to select
the active extruder/tool.

4. Like r15, the fix fo the RPM bug which Wingcommander uncovered in RepG.

As regards 3, if you have custom start or end gcode files, then please update them
to no longer use RPM. If you have a custom replace.csv, update it to comment out both

M108 R

and

M108 S

But do not comment out M108 in general. If you are still using SF-47 or earlier
AND using RPM, then now is the time to switch to Vol 5D. (Note that SF-50 is
Vold 5D only, unless you were clever and somehow figured out how to do RPM
with it somehow.)

Dan

[Fastrack]

Downloading... Can't wait to try it.

Ben

[Martin Bogomolni]

Downloaded.

On Fri, Apr 19, 2013 at 7:35 PM, Fastrack <benjami...@gmail.com> wrote:
> Downloading... Can't wait to try it.
>
> Ben
>

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

[DronE Pump]

I have encountered an interesting anomaly with RepG - I was using RepG40r13 and I do not expect this is peculiar to that version only so I thought I would pose the question here. 

I only discovered this Sat when I sliced a fairly complex file which produced a 120Mb Gcode file but did not offer the usual option to write out the x3g file.  When I looked at the log it was evident that Skeingorge had completed writing the file and then crashed.  A further look at the gcode yielded no insights, The gcode file could be opened and saved but interestingly, could not be read into RepG - every time I attempted to read it RepG would begin then go nowhere.

I thought this was very curious and I had not encountered it before.  As I write this I am visited by the eerie feeling that I may read something in the past related to this...oh oh - don't tell me this may be resolved by using the "large files" option.:-P

[Dan Newman]

On 21 Apr 2013 , at 3:22 PM, DronE Pump wrote:

> I have encountered an interesting anomaly with RepG - I was using RepG40r13
> and I do not expect this is peculiar to that version only so I thought I
> would pose the question here.
> I only discovered this Sat when I sliced a fairly complex
> file which produced a 120Mb Gcode file but did not offer the usual option
> to write out the x3g file. When I looked at the log it was evident that
> Skeingorge had completed writing the file and then crashed. A further look
> at the gcode yielded no insights, The gcode file could be opened and saved
> but interestingly, could not be read into RepG - every time I attempted to
> read it RepG would begin then go nowhere.
> I thought this was very curious and I had not encountered it before. As I
> write this I am visited by the eerie feeling that I may read something in
> the past related to this...oh oh - don't tell me this may be resolved by
> using the "large files" option.:-P

The large models option is only relevant on Windows.
On OS X, RepG uses request the maximal heap size possible for a 32bit JVM -- 2 GB.
On Linux, you would edit the replicatorg shell script and toss in a "-Xmx 2048M" switch to
get a heap which can grow to 2GB.

Mind you, for 120MB of gcode, 2GB may not be sufficient. I don't know offhand.
However, it certainly sounds like the issue was that RepG could not get enough
VM to handle that amount of gcode. Mind you, that's not a lot of gcode IMO.
However, RepG likes to turn it all into Java object instantiations, and that
does gobble up memory.

Dan

[DronE Pump]

I should have said that I am running RepG in Windows earlier.  So is there some threshold size that one can apply to these things?  How does one know that the model in question is too big for std (default) RepG? Why would a Windows user need to run RepG (default at all)?  I am thinking why not simply run the large files option all the time....I mean if your Win environment has 32Gb RAM then where is the problem?

[Dan Newman]

On 21 Apr 2013 , at 3:40 PM, DronE Pump wrote:

> I should have said that I am running RepG in Windows earlier. So is there
> some threshold size that one can apply to these things?

I suppose someone with sufficient interest could work it out, but I haven't.
Different Java objects for the gcode will have different sizes, but I'm sure
that there's a rough rule of thumb: start/end takes up about X bytes and then
everything in between is some rough multiplier of the number of lines of gcode.

> How does one know
> that the model in question is too big for std (default) RepG? Why would a
> Windows user need to run RepG (default at all)?

Because Windows is, well, Windows. Some folks have some sort of environmental
issue which causes replicatorg-large-models.exe to not run for them. Something
may appear in the java console log or windows event log, but since it doesn't
die on me, I cannot tell. (I'v

Dan

[DronE Pump]

Ok.  Thanks for these insights.  I am now going to do 2 things.

a) I will start running RepG (large models) only and monitor/document the behaviour.

b) Install RepG in my Kubuntu environment (probably should have done this earlier but like most others the convenience of windows as a work supplied tool makes one lazy).

[Jwo Fox-Lee]

I've regularly sliced 130+mb GCode files with RepG 0040r13 and PyPy on a MacBook Air with 4GB ram.

- Jwo Fox-Lee

  Sent from my iPad

--

[Dan Newman]

On 21 Apr 2013 , at 3:53 PM, DronE Pump wrote:

> Ok. Thanks for these insights. I am now going to do 2 things.
> a) I will start running RepG (large models) only and monitor/document the
> behaviour.

And yes, there are Java heap visualization tools. I don't know how much
the uncertainty principle applies to them though as I've never used them
myself. (Actually, I used one once: to see for myself that the
large model version was truly running with -Xmx 1400M. Unfortunately,
on Windows 1.4G is the largest you are assured of being able to ask
for. Dunno why. Just read it on the Oracle web page. Just because
I have a Sun badge doesn't mean I know anything about Java.)

Dan

[DronE Pump]

" Just because I have a Sun badge doesn't mean I know anything about Java.""

Must get me one of those :P

Java heap visualization tools.....sounds like a plan to me.  As for the uncertainty principle, well I don't have a cat so I nothing to worry about there.

[Eighty]

> As for the uncertainty principle, well I don't have a cat so I nothing to worry about there.

Never understood the choice of a cat for that analogy. Since all they do is sleep, one can never tell if a cat is alive or dead anyways. Unless it's giving you the evil eye...

[Dan Newman]

>
> Java heap visualization tools.....sounds like a plan to me. As for
> the uncertainty principle, well I don't have a cat so I nothing to worry
> about there.

Maybe we just have to go with the many worlds interpretation: there's
a world in which you DO have a cat.

Dan

[DronE Pump]

The only reason I can offer is that of emotional attachment (you are more likely to want to think about the welfare of your pet).  While they could have employed a reference to a rat - I rather suspect that had they done so, no one would have given a rats @#ss what happened to the animal.

[sjlane7160]

Stephen Lane wrote:
    Hi Dan just an update that may have some bearing on this the 64bit version of RepG You & Kobus worked on a few weeks ago has helped immensly  with the slicing of big STL files(so a belated thanks for those efforts)  (although nothing I've done has created excessive (120mb) gcode) really big 200mb plus(stl's) still allude me & the interesting thing is that a Win7 machine using a bog standard RepG with no mods will still slice & gcode 490mb stl's (the gcode for these files doesn't exceed 30mb so) Anyway the point is that the 64bit stuff you & Kobus furnished may be worth trying.

Regards
Stephen

[IVIUPPET]

Hi,

It appears that the Windows link is no longer working, Dropbox returned its 404 page aka the file has been moved.  Could you post new links or put it on google code please?

[Dan Newman]

On 15/08/2014, 8:37 AM, IVIUPPET wrote:
> Hi,
>
> It appears that the Windows link is no longer working, Dropbox returned its
> 404 page aka the file has been moved. Could you post new links or put it
> on google code please?

Once the __fill in the blank__ is uploaded to Thingiverse, I remove it from
Dropbox. Dropbox is just used to distribute the large files when they are
in beta test.

So, please go to the Sailfish Thing at thingiverse if you are looking
for RepG 40r28 - Sailfish.

Dan

[Dan Newman]

On 15/08/2014, 11:49 PM, rblakemesser wrote:
> The links seem to be rotten

Beta test software is only kept around for about a month or two before either
being pushed out to thingiverse as "official" OR being replaced by even newer
beta test software. You are here asking after software which is well over a
year old and long ago replaced by much newer software.

Please go to the Sailfish Thing at thingiverse.com. If for some reason you
truly need RepG 40r16 - Sailfish, you will have to use github to pull the
sources from about that point in time (April 2013) and build it yourself.
That will require having a Java JDK installed (free from Oracle). You may
also have to install "ant" if your platform of choice does not include it.

Dan

[IVIUPPET]

Ah, I didn't think of checking the thing files when I was there, I swear it only lets me upload .stl or .obj.

Thanks