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