开云体育

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]

Tim,

I have been running EMC this week on a Sherline mill. I haven't made any
parts yet, but have been running the table to get a feel for it. On G02,
G03, cirular interpolation- I have been using I and J format with no
problem so far. Maxnc uses I's and J's, so I'm use to it now.
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.
What kind of problem did you have with the XZ motion with the lathe? Did
you set up a G18 (XZ plane) before trying to make a curve? I haven't tried
it myself yet. I will try it tommorrow.

I really do like this program so far. The fact that it is rewrote
constantly and the source is out there is kind of reassuring. I am looking
forward to being able to use it for the lathe and gang the spindle to the
compound using encoders. I don't have servos yet, but someday I will bite
the bullet and get them.

Sincerly,
Dan Falck



At 07:25 PM 6/5/99 -0600, you wrote:

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

discussion of shop built systems in the above catagories.

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.

Sorry, I forgot to tell you. I believe this fixes the problem of
DEFAULT_VELOCITY not affecting the default feed rate. It also may limit the
max feed rate to MAX_VELOCITY. Fred told me this on Friday, but I was sick
and my brain was clogged up so I didn't do any writing to the list and by now
I've forgotten the exact details. Fred also e-mailed a question to me today
on this same subject and I'm sure he wont mind my echoing it here as well as
my reply:

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

I replied:
-----
I think the 60, 60, 60, 30 scenario is the correct one. The way this is
handled in other cncs is that the rapid traverse rate is greater than the
highest allowable _programmed feed rate_. Also, the feed override control
usually only goes up to 125%. For example, on a mill that rapids at 150ipm,
the max feed rate you can program might be 100ipm which can be increased to
125ipm with the feed override knob.

Some random ideas:

1. Add a MAX_PROGRAMMED_FEED_RATE parameter to allow setting up the
conditions described above. The writer of the .ini file could always goof up
and allow MAX_PROGRAMMED_FEED_RATE x MAX_FEED_OVERRIDE > MAX_VELOCITY, but
the maximum actual velocity should never exceed MAX_VELOCITY.

2. Maybe there should be a "clipping" indicator when this error condition
happens.

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.

Sorry I didn't get your phone message earlier, I've been home most all day
but I left to go to Radio Shack when your message came in and I never looked
at the machine until I read your e-mail. The stepper control hardware is
progressing...

Thanks,

Matt
-----

If anyone else has suggestions on how to handle this, speak up!

When I do a software update, I usually:

