Re: EMC & Linux

Tim Goldstein wrote:

> What I noticed was not that EMC wouldn't process the I & J format, but that
> it seemed as if I had more errors than if I used the R format. Except for
> very simple stuff I use Vector 7.0 to generate my g-code and what I found
> was when I generated both styles off the same part there were far fewer
> lines that errored with the R format. This could be an indication that
> Vector's g-code algorithms are a little lacking when it comes to the I & J
> style, but I never had a problem with it in DeskNC.

Yes, EMC is VERY picky about inside corners when using a cutter
radius offset. It is also very picky about extremely small errors in
matching the radius computed from the I and J words to the current
position and the new position specified in the X and Y words.
These things have to match to about .000001" or you get an error.

>
> Despite having used the I & J format in the past I will admit that I really
> don't understand it. It is my understanding that the X & Y values indicate
> the destination position, but can you clue me in on what the I and J are
> indicating?

To make an arc, you have to know not only where you started and
where you end, but also the radius. The I, J and K words are the distance
from the starting point to the center of the arc, in the X, Y and Z
axes, respectively. So, in your earlier question, the I and J words
give a set of coordinates for the center of the arc. Then, EMC compares
the length of imaginary lines from this center to the start and end points.
many CNC controls allow quite a bit of difference in these, and just fudge
it. EMC requires them to be really accurately the same length.

> > I found out that if you set the Acceleration too low, you get some odd
> > behavior. The move that is just ending slides to a stop slowly after the
> > next move starts. The ramping was working pretty good for my setup and I
> > kept running it lower and lower just to try it out. At
> > Acceleration set to
> > .05 it does this lazy motion thing. At .15 it looks ok. When I cut parts
> > I will check it for sure.

This is the blending of moves. It can be a problem when you make an X
move, then a Y move, as the Y move will start to ramp up when the X move
just begins to ramp down. But, for a string of short continuous moves describing
a fluid curve, you need this, or the machine will absolutely CREEP. (My
antique AB suffered from this.)
Maybe we should ask Fred Proctor for some sort of switch (either in
the RS-274 program (G-code) or on the user interface) to turn this
on and off.

> Actually I had no problems running any code in lathe mode. Here is the few
> lines I tried to run. It has small enough move you should have no problems
> if you want to give it a try. It isn't anything special. It just turns a
> shaft down to a number of steps with roughing passes and then has a finish
> pass to complete it.

This is good news (although, really, except for some very small tricks like
wanting a diameter/radius display) the CNC really doesn't need to know
what it is moving - a Mill, a Lathe, or a robot. Oh, yes, then there is
the constant surface speed trick, where the spindle speed changes as
the cutter radius changes.

> I agree on the program. I like what it has to offer a lot. I want to get a
> better handle on how to use the cutter comp and I would like to find a way
> to know what line it is that is failing on a program, but all in all it is a
> far superior program to the DOS / Windows based items I have been using.

I believe Fred has something in the works that will make this a lot better.
Clearly, a real need.

Jon