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