EX.02 (gcode editing) “Use the gcode, Luke”

As a foreword, This page is dedicated to tests with custom gcode writing and editing. We are primarily interested in porting the gcode writing sample supplied for the Lulzbot (Marlin) to other firmwares and machine types, since that’s where it will end up being applied.

UPDATE:

The gcode writer  for the BKMM (Repetier) works! kind of…

In a last ditch effort, the header from simplify (comments and all) was transported to beetle blocks and grafted to gcode coordinates output from a simple spiral test. Only one concrete issue remains, and that is adjusting the E values. It would appear that the e values increase inversely to how they are intended to increase. Meaning, a longer distance between coordinates yields less filament, and shorter distances yield exponentially more filament. Photo-documentation to follow (phone is OOC).

At this stage, we feel like Luke during his tenure on Dagobah BEFORE he successfully lifted the X-Wing out of the bog…

This week, We both delved into gcode, specifically translating the writer provided to the class to other machines with separate firmware.

I’ve been attempting to port the gcode to the BKMMs provided by Richard. The primary hangup here is that the BKMMs are flashed with a RepRap firmware called Repetier, which requires a unique set of header/footer qualities in order to successfully complete a print. I was able to successfully push gcode to the machine by slicing a simple file with a slicing software that is verified to work on the machine, and inserting gcode coordinates generated in Beetle Blocks HERE:

fullsizerender-2fullsizerender-3img_1242

Several problems that have arisen:

  1. The header/footer combo that successfully generated these models is not uniformly effective. When applied to the average set of coordinates, the print fails to initialize. This lead me to believe that Repetier is verifying the code in its entirety to search for coordinates outside of its acceptable domain. However after talking to Che-Wei and Andrew Reitz, I’ve been assured that this would be a highly unorthodox way for a gcode to be perceived by a machine.
  2. Plotting variable z values has been questionable at best. and in fact, when I attempted to repeat the same path twice over, once at Z = 0.2, and again at Z = 0.4, the machine recognized only the first set of coordinates and negated the second. Very spooky..

 

Grey followed a similar logic with gcode porting from beetle blocks, and was able to successfully analyze a code generated by rhinoCam for the CNC mill and mimic its header/footer to create a hacked toolpath to remove a layer of foam following a turtle geometry path from Beetle Blocks found HERE

 

The bit used was a 3/8″ Ball, and a milled it on some pink foam.

img_8007img_8008

This is what the gcode starts to look like on the processor (Tecno)

img_8005

and here you can see a couple of the squares starting to be cut

img_8006

Here is one of the final pieces…but because I’m a sucker for greytones…

fullsizerender-1   fullsizerender

Successes with this came in understanding gcode commands with enough clarity to specify engage/retract points to be read by the CNC, as well as applying name and number values iteratively to layers, a requirement in NC coding. VERY CLEAN…