I was working on a new part under GSimple two weeks ago.

I have my own custom GSpost definitions file for the R2E4, because it
transmutes some of the ISO G-code, and requires all three axes be
expressed in a drilling cycle.

This particular part just would NOT work. Every time I got ready to
drill one hole (of several) with a peck cycle, the bit would plunge
straight into the work in one feed. It was wax (per usual) and didn't
break anything, but it was obviously not right. So, of course, I assumed
my post defs were wrong.

It turns out there's a bug in GSimple's post-processor code that
occasionally will drill a peck hole in straight in-line G00 code just
before it drills it with the G83 cycle.

I'm reporting it, but not a lot of bug-fixing is going on with that
product right now, so I don't expect a fix.

FWIW, the order of the holes is root to the cause. Just moving the hole
to another part of the original GS output file allowed GSpost to get it
right. That's an ugly fix, though, because makes you have to peruse
sometimes hundreds of lines of code to find something that doesn't just
"jump out at you" among all that other G-code.

I'm thinking of writing my own post-processor (just for the R2E4) in
compiled BASIC, and just shucking the GSimple processor. All in all, GS
has been good. It would be nice if it did islands, but so far I haven't
really needed them. It does a really nice job of handling tool changes
and speeds.



A question, too for you all... I've gotten by for most of a year with
files that would fit in the R2E4's main memory, but am bumping up against
parts that will have to be "drip fed" from my computer. I can't figure
that one out from the docs. Anybody have experience there?

LLoyd

"Lloyd E. Sponenburgh" lloydspinsidemindspring.com wrote in message
. 3.70...
I was working on a new part under GSimple two weeks ago.

I have my own custom GSpost definitions file for the R2E4, because it
transmutes some of the ISO G-code, and requires all three axes be
expressed in a drilling cycle.

This particular part just would NOT work. Every time I got ready to
drill one hole (of several) with a peck cycle, the bit would plunge
straight into the work in one feed. It was wax (per usual) and didn't
break anything, but it was obviously not right. So, of course, I assumed
my post defs were wrong.

It turns out there's a bug in GSimple's post-processor code that
occasionally will drill a peck hole in straight in-line G00 code just
before it drills it with the G83 cycle.

I'm reporting it, but not a lot of bug-fixing is going on with that
product right now, so I don't expect a fix.

FWIW, the order of the holes is root to the cause. Just moving the hole
to another part of the original GS output file allowed GSpost to get it
right. That's an ugly fix, though, because makes you have to peruse
sometimes hundreds of lines of code to find something that doesn't just
"jump out at you" among all that other G-code.

I'm thinking of writing my own post-processor (just for the R2E4) in
compiled BASIC, and just shucking the GSimple processor. All in all, GS
has been good. It would be nice if it did islands, but so far I haven't
really needed them. It does a really nice job of handling tool changes
and speeds.



A question, too for you all... I've gotten by for most of a year with
files that would fit in the R2E4's main memory, but am bumping up against
parts that will have to be "drip fed" from my computer. I can't figure
that one out from the docs. Anybody have experience there?


I did a lot of basic parts with G-Simple, but it never seemed to have enough
umph for me. Its pretty darn good for a free program though. I tried a
number of CAD/CAM packages including several paid ones, and I found CamBam
to be about the best bang for my buck. Its got a lot of good 2D cad
cability, and its CAM works. It also handles STL 3D files like a snap as
imported entities. You can even import the same one several times and
position as needed.

I have not started my copy of G-Simple in quite a long time now.

On Tue, 14 Dec 2010 15:33:53 -0600, "Lloyd E. Sponenburgh"
lloydspinsidemindspring.com wrote:

snip

A question, too for you all... I've gotten by for most of a year with
files that would fit in the R2E4's main memory, but am bumping up against
parts that will have to be "drip fed" from my computer. I can't figure
that one out from the docs. Anybody have experience there?

LLoyd

=========
to download a software solution click on
http://www.mcduffee-associates.us/PE/SPLITTER.ZIP
written in PowerBasic and includes the source and a sample
cnc file for an impeller. I placed this in the public
domain.

Description:
A software solution to the problem of a large file and small
controller memory w/o drip feed capability. Divides any
G-code CNC file into smaller user specified size files
(minimum 5k), and adds header.nc and footer .nc to preserve
modal settings, etc. Generated programs are seg00001.nc
through seg99999.nc in the same directory as split02.exe.
you can specify drive and directory of the long input file
and the program will accept long file names as well as the
DOS 8.3 format.

Splitter.zip contains the following files:

split04.bas - the PowerBasic CC source file
split04.exe - the executable program that will run in
Windows no DOS box needed
blade.nc - a long 341k profiling program for test
footer.nc - a sample footer file from test.nc
header.nc - a sample header file from test.nc

Note header.nc and footer.nc must be user generated from the
long program they wish to split. Let me know if you find
this to be useful and any suggestions for improvements or
extensions.

Update 13 Apr 07 from split02 to split03 is that the return
of the tool to the last position is under rapid [G0] except
for last 0.10 unit of Z travel. G1 modal is restored.

Update 14 Apr 07 from split03 to split 04 is that entire
code line is parsed and LAST XYZ values are used, when
multiple moves per line. Rapid approach now to within 0.5
units in Z on following segment, then G1 model.
==========




-- Unka George (George McDuffee)
...............................
The past is a foreign country;
they do things differently there.
L. P. Hartley (1895-1972), British author.
The Go-Between, Prologue (1953).

F. George McDuffee fired this volley in
:

http://www.mcduffee-associates.us/PE/SPLITTER.ZIP

George, thanks! I've been fiddling that capability by hand, and sometimes
did lose my modal settings, and had to add the code to reassert them.

LLoyd

On Tue, 14 Dec 2010 21:09:15 -0600, "Lloyd E. Sponenburgh"
lloydspinsidemindspring.com wrote:

F. George McDuffee fired this volley in
:

http://www.mcduffee-associates.us/PE/SPLITTER.ZIP

George, thanks! I've been fiddling that capability by hand, and sometimes
did lose my modal settings, and had to add the code to reassert them.

LLoyd
=========
You're more than welcome.

There may be some other stuff you can use at
http://mcduffee-associates.us/cnc_re...nc_related.htm

also see
http://mcduffee-associates.us/machin...aftmachine.htm
for my crafts machining page
and
http://mcduffee-associates.us/PE/Econometrics.htm
for my political econometrics page.

Any comments or suggestions appreciated.


-- Unka George (George McDuffee)
...............................
The past is a foreign country;
they do things differently there.
L. P. Hartley (1895-1972), British author.
The Go-Between, Prologue (1953).