Re: Linux vs. DOS

> I finally have made my first item using EMC!!!
>
> If you want to check it out you can see it on my website at
> http://www.ktmarketing.com/emcproject1.html

I like it! I'm also happy to see that you were able to use your CAM output
with the EMC.

> In getting this g-code to run I have discovered another thing I wish EMC
> would do. When it runs into an error in your g-code EMC pops up an alert
> window telling you what the error is in terms that give you a hint at the
> problem, but it resets your program at that point and gives you no
> indication of the line that caused the error. The code for cutting this
> little EMC sign I made was 572 lines long. So it was a little bit of a pain
> to watch the program code as it flys by in Xemc and hope I was paying close
> enough attention to catch the line number just before I hit an error. If
> Fred could add the ability to display the line of g-code in the alert

window

> along with the error message debugging a g-code program would be 1000 times
> faster.

At the beginning of the error message there is a number. Although it doesn't
say so, this is the line number of the error. Not the "N" number (if you use
them), but the number of lines into the program from the top. This should be
easy to find with emacs or any editor that counts the lines for you. I'll
agree that the error messages could be more explanatory in their verbiage.

> Here is a question for Matt or Jon or anyone else running EMC:
> Is there a way to run the g-code through EMC's code interpreted without

just

> loading it in Xemc and running it?

Yes, open the file for editing, scroll down all the way to the last line that
says M2 and put your cursor there. Press the "Set Run Mark" button at the
bottom of the editor window, and confirm that you want to start running at
this line when the little window pops up to ask you. Make sure you are clear
of any obstructions since the machine may try to move to the position that it
would be in at the end of your program (probably the tool change position).
Originally, the interpreter could be run in standalone mode (without the
motion control system) and do its inputs and outputs to and from disk files.
More interpreter information is in the file:

ftp://ftp.isd.cme.nist.gov/pub/emc/emcsoft/RS274NGC_22.doc

I am about halfway through turning this document into html which will improve
its accessibility. The raw .doc file doesn't have the table of contents,
illustrations, tables, etc.

> I found that if I tried running the code
> with the my stepper controller turned off so I could crank up the feed rate
> to just check the code more quickly I would get an error that would abort
> the code referring to a "follow error" on an axis. If I ran the code with
> the controller turned on I had no errors in this section of code, but it
> took MUCH longer as I had to use realistic feed rates.

Since you have no feedback in your control system (like encoders), I don't
think you should get following errors. I'm puzzled by this, so I'll forward
it to Fred.

> Now for some observations that may help others over the EMC learning curve

a

> little faster:
> The enter key by your number pad and the enter key by your letter keys are
> not equivalent in EMC. If you use your mouse to click on either the feed
> rate or the feed override it pops up a window to enter a rate into, but to
> get it to accept the rate and use it you have to use the enter key by your
> letter keys. The one on the number pad will close the box, but your entry
> disappears.

I didn't know this, but it may be fixable. I'll send it to Fred as well.

> EMC seems to want it's circular moves (G2, G3) to be entered in the format
> using R and not I and J.

Actually, I had the same problem, but the other way around. I couldn't always
use R format, but IJ worked fine. I'd like to know what the error message
was. I drew these in AutoCad and assuming the starting point to be X-2.196
Y-5.946 I got the following results:

> EMC seems to likes: N331 G03 X-2.309 Y-6.059 R.094

The center of this arc is X-2.2175 Y-6.0375.

> EMC seems to not like: N331 G03 X-2.309 Y-6.059 I-2.253 J-6.003

The radius of this arc is .0806 .

Truthfully, I got some bad R format output from my CAM system that the EMC
couldn't digest. Here are some excerpts from the e-mail of that era:

-----
From: Matt Shaver
When the EMC tried to execute the block:

N285G3X22.4352Y-1.8132R0.0025

it produced the error:

"arc_data_r: error 2: Arc Radius is too small to reach end point".

The starting point for the arc was X22.4388 Y-1.8168.

I thought it might be the result of a rounding error so I changed the post
processor in the CAM software we're using to output the coordinates with 100%
precision. This made the code look like:

N285G3X22.4352322Y-1.8132322R-0.0025

but it still failed.

I drew the geometry (as two points connected by an arc) in AutoCAD to check
whether this was a valid arc and it seems OK. The entity list was:

POINT Layer: 0
Space: Model space
at point, X= 22.4352 Y= -1.8132 Z= 0.0000

POINT Layer: 0
Space: Model space
at point, X= 22.4388 Y= -1.8168 Z= 0.0000

ARC Layer: 0
Space: Model space
center point, X= 22.4370 Y= -1.8150 Z= 0.0000
radius 0.0025
start angle 315
end angle 135
-----

Tom Kramer, the author of the G code interpreter replied:
-----

> The start and end point are 0.0050919293 apart. This is 0.00009 more
> than twice the desired radius of 0.00250 (a relative error of 9/250).
> The interpreter allows a relative error of only 0.000000000001
> (#define'd as TINY in rs274ngc.hh). The check is made in the arc_data_r
> function. TINY is not used for anything else and could be changed easily,
> but I do not think we want to make it as large as 9/250.
>
> The block of code is trying to make a semi-circle using the r-format
> for an arc. This is inherently numerically unstable (which we discussed
> in one or more of the NISTIR's on interpreters) and should not be done.
> A change of 0.0001 in the position of the end of an r-format semicircle
> may move the center of the semicircle as much as 0.01, which is likely
> to result in an out-of tolerance part.
>
> To deal with this, the arc may be split into to quarter circles (then
> numerical stability is not a problem), or some other format arc should
> be used.

-----

Since switching to IJ format there haven't been any problems since for any
two points (start and end) and a specified center point, an arc of some
radius exists!