Re: [CAD_CAM_EDM_DRO] Conversational Programming and NAMES- very long!
Posted by
Matt Shaver
on 2000-05-04 16:56:21 UTC
> From: Tim Goldstein <timg@...>54ipm to be exact, perhaps it's because I was using a scale of 4000, I don't
> Interesting...
>
> When I talked to Matt Shaver about his Bridgeport conversion he said he was
> able to get 60 ipm if I remember correctly. Makes you wonder why he managed
> 3X the speed you are getting??
know for sure. That said, Darrell is right, the stepper pulse output of the
EMC, even using freqmod, isn't good enough for some machine configurations. I
think it's a combination of things:
1. The machines Darrell and I are trying to retrofit have much more mass in
each axis to sling around than a mill drill or Sherline, or even a Shoptask,
although they're closer to Bridgeport size than most hobbiest machines.
2. The motors Darrell and I are using are old technology. Most hobbiests use
newer motors with greatly superior characteristics.
3. People who buy a Bridgeport retrofit expect rapid feed rates of at least
100 ipm (the stock machine would do 120 ipm), while most Sherline operators
could probably get by with 50 ipm ;) .
AFAIK the existing control programs that are capable of high output steps
rates _AND_ close grained frequency control of the step rate _AND_ negligible
jitter use external hardware (outside the standard PC) to generate or somehow
control the step pulses. Examples of these are AHHA, and Flashcut. For
reasons that take about a page of typing to explain (see the archives),
software only solutions break down at high step pulse rates. The one possible
exception to this is Indexer LPT, although I don't have personal experience
with it (does anyone here use it?). I would love to know if anyone has done
any experiments to measure the performance of I-LPT, specifically I'd like to
know the granularity of the frequency control from DC to it's maximum output
rate and the guaranteed maximum jitter (however they would like to specify
it). If it turns out that I-LPT achieves all the three above mentioned
performance goals _AND_ still allows the user interface to operate normally
while the machine is in motion, then it's definitely worth the price charged.
The approach I would use (will use if I ever do anything else with steppers)
would be to employ an external programmable frequency generator, probably in
the form of an Intel 8254 CTC that would be controlled by the EMC software.
The step signals (from the 8254's output) and the direction signals (from a
general purpose digital I/O port) would go to the stepper motor drive
circuitry and also be fed back into a counter circuit (like the LSI Logic
7266) that would accumulate the position count for each axis. To the EMC this
would look just like a servo system. The EMC would send out velocity commands
to the 8254 and read back position data from the counter. This servo loop
would be processed at a kilohertz or so just like any other servo system. In
fact, you could get position feedback from a linear scale if you would prefer
and that wouldn't change anything in the software (actually there are a few
issues such as the difference in resolution between one stepper step and one
encoder count, but this could be worked out). It's interesting to note that
this is exactly a mirror image of the approach taken by Bill Wainwright with
his Servo-Lite setup.
Matt
Discussion Thread
james owens
2000-05-03 09:25:11 UTC
Re: [CAD_CAM_EDM_DRO] Conversational Programming and NAMES- very long!
Paul Devey
2000-05-03 17:10:47 UTC
Re: [CAD_CAM_EDM_DRO] Conversational Programming and NAMES- very long!
Jon Elson
2000-05-03 20:50:09 UTC
Re: [CAD_CAM_EDM_DRO] Conversational Programming and NAMES- very long!
bfp
2000-05-03 21:25:48 UTC
Re: [CAD_CAM_EDM_DRO] Conversational Programming and NAMES- very long!
Darrell
2000-05-04 10:54:52 UTC
Re: [CAD_CAM_EDM_DRO] Conversational Programming and NAMES- very long!
Tim Goldstein
2000-05-04 12:03:48 UTC
Re: [CAD_CAM_EDM_DRO] Conversational Programming and NAMES- very long!
Darrell
2000-05-04 15:07:14 UTC
Re: [CAD_CAM_EDM_DRO] Conversational Programming and NAMES- very long!
Tim Goldstein
2000-05-04 15:34:29 UTC
Re: [CAD_CAM_EDM_DRO] Conversational Programming and NAMES- very long!
Matt Shaver
2000-05-04 16:56:21 UTC
Re: [CAD_CAM_EDM_DRO] Conversational Programming and NAMES- very long!
Carlos Guillermo
2000-05-04 17:51:06 UTC
RE: [CAD_CAM_EDM_DRO] Conversational Programming and NAMES- very long!
Matt Shaver
2000-05-04 18:23:39 UTC
Re: [CAD_CAM_EDM_DRO] Conversational Programming and NAMES- very long!
paul@a...
2000-05-04 18:23:52 UTC
Re: [CAD_CAM_EDM_DRO] Conversational Programming and NAMES- very long!
lawrence jackman
2000-05-04 21:13:50 UTC
Re: [CAD_CAM_EDM_DRO] Conversational Programming and NAMES- very long!
Jon Elson
2000-05-04 22:20:01 UTC
Re: [CAD_CAM_EDM_DRO] Conversational Programming and NAMES- very long!
Darrell
2000-05-05 00:07:27 UTC
Re: [CAD_CAM_EDM_DRO] Conversational Programming and NAMES- very long!
wanliker@a...
2000-05-06 10:22:23 UTC
Re: [CAD_CAM_EDM_DRO] Conversational Programming and NAMES- very long!