开云体育

I finally have made my first item using EMC!!!

If you want to check it out you can see it on my website at

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

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

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

loading it in Xemc and running it?

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.

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

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.

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

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

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

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.

Has anyone tried running a lathe using EMC? I have set up a 2 axis
configuration file on my machine and hope to give it a try this weekend.

Got impatient and gave it a try. Here is what I found:

You have to change your g-code to be X Y and not X Z as is normal for
lathes.

Don't set the AXES setting in the [TRAJ] setting to 2. If you do Xemc will
come up with the Z axis numbers in red and you can jog X and Y just fine,
but as soon as you try to gun a g-code program and it hits a linear move you
get an error something like "linear moves can't be made if beyond the
limit". After checking to make sure I was not beyond the soft limits for X &
Y and restarting EMC a few times it dawned on me what is happening. The red
numbers is the same thing you get when you hit a limit switch. Apparently,
EMC thinks you are against the limit switch for the Z axis.

Other than this it seems to work just fine after you reverse the direction
of movement of the X and Y axis in your ini file.

From: "Tim Goldstein" <timg@...>

I finally have made my first item using EMC!!!

If you want to check it out you can see it on my website at

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? 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.

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.

EMC seems VERY picky about the g-code it will accept. The other controller
software product I was using will let you run most any code you throw at it
as long as you don't give it a code it doesn't handle. EMC seems to require
everything is exact. This is not a bad thing, but it does make the debugging
lengthy particularly in light of the fact that when it errors you have no
clue of the line that caused it.

On the plus side, my machine seems to run much smoother under EMC than on
any of the other softwares I have tried.

3. Maybe there should be an _actual_ feed rate display to compliment the
_commanded_ feed rate display we have now. If we go to the "exact path"
motion control system this would show when the system is forced to decrease
the feed rate to keep acceleration within bounds.

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.

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?

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.

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.

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.

From: "Tim Goldstein" <timg@...>
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?

From: "Tim Goldstein" <timg@...>

I just checked the ftp server for EMC and there is a new build dated
June-5-1999 on the site. Don't know what it fixes, but I am downloading it
right now and will report back later.

From: Fred Proctor
To: mshaver@...
Subject: Feed rate override and max feed rate
Date: Saturday, June 05, 1999 6:49 PM

Matt,

More detail than I left on your answering machine: consider this
example:

1. As set in the ini file, the max feed rate is 60 IPM and the max
allowable feedrate override is 200%.
1. You set the feed rate override to its max, 200%.
2. You MDI "G1 X10 F60", which moves the machine at 60 IPM despite the
200% feed rate override, since the max feed is set to 60 IPM.
3. You reduce the feed rate override to 150%, then 100%, then 50%.

What should happen? Should the feeds be 60, 60, 30, or should they be
45, 30, 15? In the first case the operator would be surprised that
reducing the feed rate override from 200% to 150% and 100% had no
effect. In the second case the operator would be surprised that at the
final 50% feed rate override and a nominal 60 IPM, the feed is actually
15 IPM.

What is your experience with other CNCs?

--Fred

Thought I would take the opportunity to start a new thread name as the
original one of Linux vs. DOS has become just info and tips about setting

and using Linux and EMC.

From: "Tim Goldstein" <timg@...>

I just checked the ftp server for EMC and there is a new build dated
June-5-1999 on the site. Don't know what it fixes, but I am downloading it
right now and will report back later.

Thought I would take the opportunity to start a new thread name as the
original one of Linux vs. DOS has become just info and tips about setting up
and using Linux and EMC.

Tim
[Denver, CO]


------------------------------------------------------------------------
Have you entered ONElist's "Grow to Give" program?

Deadline is June 19. Join now to win $5000 for your charity of choice.
------------------------------------------------------------------------
welcome to CAD_CAM_EDM_DRO@..., an unmodulated list for the

Sorry, old technology. Mag amp is short for a magnetic amplifier.
This goes back to WW-II, and certainly Korea.
A way of getting a lot of gain without much energy loss is to use a winding
of many turns of fine wire to drive an inductor into and out of saturation.
When the inductor is saturated, AC current passes through a winding
of a modest number of turns of heavy wire fairly easily. When the control
winding does not saturate the inductor, then the inductance blocks the
power flow through the power winding.

No. What is similar to the low voltage winding of a mains transformer
would be put in series with the AC output of the real mains transformer,

From: "Ian W. Wright" <Ian@...>

Thanks Jon but let me just get it clear. Are you saying that if you put,
say, the high voltage winding of a mains transformer in series with the
low voltage motor, it will boost its starting torque?

From: "Ian W. Wright" <Ian@...>

Sorry to seem so dim but what, pray, is a mag amp?

The trick Bridgeport uses (pretty tricky, but not original) is to use a mag
amp on the AC input to the rectifier.