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
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?
- posted 11 years ago