> > > Paul wrote:
The big problem is the software that reads the G & M codes off the
hard
disk, sends the proper commands to the motion control card and
generates
the user interface on the LCD and PC keyboard. Do you have
something in
mind for
that. Seems that software would be custom for each motion control
card
design. Can that be bought off the shelf for some motion control
chips set?
Mark Wrathall wrote:
That's why it is cheaper to dump the motion control cards on Ebay,
and buy
Gecko's. Both the Stepper (G210)and Servo (G320) geckos accept step
and
direction input from a parallel port. There are about a dozen
software which
convert G and M code to step and direction conmmands. TurboCNC
(DOS), MACH2
(WIN XP) and EMC are the three best choices (from the
CAD_CAM_EDM_DRO
group).
EMC can also be set up with the servo-to-go cards if you want true
closed
loop control. In practice the G320 version is fine (PC sends open
loop
STEP/Dir commands - Gecko controls the servo's closed loop to
acheive that -
Gecko's fault out and report to the PC if the command can't be met
(not
likely).
Note the G & M code is not really standardized. The 1974 RS-274 (?)
standard
is not adhered to. Obviously EG, on a Rapid (G00) one controller
might clear
Z first, and then do a coordinated X, Y move, another controller
(like
TurboCNC) might do a coordinated move in all three axis, and a third
controller might send all axis off at their own topspeed. Whatever
Controller SW you end up with you need to be sure that your CAM
program has
a Post processor to output your dialect of G code.
The PC based controller mentioned above are generally better at
sticking to
the mainstream defacto standard (FANUC) then many OEM controllers.
Regards,
Mark
Something I still don't understand Mark. My servo amps require +/- 10
Volt
analog control signals. How do you get that out of a parallel port?
Paul Lamar
American Flyer wrote:
Paul,
Not to ruffle any feathers, but you probably want to steer well
clear of any parallel port based controllers (or at least understand
their limitations). I researched them well before deciding to do
my own controller. The problem with them is that since they output
directly from the parallel port to hardware control with no buffer
(such as a FIFO or a processor using some RAM), they are
dependent on the PC for timing. The timing is generated by software,
which means that a preemptive multitasking operating system
such as Windows will cause significant random delays to be introduced
between steps of revolution. This manifests itself as random
jerking in the servo motor rotation. It makes accurate multi-axis
interpolated moves all but impossible. It also wreaks havoc on a
Stepper-motor based system because you either have to run it at a
small fraction of the feedrate it is capable of, or it will skip
steps during Windows-induced pauses because of motor inertia. A
lot of people have gotten around this by writing their software to
run in DOS mode, or in Linux. For DOS versions, you actually have
to boot the PC in DOS mode. You can't just run the software in a
DOS window and expect great results. I won't use Linux for anything
except web surfing, so neither of those options is acceptable to
me. Those parallel port based systems are for hobby mills such as
the Sherline, or MaxNC. You have a real piece of machinery there,
and I think you'd be disappointed with a hobby controller. Go to
the user groups and read all of the complaints by people who use
them. I know that the software that comes with the MaxNC mills runs in
DOS.
There are a few systems out there which communicate via a serial
port instead of parallel port. These systems have much better
performance because the timing is generated by the processor
receiving high-level commands instead of by the PC. These systems cost
a good bit more than the parallel port based systems, but are
probably a reasonable alternative to a $4000 controller. The ones I've
looked at are in the $700 to $1000 range (not including motor
drivers). One of these controllers with some Gecko 320s might work out
well, but you would need to make a few changes to your mill.
First, the Geckos won't read resolver or tach outputs so you would need
to add digital shaft encoders for Gecko feedback. Second, the
Geckos take a max supply voltage of 80V, but your mill uses a DC
supply of over 100V to drive the motors. You would need to do
something to provide a lower voltage (at about 14 amps).
The non-standard G code situation is not really a big deal.
Most CAM software (even free ones like FreeMill) come with a
customizable post processor, which allows them to drive virtually
anything once you set it up.
As far as the system I'm developing goes, I will write the software
which translates the G/M codes. I will make a point of emulating
some common standard such as Fanuc. It should work with any CAM
software. My hardware controller will have a separate processor
which receives low level position information from the PC via a
USB port, and provides precise timing control allowing interpolated
moves in all 3 (or 4) axis. I have in mind to add a fourth axis
to my Kasuga, so I am designing the system to accommodate that as
well.
Harrison Young
Harrison make some good points. But the Paul I know from this list used to
rave about how fast AutoCAD 12 ran on an Athlon under DOS. DOS is still the
best OS Microsmurf ever made. It boots nearly instantly, is rock stable, no
longer changing. Doesn't start getting flaky after one power cut, etc. So
you can internet surf, but checking your email on your Mill controller never
seemed like such a good idea anyway.
DOS is used by the majority of the PC based controller software, because it
dosn't stop to inspect it's navel for 90ms at random. TurboCNC generates a
clean pulse rate up to ~50kHz (V3.24), with V4 having been optimised for
the Pentium class, it is beta testing at around 100kHz. Running 5tpi
ballscrews, direct drive with 2000 count (qudrature) encoders in 1/10
microstepping mode, this frequency whould be good for rapids to 60
Inches/minute, if thats too slow, the Gecko G340's offer selectable level of
microstepping down to 1:1
The PC based software that best gets around Windows lack of real time
performance is MACH2, which used some very fancy programming to get beneath
the OS. It is limited to 45Khz, and has an excellent reputation.
EMC uses either a red hat 6.xx kernal patch for real time perfomance, or Red
hat 7x with a different kernal patch. It was written with your tax money by
the NIST. It is probably the most powerful of the above, bt is tied with
Linux's learning curve (which you are already familiar with.)
On the near horizon, The Gecko G2003 is the USB device which has just gone
into production. Both Mach2 and TurboCNC software versions are being
developed at present to support this device. The Software will interpret the
G code, and output lower level motion commands, The G2003 will buffer these,
and produce a step/dir pulse stream up to 250Khz, with constant velecity
contouring in real time. Mariss's target price on these 6 Axis devices is
~$300!!!
To get well informed on this stuff, the Geckodrive forum
http://groups.yahoo.com/group/geckodrive/ ,and the CAD_CAM_EDM_DRO groups
are both full of very experience engineers.
http://groups.yahoo.com/group/CAD_CAM_EDM_DRO/
Regards,
Mark
The AirCraft Rotary Engine NewsLetter. Powered by Linux.
ACRE NL web site. http://home.earthlink.net/~rotaryeng/
Copyright 1998-2003 All world wide rights reserved.