SD card Feature hassle

[hisashime]

Hi Dan,

I find it troublesome pulling in and out my SD card from my TOM whenever I need to generate a .s3g with RepG. Is there a way to directly generate it to the SD card on the TOM? If no, will it be a new feature in future firmware?

[Luis E. Rodriguez]

Build to file and copy to SD is the fastest way. It's way too slow over USB, it's been a feature since the first RepG. Stop being lazy. :)

Luis E. Rodriguez

On Feb 23, 2013, at 12:39 AM, hisashime <hisa...@gmail.com> wrote:

Hi Dan,

I find it troublesome pulling in and out my SD card from my TOM whenever I need to generate a .s3g with RepG. Is there a way to directly generate it to the SD card on the TOM? If no, will it be a new feature in future firmware?

--
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.
 
 

[David Lancaster]

Yeah...while the capability to copy the file to the SD card over USB was occasionally useful when testing *really* small prints...the speed was atrocious.  Anything of any decent size took well over 20 minutes...

D.

[hellphish]

Mount a card reader to your bot. Then you don't have to walk as far.

[hisashime]

On Sunday, February 24, 2013 11:44:01 PM UTC+8, hellphish wrote:

Mount a card reader to your bot. Then you don't have to walk as far.

The BOT has a reader.

On Sat, Feb 23, 2013 at 5:09 AM, David Lancaster <dar...@gmail.com> wrote:

Yeah...while the capability to copy the file to the SD card over USB was occasionally useful when testing *really* small prints...the speed was atrocious.  Anything of any decent size took well over 20 minutes...

D.

On Sat, Feb 23, 2013 at 3:07 AM, Luis E. Rodriguez <lrodrig...@gmail.com> wrote:

Build to file and copy to SD is the fastest way. It's way too slow over USB, it's been a feature since the first RepG. Stop being lazy. :)

Luis E. Rodriguez

I was advice to use SD card to print my build, that is why USB was abandoned since I am having packet loss problem. I am gen .s3g in repG and copy it to SD through my SD Reader. Then unmounting it and then plugging it to TOM. I have to do keep pulling the SD card in and out every test print of my build. Don't u think its frustrating. I am not being lazy. :(

[Jetguy]

Yes, we know for small jobs, swithing SD cards is not fast or
efficient. Just print from USB.

Part 2, the CODE is in Replicator -G so your complaining to the wrong
person/group. GO to rep-g site and put in a feature request
http://replicat.org/reporting-bugs

Part 3, even when enabled, it sucks. DO NOT USE

Dan is not going to drop everything and enable this. Even in the few
rare usage cases where it was helpful, the performance and code space
issues in the firmware to handle this correctly are not worth fighting
for other performance factors. This has been brought up before and
discussed and shot down.

As far as I can remember last (you can search for this ) the firmware
will accept the commands so that means it's disabled in Replicator-G,
not the Firmware.
You can revert to older, non-Sailfish firmware and a much older
version of Replicator-G if you MUST have this functionality.

Older versions:
http://code.google.com/p/replicatorg/downloads/list

On Feb 25, 2:05 am, hisashime <hisash...@gmail.com> wrote:
> On Sunday, February 24, 2013 11:44:01 PM UTC+8, hellphish wrote:
>
> > Mount a card reader to your bot. Then you don't have to walk as far.
>
> The BOT has a reader.
>
>
>
>
>
>
>

> > On Sat, Feb 23, 2013 at 5:09 AM, David Lancaster <dar...@gmail.com<javascript:>

> > > wrote:
>
> >> Yeah...while the capability to copy the file to the SD card over USB was
> >> occasionally useful when testing *really* small prints...the speed was
> >> atrocious.  Anything of any decent size took well over 20 minutes...
>
> >> D.
>

> >> On Sat, Feb 23, 2013 at 3:07 AM, Luis E. Rodriguez <lrodrig...@gmail.com<javascript:>

> >> > wrote:
>
> >>> Build to file and copy to SD is the fastest way. It's way too slow over
> >>> USB, it's been a feature since the first RepG. Stop being lazy. :)
>
> >>> Luis E. Rodriguez
>
> I was advice to use SD card to print my build, that is why USB was
> abandoned since I am having packet loss problem. I am gen .s3g in repG and
> copy it to SD through my SD Reader. Then unmounting it and then plugging it
> to TOM. I have to do keep pulling the SD card in and out every test print
> of my build. Don't u think its frustrating. I am not being lazy. :(
>
>
>
>
>

> >>> On Feb 23, 2013, at 12:39 AM, hisashime <hisa...@gmail.com <javascript:>>

> >>> wrote:
>
> >>> Hi Dan,
>
> >>> I find it troublesome pulling in and out my SD card from my TOM whenever
> >>> I need to generate a .s3g with RepG. Is there a way to directly generate it
> >>> to the SD card on the TOM? If no, will it be a new feature in future
> >>> firmware?
>
> >>> --
> >>> 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 <javascript:>.
> >>> For more options, visithttps://groups.google.com/groups/opt_out.

>
> >>>  --
> >>> 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 <javascript:>.
> >>> For more options, visithttps://groups.google.com/groups/opt_out.

>
> >>  --
> >> 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 <javascript:>.
> >> For more options, visithttps://groups.google.com/groups/opt_out.- Hide quoted text -
>
> - Show quoted text -- Hide quoted text -
>
> - Show quoted text -

[Jetguy]

Sorry if it seemed I was rude, but again, the topic has been discussed
before, and due to many technical factors shot down. If you really
need it, then you can:

Compile Rep-G from source and edit the flag to enable writing
File a request with Rep-G folks
Revert to other non-Sailfish versions.

