Re: re:EMC
Posted by
Tom Caudle
on 2000-10-10 17:04:19 UTC
--- In CAD_CAM_EDM_DRO@egroups.com, Anne Ogborn <anniepoo@n...> wrote:
machines (mills, lathes, punch presses) and developed a quasi
standard for the language to control them often referred to as G-
code. Its pretty simplistic and consists of Go commmands that give
an X and Y corroridinates. The X & Y can either be absolute (always
referenced from the 0,0 pint of the machine or incremental (each move
is from the last one) Over the years the code has expanded to cover
specific machine commands to deal with automatic tool changers,
misters, etc. The Control software is responsible to take the G-code
in and do things like issue the correct number of steps and direction
signals to each axis of the machine. 2 axis machine have X (normally
left and right as you stand in front of the machine, and Y, normally
forward and reverse from the same position. The Z axis is normally
an up and down (verticle) axis. There can be others like a rotary
axis and such. If you haven't seen any g-code then you haven't
missed much. The control software has the responsibility to do
things like automatically ramp up and down the motor speeds, monitor
the limit switches to keep things from spinning off onto the floor
and in general move the mechanics of the machine. It can also
provide a closed loop feedback that reads the distance something
moves using an encoder and compare that with what was sent to the
motors to see if it really did do it. The normal stepper system
controller takes the g-command, figures out how many pulses to send
to the motor to get to the next location and assumes the motor did
it. Steppers move in precise increments (most are 1.8 deg of arc per
pulse = 200 pulses per revolution) you then have to do some math the
calculate how far this will actually move your axis given that most
system are moved with course threads of 5 threads per inch.
The "lead" of a screw is the number of times we have to turn it to
make a nut travel one inch. All this math is setup in the controller
and control software. You define how many steps it takes on each
axis to move an inch (or mm). Then the controller knows how many
pulses to send the motor. If you have a servo based system then it
is referred to as a "closed loop system". It most often is not used
with steppers but with DC motors (can be AC in some cases) that are
not limited to a minimum step. The motor has an encoder attached to
it that sends back a pulses as it rotates and we just power the motor
in the direction we want until the number of return pulses are equal
to the number we have defined as the proper pulses per inch. Servo
systems "know" where they are. Stepper systems "assume" where they
are. We could write a book about the advantages of each system.
Obviously the servo is much more complex and expensive to build.
So far we are still in the controller. The controller can be
anything from a "black box" to a PC. There is a generation of
software that runs on a PC and either talks to a special Input/Output
card or through the parallel port. It just sends out simple step and
direction pulses to each motor and can be used to monitor the limit
switches and turn on relays for auxilliary equipment. The output from
a parallel port is not enough to drive a motor so a motor driver
circuit is used to amplify the voltage and current. The size and
complexity of the motor drive circuit is dependent on the size of the
motors. Since motors are basically current devices we slam them with
pulses of higher voltage and let them draw high peak currents.
So far we have just talked about the controller and the motor drive
circuits. If we have our g-code in hand and feed it to the
controller then we should be able to make the machine do whatever we
want. (well, it won't clean up after itself). Entire production runs
of parts have been made using g-code that a coder sat down and wrote
step by step with nothing more fancy than a calculator and editor.
For those of use that no longer get excited about hand coding g-codes
there are other methods. Prior to the post processors of today you
had to take a CAD drawing (or one done by a draftsman) and write your
own code. What somebody finally figured out was that you could take
the raw CAD files that are actually stored as vector math relations
and turn it into g-code...most standard CAD systems will export in a
common file format called DXF (drawing exchange format). What you
want is some that will take the DXF output file from a CAD or
Illustration program and turn it into g-code that the Control
software can turn into machine moves. EMC is a controller software
for controlling the motors and taking feedback from motor encoders
and limit switches. It wants g-code (RS-274).
The rub comes in that not all DXF to g-code translators are good and
very few let you graphically change any of the cut paths they
produce. You have to go back into the g-code and make the changes
manually; which is whole reason you bought a translator to begin with!
Several system combine two or more of these functions in one package
but in most cases you have to deal with seperate software and
hardware packages for each step.
So to summerize: You draw or import a drawing into your CAD or
Illustration software (Autocad, CorelDraw, etc) and export it to a
file of DXF type (or in some cases HPGL). You then run that through
a software process to turn it into g-code (a simple ASCII file) and
then you send that code to the controller (EMC, MasterControlCNC,
DeskNC etc) which then drives the motors that move the
machine....simple huh?
The statement should be: We are trying to build a universal
controller software package that is based on open code, that will run
on just about any kind of computer and that will control just about
anything.
> Never mind - the LinuxCNC.org site has a sane description of it.develop and validate
>
> Despite 20 years in the software biz,
>
> "The Enhanced Machine Controller (EMC) program is a NIST effort to
> a specification for interfaces to open architecture controllers."make some software.
>
> is still utter nonsense. To parse this -
>
>
> The Enhanced Machine Controller (EMC) program <-- EMC
>
> is a NIST effort <-- that's in English already
>
> to develop and validate a specification for interfaces <-- to
>Ohh, Ohh let me try! A long time ago (in Computer Years) they built
> to open architecture <-- we're gonna make it public
machines (mills, lathes, punch presses) and developed a quasi
standard for the language to control them often referred to as G-
code. Its pretty simplistic and consists of Go commmands that give
an X and Y corroridinates. The X & Y can either be absolute (always
referenced from the 0,0 pint of the machine or incremental (each move
is from the last one) Over the years the code has expanded to cover
specific machine commands to deal with automatic tool changers,
misters, etc. The Control software is responsible to take the G-code
in and do things like issue the correct number of steps and direction
signals to each axis of the machine. 2 axis machine have X (normally
left and right as you stand in front of the machine, and Y, normally
forward and reverse from the same position. The Z axis is normally
an up and down (verticle) axis. There can be others like a rotary
axis and such. If you haven't seen any g-code then you haven't
missed much. The control software has the responsibility to do
things like automatically ramp up and down the motor speeds, monitor
the limit switches to keep things from spinning off onto the floor
and in general move the mechanics of the machine. It can also
provide a closed loop feedback that reads the distance something
moves using an encoder and compare that with what was sent to the
motors to see if it really did do it. The normal stepper system
controller takes the g-command, figures out how many pulses to send
to the motor to get to the next location and assumes the motor did
it. Steppers move in precise increments (most are 1.8 deg of arc per
pulse = 200 pulses per revolution) you then have to do some math the
calculate how far this will actually move your axis given that most
system are moved with course threads of 5 threads per inch.
The "lead" of a screw is the number of times we have to turn it to
make a nut travel one inch. All this math is setup in the controller
and control software. You define how many steps it takes on each
axis to move an inch (or mm). Then the controller knows how many
pulses to send the motor. If you have a servo based system then it
is referred to as a "closed loop system". It most often is not used
with steppers but with DC motors (can be AC in some cases) that are
not limited to a minimum step. The motor has an encoder attached to
it that sends back a pulses as it rotates and we just power the motor
in the direction we want until the number of return pulses are equal
to the number we have defined as the proper pulses per inch. Servo
systems "know" where they are. Stepper systems "assume" where they
are. We could write a book about the advantages of each system.
Obviously the servo is much more complex and expensive to build.
So far we are still in the controller. The controller can be
anything from a "black box" to a PC. There is a generation of
software that runs on a PC and either talks to a special Input/Output
card or through the parallel port. It just sends out simple step and
direction pulses to each motor and can be used to monitor the limit
switches and turn on relays for auxilliary equipment. The output from
a parallel port is not enough to drive a motor so a motor driver
circuit is used to amplify the voltage and current. The size and
complexity of the motor drive circuit is dependent on the size of the
motors. Since motors are basically current devices we slam them with
pulses of higher voltage and let them draw high peak currents.
So far we have just talked about the controller and the motor drive
circuits. If we have our g-code in hand and feed it to the
controller then we should be able to make the machine do whatever we
want. (well, it won't clean up after itself). Entire production runs
of parts have been made using g-code that a coder sat down and wrote
step by step with nothing more fancy than a calculator and editor.
For those of use that no longer get excited about hand coding g-codes
there are other methods. Prior to the post processors of today you
had to take a CAD drawing (or one done by a draftsman) and write your
own code. What somebody finally figured out was that you could take
the raw CAD files that are actually stored as vector math relations
and turn it into g-code...most standard CAD systems will export in a
common file format called DXF (drawing exchange format). What you
want is some that will take the DXF output file from a CAD or
Illustration program and turn it into g-code that the Control
software can turn into machine moves. EMC is a controller software
for controlling the motors and taking feedback from motor encoders
and limit switches. It wants g-code (RS-274).
The rub comes in that not all DXF to g-code translators are good and
very few let you graphically change any of the cut paths they
produce. You have to go back into the g-code and make the changes
manually; which is whole reason you bought a translator to begin with!
Several system combine two or more of these functions in one package
but in most cases you have to deal with seperate software and
hardware packages for each step.
So to summerize: You draw or import a drawing into your CAD or
Illustration software (Autocad, CorelDraw, etc) and export it to a
file of DXF type (or in some cases HPGL). You then run that through
a software process to turn it into g-code (a simple ASCII file) and
then you send that code to the controller (EMC, MasterControlCNC,
DeskNC etc) which then drives the motors that move the
machine....simple huh?
The statement should be: We are trying to build a universal
controller software package that is based on open code, that will run
on just about any kind of computer and that will control just about
anything.
Discussion Thread
Jon Elson
1999-06-06 17:00:33 UTC
EMC
Fred Proctor
1999-06-09 13:44:23 UTC
EMC
Mo
1999-06-09 19:07:53 UTC
Re: EMC
Tim Goldstein
1999-06-09 23:16:54 UTC
Re: EMC
Tim Goldstein
1999-06-15 20:18:41 UTC
Re: EMC
Dan Falck
1999-06-16 04:07:23 UTC
Re: EMC
Ian W. Wright
1999-07-29 13:03:47 UTC
Re: EMC
chda@x...
1999-10-12 08:48:51 UTC
EMC
batwings@x...
1999-10-12 00:29:11 UTC
Re: EMC
Darrell Gehlsen
1999-10-12 10:08:41 UTC
Re: EMC
Kahl Klemm
1999-11-11 10:16:23 UTC
EMC
Tim Goldstein
1999-11-21 13:05:08 UTC
RE: EMC
Karl Klemm
1999-11-21 17:55:11 UTC
RE: EMC
Tim Goldstein
1999-11-21 18:55:40 UTC
RE: EMC
Karl Klemm
1999-11-22 08:43:09 UTC
RE: EMC
hansw
1999-11-22 08:57:30 UTC
Re: EMC
Tim Goldstein
1999-11-22 09:25:51 UTC
Re: EMC
James Cullins
2000-04-19 17:24:43 UTC
EMC
Tim Goldstein
2000-04-19 19:53:13 UTC
RE: [CAD_CAM_EDM_DRO] EMC
Dan Mauch
2000-04-20 05:59:37 UTC
Re: [CAD_CAM_EDM_DRO] EMC
James Cullins
2000-04-20 06:28:07 UTC
Re: [CAD_CAM_EDM_DRO] EMC
Tim Goldstein
2000-04-20 06:34:52 UTC
RE: [CAD_CAM_EDM_DRO]DeskNCrt, was: EMC
Chris Salter
2000-08-31 08:07:25 UTC
EMC
Anne Ogborn
2000-10-09 16:45:06 UTC
EMC
ballendo@y...
2000-10-09 20:10:22 UTC
re:EMC
Anne Ogborn
2000-10-10 10:31:18 UTC
Re: [CAD_CAM_EDM_DRO] re:EMC
Anne Ogborn
2000-10-10 10:55:06 UTC
Re: [CAD_CAM_EDM_DRO] re:EMC
Jon Elson
2000-10-10 12:02:19 UTC
Re: [CAD_CAM_EDM_DRO] re:EMC
ballendo@y...
2000-10-10 15:23:51 UTC
Re: re:EMC
Jon Elson
2000-10-10 15:59:44 UTC
Re: [CAD_CAM_EDM_DRO] Re: re:EMC
ballendo@y...
2000-10-10 16:36:21 UTC
Re: Re: re:EMC
Tom Caudle
2000-10-10 17:04:19 UTC
Re: re:EMC
ballendo@y...
2000-10-10 18:02:34 UTC
RE:re: EMC
Tom Caudle
2000-10-10 18:08:41 UTC
Re: RE:re: EMC
dave engvall
2000-10-10 18:11:59 UTC
Re: [CAD_CAM_EDM_DRO] RE:re: EMC
Anne Ogborn
2000-10-10 19:15:14 UTC
Re: [CAD_CAM_EDM_DRO] Re: re:EMC
Anne Ogborn
2000-10-10 19:24:24 UTC
Re: [CAD_CAM_EDM_DRO] RE:re: EMC
ballendo@y...
2000-10-10 19:27:08 UTC
re:RE: EMC
Tom Caudle
2000-10-10 19:47:22 UTC
Re: re:EMC
Anne Ogborn
2000-10-10 21:44:53 UTC
Re: [CAD_CAM_EDM_DRO] Re: re:EMC
catboat15@a...
2000-10-11 09:40:45 UTC
Re: [CAD_CAM_EDM_DRO] Re: re:EMC
ballendo@y...
2000-10-11 20:53:09 UTC
re:Re:rE:RE: EMC
barker1@m...
2000-11-03 05:11:59 UTC
EMC
Dan Falck
2000-11-03 05:29:18 UTC
Re: [CAD_CAM_EDM_DRO] EMC
Tim Goldstein
2000-11-03 09:10:56 UTC
RE: [CAD_CAM_EDM_DRO] EMC
Jon Elson
2000-11-03 12:08:09 UTC
Re: [CAD_CAM_EDM_DRO] EMC
Scott Hendershot
2002-03-28 10:48:22 UTC
EMC
j.guenther
2002-03-28 11:11:32 UTC
RE: [CAD_CAM_EDM_DRO] EMC
Tim Goldstein
2002-03-28 11:13:06 UTC
Re: [CAD_CAM_EDM_DRO] EMC
Kos
2002-03-28 12:25:40 UTC
Re: EMC
Paul
2002-03-28 12:32:25 UTC
Re: [CAD_CAM_EDM_DRO] EMC
Scott Hendershot
2002-03-28 14:14:31 UTC
Re: [CAD_CAM_EDM_DRO] EMC
Tim Goldstein
2002-03-28 15:04:41 UTC
Re: [CAD_CAM_EDM_DRO] EMC
William Scalione
2002-03-28 21:43:04 UTC
Re: [CAD_CAM_EDM_DRO] EMC
Jon Elson
2002-03-28 22:25:04 UTC
Re: [CAD_CAM_EDM_DRO] EMC
Bill Vance
2002-03-28 23:14:09 UTC
Re: [CAD_CAM_EDM_DRO] EMC
Darrell Daniels
2002-03-28 23:26:40 UTC
Re: [CAD_CAM_EDM_DRO] EMC
Darrell Daniels
2002-03-28 23:31:42 UTC
Re: [CAD_CAM_EDM_DRO] EMC
Gene
2002-05-06 13:10:29 UTC
EMC
Tim Goldstein
2002-05-06 14:39:30 UTC
Re: [CAD_CAM_EDM_DRO] EMC
Ray Henry
2002-05-06 21:09:41 UTC
Re: EMC
Jon Elson
2002-05-06 22:05:51 UTC
Re: [CAD_CAM_EDM_DRO] EMC
Gene
2002-05-07 15:18:50 UTC
EMC
Gene
2002-05-09 00:36:24 UTC
EMC
Ian W. Wright
2002-05-09 07:43:53 UTC
Re: [CAD_CAM_EDM_DRO] EMC
Gene
2002-05-09 10:32:03 UTC
EMC
Jon Elson
2002-05-09 22:30:55 UTC
Re: [CAD_CAM_EDM_DRO] EMC
Gene
2002-05-26 20:20:00 UTC
EMC
Jon Elson
2002-05-26 23:21:03 UTC
Re: [CAD_CAM_EDM_DRO] EMC
IMService
2002-06-06 06:14:50 UTC
Re: EMC
Gene
2002-08-18 16:07:21 UTC
EMC
John Guenther
2002-08-18 19:48:08 UTC
RE: [CAD_CAM_EDM_DRO] EMC
Jon Elson
2002-08-18 20:34:54 UTC
Re: [CAD_CAM_EDM_DRO] EMC
dakota8833
2002-08-23 05:12:23 UTC
EMC
Tom Benedict
2002-08-23 08:15:46 UTC
Re: [CAD_CAM_EDM_DRO] EMC
Ray Henry
2002-08-23 14:50:49 UTC
Re: EMC
Les Watts
2002-08-23 15:28:41 UTC
Re: [CAD_CAM_EDM_DRO] Re: EMC
Gene
2002-11-18 21:30:53 UTC
EMC
Jon Elson
2002-11-19 21:04:40 UTC
Re: [CAD_CAM_EDM_DRO] EMC
Gene
2002-11-19 21:16:30 UTC
Re: [CAD_CAM_EDM_DRO] EMC
Tim Goldstein
2002-11-19 21:57:45 UTC
RE: [CAD_CAM_EDM_DRO] EMC
Matt Shaver
2002-11-19 22:14:29 UTC
Re: [CAD_CAM_EDM_DRO] EMC
William Scalione
2002-11-19 23:00:43 UTC
Re: [CAD_CAM_EDM_DRO] EMC
Tim Goldstein
2002-11-19 23:30:51 UTC
RE: [CAD_CAM_EDM_DRO] EMC
Jon Elson
2002-11-20 10:29:21 UTC
Re: [CAD_CAM_EDM_DRO] EMC
Yesamazza@a...
2003-02-08 09:09:21 UTC
EMC
William Scalione
2003-02-08 09:34:15 UTC
Re: [CAD_CAM_EDM_DRO] EMC
Vince Negrete
2003-09-15 03:25:04 UTC
EMC
Gene
2004-08-06 16:17:38 UTC
EMC