John Elson read this please

John:

I just came back from your site and I have to say it's nice to see some
good C++ written down there. I was working on a rectpocket routine myself
and though I'm not going to steal yours I did admire the logic, maybe
because I reached same sort of conclusions myself about the general way
(from brief look) it should be structured. Maybe I should write mine (it's
in psuedo-code right now) before I study yours too much, so I won't be
influenced toward immorality?

I realized early on that once routine compared the X and Y dimensions, and
figured out which way to start (from point equidistant from one end and
both sides, IE on int of lines 45 deg to end corners), the remaining part
was a matter of book-keeping only on the diff between tool dia and the
location of the end. I decided after plowing the center stripe to step out
the given increments along a 45 deg line toward a corner and then add two
times cut width to each length of cut, plus on longer axis add the diff
between width and length. Then book-keeping only that one distance makes
the machine stop out-stepping the right amount for the other sides too. I
didn't examine closely enough to see if you did that, but it's a simple and
obvious solution and I expect you saw it too. In my case I had a routine to
keep track of stepovers and finish cuts for turning (and in fact for
peck-drilling) and it looks as if that can be used for above position
tracking too.

One thing tried to avoid as much as possible is having extra user inputs.
So instead of calling for tool dia entry in routines, I use a table and
just give the routine a TN; it then computes the necessary stuff directly
using variables in routine that refer to the right line/column in tool
offset/dia array; you just declare the array of variables as global and
stick them into the functions in the pocket routine or wherever. To do all
that you need motion control with position feedback, so you can poll for
position of tool and store it.

One thing I was wondering about is whether you'd any plans to emit the
Gcode to machine as well as file. You could make these run real time on
machine pretty easily by simply writing to machine and file both. You also
get the ability to jog tools around and find out your offsets directly of
course. The question here is whether the common G-code software like HAHA
and MaxC can accept input that way??

Best wishes,

Hoyt McKagen


Belfab CNC - http://www.freeyellow.com/members/belfab/belfab.html
Best MC Repair - http://www.freeyellow.com/members/batwings/best.html
Camping/Caving - http://www.freeyellow.com/members/batwings/caving.html
If assholes flew, this place could be an airport !!