1. Save run.emc (or whatever you've named your customized script), emc.ini
(ditto here), tool.tbl (tool data), and rs274ngc.var (the offsets). Also save
any other stuff you want to keep that is in or below /usr/local/nist/emc.

2. Go to /usr/local/nist and run ./clean which removes everything including
the emc directory.

3. Put the latest emc.tgz (whatever its name) in /usr/local/nist and
un-tar/zip it.

4. Run ./install to compile the new version.

5. Put back the files you saved in step 1.

There is a ./update script as well that I believe saves your customized
settings, but I've never used it. If you try it, let me know, maybe I should
too!

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.

A good idea! I'll start using it too.

Matt

Matt,
Sorry to hear you are still sick. It sure is a drag when you have things you
need to do.

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?

I and J are the coordinates of the center of the arc, I=X, J=Y. See my next
post for more on this.

<much other stuff cut>

I've got a lot to say about the rest of this stuff you're talking about, but
I'm slow at typing so I might break it down into a few separate replies. I'm
beginning to think we need audio/video/whiteboard type conferencing rather
than e-mail!

Matt

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

Matt Shaver wrote:

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.

My antique Allen-Bradley had this. The feedrate would actually ramp up and
down as moves started and stopped. This much activity isn't necessary
(the AB updated the screen at 100 Hz, same as the servo update rate and
the trajectory update). But, showing the rate it is actually going (at the plateau
of the trapezoidal velocity profile) would be nice. Of course, it now shows
the feedrate of the LAST move in the program, since the interpreter has
run to the end before I hit start!

Jon

hi Jon & Tim,

suggest making the deceleration override a G-code instruction as you want
to turn it on for the many short moves of an interpolated spline as you point
out, but on a square feature on the same part you want the motion completing
in one axis before starting in the other.

an even better approach is found in a commercial control i use at work
which has a parameter set in G-code which they call "Tangency factor" that
automatically controls the overlapping accelerations between blocks based
on the angle. (how it works i don't know -- not open source -- mfg Thermwood)

-ron

On Sun, 6 Jun 1999, Jon Elson wrote:

Tim Goldstein wrote:

---snip---

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.

From: Jon Elson <jmelson@...>
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.

[There are other documents like the NCMS (National Center for Manufacturing
Sciences) Next Generation Controller Part programming Functional
Specification (RS274/NGC), which, unfortunately, only exist as paper
documents. This one is 127 pages and I have a Xerox which also has Tom
Kramer's handwritten notes in the margins regarding the inconsistencies in
the document. I'd scan it and html it if I had the time. I can't imagine how
long it would take to OCR it and then as slow as I type, we'll all be dead
before I could finish, plus, what do I do with Tom's handwritten notes?
Footnotes? Appendix?]

Paraphrasing NCMS:

G09 Exact Stop (Non-Modal) Causes an exact stop before the next move begins.
G61 Exact Stop Mode (Modal) Same as G09, except it doesn't affect rapid
moves.
G64 Contouring Mode (Modal) Default mode where the next move begins when the
previous move has reached a position within the "tolerance band" specified by
the machine builder. (I wonder where this tolerance is in the EMC, and how to
change it?)

Unfortunately, they don't seem to work. The reason for the blending in the
first place (as explained to me by Fred, and which I hope I remember
correctly) is that the heritage of the EMC is the robotics family, not the
machine tool control family. There are three variables involved in motion
control:

1. Desired Velocity (feed rate)
2. Maximum Acceleration Rate
3. Path Geometry

Imagine a tool path that goes along the X axis for a while, and then gently
radiuses into a Y axis move. In the servo systems I've worked on so far, at
machining feed rates it's no problem for the control to follow this toolpath
while keeping below the maximum acceleration limit. Now imagine the situation
that occurs at the end of a drilling cycle where we are rapidly pulling up
the Z axis to get the drill clear of the hole, and then we rapid in X and Y
to the next hole location. At the top of the Z travel we have to make a 90
degree corner at the rapid traverse rate. This move is definitely going to
exceed the maximum allowable acceleration rate. In robotics applications the
typical practice is to blend these motions together with a large enough
radius to limit the acceleration to an allowable rate while maintaining the
programmed feed rate. This is "exact velocity" mode. That's how the EMC works
now. As Jon points out, if you have a long series of short moves describing a
fluid curve, this is exactly what you want, because if you run in "exact
path" mode and come to a full stop before beginning the next move you will
gouge the surface and your mold or whatever will look like hell as well as
take forever to machine! However, I have experienced the problem of having a
drill broken off in a hole because X and Y started moving before the Z axis
had dragged the drill clear of the hole. This is definitely an "exact path"
operation! I believe Jon programs his drilling cycles by hand (or with one of
his nifty programs) without using the G8x series of canned cycles. I believe
his retract move is done as a feed move. What I have done to get around this
problem with rapid moves is to insert a dwell (G04) between the rapid moves
as shown in the skeleton program template at the end of this post. Another
workaround is to specify a retract level high enough off the top of the part
so that the drill is clear before blending occurs.

The immediate problem with all this is that the stepper guys (and that will
be me soon as well) have acceleration limits low enough that they are getting
blending at machining feed rates. This could cause there to be radiuses where
none are expected! Either they will need to hop up the hardware to allow
faster acceleration (higher supply voltage Tim?), or G61 needs to work, or
you need a dwell between every move (the other alternative of limiting the
feed rate isn't a good answer).

N5(SKELETON 00-00-00 1 filename, date, etc...)
(set up modal operators)
N10G17G20G40G49(XY plane select, inch mode, cancel diameter comp, cancel
length offset)
N15G54G80G94G98(coordinate system 1, cancel motion, feed/minute mode, initial
level return)
N20M48
(The next 3 lines probably aren't needed anymore, they fixed an old bug)
N25G91
N30G0X0Y0Z0
N35G90
N40G53G0Z0(retract quill)
N45X0.Y0.(move X and Y to the tool change position, change as required)
N50M05M09(spindle and coolant OFF!)
(display a message for the operator)
N55(MSG,LOAD TOOL #1)
N60M00(don't move until the operator presses the S key)
(clear the message line)
N65(MSG, )
N70T1M06G43H1(change to tool 1 and get its length from the tool table)
(start G0 lines with a .001 second pause to avoid motion blending problems)
N75G04P.001G0X1.0Y1.0S1000M3M8(rapid to the starting XY, spindle CW, coolant
ON, change as required)
N80G04P.001G0Z0.25(rapid to .25" above the part, change as required)
( )
(the program goes here, don't have blank lines)
( )
(PROGRAM END)
N980G0Z0.25(rapid to .25" above the part, change as required)
N985M05M09(spindle and coolant OFF!)
N990G53G0Z0(retract quill)
N995X0.Y0.(move X and Y to the tool change position, change as required)
N1000M2(end program)

I got an e-mail from Dan Chamberlain and he was asking if EMC would work on
a system with 20 mb RAM? He is looking to put it on a laptop and that is the
memory he has in it. I did caution him that Linux is pretty particular about
hardware and that may keep him from using his laptop.

He also wanted to know if the stepper version supported 4 axis's? My guess
is no considering we only have pin out connections for 3 axis's. Does the
servo version support 4?


Tim
[Denver, CO]

Matt Shaver wrote:

[There are other documents like the NCMS (National Center for Manufacturing
Sciences) Next Generation Controller Part programming Functional
Specification (RS274/NGC), which, unfortunately, only exist as paper
documents. This one is 127 pages and I have a Xerox which also has Tom
Kramer's handwritten notes in the margins regarding the inconsistencies in
the document. I'd scan it and html it if I had the time. I can't imagine how
long it would take to OCR it and then as slow as I type, we'll all be dead
before I could finish, plus, what do I do with Tom's handwritten notes?
Footnotes? Appendix?]

I have this document, too. I could scan it, but it would have to be published
as an image. There is so much henscratching all over it, no OCR could
read the original printed text (which is wrong in many places, hence the
henscratches).

Paraphrasing NCMS:

G09 Exact Stop (Non-Modal) Causes an exact stop before the next move begins.
G61 Exact Stop Mode (Modal) Same as G09, except it doesn't affect rapid
moves.
G64 Contouring Mode (Modal) Default mode where the next move begins when the
previous move has reached a position within the "tolerance band" specified by
the machine builder. (I wonder where this tolerance is in the EMC, and how to
change it?)

Unfortunately, they don't seem to work.

Right, I was pretty sure from some email with Fred that this was a permanently
active feature, right now. There is no 'tolerance'. The next move starts as
soon as the deceleration of the current move begins. Since the deceleration
is a linear ramp at a fixed rate, if you slow the feedrate, the decel begins closer
to the end point. So, if this is a problem, you can program or override the
feedrate at these points to prevent rounded corners (or crashes!) where it
matters.

Unfortunately, they don't seem to work. The reason for the blending in the
first place (as explained to me by Fred, and which I hope I remember
correctly) is that the heritage of the EMC is the robotics family, not the
machine tool control family. There are three variables involved in motion
control:

1. Desired Velocity (feed rate)
2. Maximum Acceleration Rate
3. Path Geometry

<snip>

The immediate problem with all this is that the stepper guys (and that will
be me soon as well) have acceleration limits low enough that they are getting
blending at machining feed rates. This could cause there to be radiuses where
none are expected! Either they will need to hop up the hardware to allow
faster acceleration (higher supply voltage Tim?), or G61 needs to work, or
you need a dwell between every move (the other alternative of limiting the
feed rate isn't a good answer).

Well, I see it on my fairly responsive servo system, especially when I have
some non-cutting moves above 45 IPM.

Jon

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

He also wanted to know if the stepper version supported 4 axis's? My guess
is no considering we only have pin out connections for 3 axis's. Does the
servo version support 4?

Hi Tim,
From my understanding it should be possible to use more than one parallel
port.
Mo

Jon,

If you want to scan it I have an FTP server available to me that we could
put the images on.


Tim
[Denver, CO]

Tim Goldstein wrote:

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

Jon,

If you want to scan it I have an FTP server available to me that we could
put the images on.

OK, I'll take a look at it and see how badly it looks as a .gif or whatever.
You won't believe how scrambled the original printed document was.
If the henscratched corrections are not readable after scanning, it will
be useless.

Jon

This may not be a practical solution for your radius problems, I'm just
learning about this stepper motor cnc stuff myself, but how about adding a
rotary table to your program "Z"? Axis?

Tracey

By the way I'll probably be asking a lot of dumb questions in the
future...please bear with me thanx

If you are running steppers on the build date 08-jun-1999 you now have to
configure a parameter called CYCLE_TIME. I was a little confused on this
setting so I called Fred today and again took the time to set me straight.

To make it easier to figure out a value to use as a starting point I have
put a web page at that will give
you the appropriate value for CYCLE_TIME and MAX_VELOCITY if you have EMC
configured to use inches based upon the steps per inch and the maximum speed
your machine is capable of in inches per minute.


Tim
[Denver, CO]