Loading G-Code without Rendering

A couple of months ago, I asked in [forums.reprap.org] for the ability to read g-codes without rendering in order to speed up the printing process:

Quote
brnrd
The ability to read gcode just for printing without displaying it would be nice. With a lot of my prints, I have to wait minutes while repsnapper interprets the gcode to generate the toolpath display. I don't always need to see that and get on to printing right away.

To which jcabrer replied

Quote
jcabrer
This can already be done in the render tab.

The option to disable rendering in the Mac Leopard compatible version that I use doesn't have any effect. It still takes a long time interpreting the g-code. Is there another Mac version that does what I want? If not, would someone point to the version that does regardless of OS?

Thanks.

If you mean that it takes a long time to "Load G-Code", there is not much you can do about that. The entire file is being loaded into memory, and most likely in a very inefficient way. Turning off G-Code Rendering only helps if you want to change the view orientation quickly withour a bunch of redrawing in between.

If you just want to get printing right away with proven code why not just use a terminal based sender like send.py ?

---

FFF Settings Calculator	Gcode post processors	Geometric Object Deposition Tool Blog
Tantillus.org	Mini Printable Lathe	How NOT to install a Pololu driver

Quote
jcabrer
If you mean that it takes a long time to "Load G-Code", there is not much you can do about that. The entire file is being loaded into memory, and most likely in a very inefficient way. Turning off G-Code Rendering only helps if you want to change the view orientation quickly withour a bunch of redrawing in between.

It doesn't take long for the reprap host to load a g-code file for printing. But when I load the same file into repsnapper, it takes much longer: many minutes versus less than 1 minute. I don't think it's just inefficient read since after it finishes, it displays the tool path. I think it's slow because it's doing the rendering. If repsnapper doesn't render it and instead just sends the g-code to the printer, then it would be much faster. Since I generate the g-code in skeinforge, i can already view the toolpath there so there's no need to view it in repsnapper.

Quote
Sublime
If you just want to get printing right away with proven code why not just use a terminal based sender like send.py ?

I would but I couldn't get it to work under Mac OS Leopard (10.5.8).

Quote
brnd

Quote
Sublime

If you just want to get printing right away with proven code why not just use a terminal based sender like send.py ?

I would but I couldn't get it to work under Mac OS Leopard (10.5.8).

In this thread sender.sh and func.sh are mentioned and then something about bash for osx

---

FFF Settings Calculator	Gcode post processors	Geometric Object Deposition Tool Blog
Tantillus.org	Mini Printable Lathe	How NOT to install a Pololu driver

change this line in tonokip

if(e_steps_to_take && (x_steps_to_take + y_steps_to_take <= 0) ) e_interval = time_for_move / e_steps_to_take * 100;


to this:
if(e_steps_to_take && (x_steps_to_take + y_steps_to_take <= 0) ) e_interval = time_for_move +1/ e_steps_to_take * 100;

there is a bug in the firmware for when no e movements are calculated. it causes a division by zero. processor locks up!

or remove this line

G1 E0 FXXXX ; from beginning of gcode. either way rep snapper is allowed to do G1 E0, so the firmware should not crash!

you will now be able to use gcode generated in repsnapper!

Edited 1 time(s). Last edit at 06/14/2011 08:08AM by jamesdanielv.