Maybe, using an old version of Rep-G with the right SF profiles will
work for printing. Dan had to add a lot of Sailfish specific configs
to be able to flip all the settings in firmware and such, but that
shouldn't affect printing that I am aware of. To SD card, it's just
the X3G compile function anyway. SF does the lifting of gcode
creation.

This brings up a second concern. You said S3G but really hoping you
meant X3G as running s3gs means no acceleration, why bother running
Sailfish firmware?
In other words, you ahd better be saving to x3g at export.

On Feb 25, 3:21 pm, Jetguy <vernonbar...@gmail.com> wrote:
> Yes, we know for small jobs, swithing SD cards is not fast or
> efficient. Just print from USB.
>
> Part 2, the CODE is in Replicator -G so your complaining to the wrong

> person/group. GO to rep-g site and put in a feature requesthttp://replicat.org/reporting-bugs

> > >> For more options, visithttps://groups.google.com/groups/opt_out.-Hide quoted text -

[Dan Newman]

Jetguy wrote:
> Yes, we know for small jobs, swithing SD cards is not fast or
> efficient. Just print from USB.
>
> Part 2, the CODE is in Replicator -G so your complaining to the wrong
> person/group. GO to rep-g site and put in a feature request
> http://replicat.org/reporting-bugs
>
> Part 3, even when enabled, it sucks. DO NOT USE
>
> Dan is not going to drop everything and enable this. Even in the few
> rare usage cases where it was helpful, the performance and code space
> issues in the firmware to handle this correctly are not worth fighting
> for other performance factors. This has been brought up before and
> discussed and shot down.
>
> As far as I can remember last (you can search for this ) the firmware
> will accept the commands so that means it's disabled in Replicator-G,
> not the Firmware.
>

Yes, Sailfish still supports "SD card capture" in which the USB host (RepG)
sends bytes to be written to the SD card loaded into the bot. MBI removed
the host end of that feature in November of 2011,

https://github.com/makerbot/ReplicatorG/commit/0c932d34055ccec7ba8b832831c6ceb64f74bdeb#src/replicatorg/app/ui/MainButtonPanel.java

So you will need to fall back to ReplicatorG 27 or earlier to regain that
functionality. Problem is, none of the accelerated firmwares support
anything earlier than RepG 29. (Yes, I'm sure there's someone out
there successfully using RepG 28 with Jetty 3.5. I don't need to
hear about it ;)

But, even if we wanted to support this in Sailfish, it would be UGLY.
The s3g/x3g protocol limits "packets" to 32 bytes. And, it's a command
response protocl. So, you send 32 bytes over the 57600 Baudot connection,
then wait for a response, and send another 32, bytes. Repeat. While
it only takes around 1/225 seconds to send those 32 bytes, the SD card
writing is not in bulk mode and is not terribly fast either. And the
firmware isn't using a comms interrupt and thus isn't as responsive as
you'd like. So, my guess is that you will maybe see 320 bytes written
per second. Maybe as much as 640 bytes? A 20 x 20 x 10 mm calibration
cube sliced at 0.3 mm with partial infill is ~175 Kbytes. So that's
about 4.7 minutes to
transfer. However, that's also around the time it takes to print the cube.
It just is not practical.

Dan

Dan

[hisashime]

Thanks Guys for the great explanation. Thanks Dan for full technical explanation. At least now I know what is best.

[hisashime]

On Tuesday, February 26, 2013 4:30:18 AM UTC+8, Jetguy wrote:

Sorry if it seemed I was rude, but again, the topic has been discussed
before, and due to many technical factors shot down. If you really
need it, then you can:

Compile Rep-G from source and edit the flag to enable writing
File a request with Rep-G folks
Revert to other non-Sailfish versions.

Maybe, using an old version of Rep-G with the right SF profiles will
work for printing. Dan had to add a lot of Sailfish specific configs
to be able to flip all the settings in firmware and such, but that
shouldn't affect printing that I am aware of. To SD card, it's just
the X3G compile function anyway. SF does the lifting of gcode
creation.

This brings up a second concern. You said S3G but really hoping you
meant X3G as running s3gs means no acceleration, why bother running
Sailfish firmware?
In other words, you ahd better be saving to x3g at export.

I have checked. Its s3g generated in RepG39 and its printing fast. Maybe I am missing something here.
1. open the stl model
2. click generate gcode
3. use default start/end gcode, use print-o-matic, infill 10, layer height .27, shell 1, feedrate 80, travel feedrate 150, print temp 230.
4. after generating, click build to file for use with SD card button.
anything wrong here.??

-Ben-

[Jetguy]

And at the bottom of the save window, there is an option for what file
type. CHOOSE X3G
http://www.makerbot.com/sailfish/troubleshooting/
"If acceleration is already enabled, make sure you’re using the
correct version of ReplicatorG and the correct kind of build file. As
of Sailfish 4.0 for the Thing-O-Matic and Cupcake and Sailfish 6.2 for
The Replicator 1, Sailfish uses a new kind of accelerated move
command. In ReplicatorG 0039 – Sailfish, those new commands are used
when generating .s3g files, while in ReplicatorG 0040, .s3g files use
the old commands and .x3g files use the new ones. If you use an .s3g
file generated with any version of ReplicatorG other than 0039 –
Sailfish, it will contain the old accelerated move commands and
Sailfish will run them as non-accelerated moves, resulting in violent,
jerky movement that is bad for your bot and your prints."

Replicator-G page says the same thing
http://replicat.org/start
"* Support for selecting between s3g, x3g file formats (x3g is
makerbot's new file format, which supports Sailfish)"

[hisashime]

Thanks. I am still on Repg39-sailfish and firmware 4.1(r720).