CAD CAM EDM DRO - Yahoo Group Archive

Re: [CAD_CAM_EDM_DRO] Re: Lost Steps => time for microprocessors!

Posted by Art Fenerty
on 2000-08-29 18:22:55 UTC
I think both answers are true. For applications like mine ( wood engraving)
PC control is fine. My table runs with little hesitation if any and cut's
well enough for wood applications. I get .08mm resolution at about 2" per
second. But if Machining metal is your thing and you want any real speed at
all, then a microprocessor control is probably the thing to use. The rule
here, is that there are no rules. As computers get faster however, they
certainly become the most cost effective answer. Generally, the stronger the
stepper motor, the less speed you need. Speed is really only required when
you reduce the ratio's to increase the torque.

Some of us consider the quite reasonable cost of $100-$200 an axis to be
horrendously expensive for a hobby, where a guy making money in a shop will
consider it quite cheap. Sooner or later the perfect algorithm will come
along.
It's all a question of speed and application. One mans junk.....

Art

----- Original Message -----
From: "dave engvall" <dengvall@...>
To: <CAD_CAM_EDM_DRO@egroups.com>
Sent: Tuesday, August 29, 2000 6:43 PM
Subject: Re: [CAD_CAM_EDM_DRO] Re: Lost Steps => time for microprocessors!


>
> ballendo@... wrote:
>
> >
> > Ron,
> >
> > Using an outboard processor is the time-proven way to do cnc. But
> > even some of the big boys are using the PC itself for motion tasks.
> > In effect, the PC IS THE OUTBOARD PROCESSOR. Look inside modern
> > commercial CNC machines, you may find 2 or 3 PC motherbds! One for
> > motion, one for GUI/ network, maybe one for IO.
> >
> > >Why do we insist on having the PC do the pulses? The PC ought to do
> > >GUI, Math,Lookahead, etc.<snip>
> >
> > Several reasons come to mind:
> >
> > Cost = Lower (obvious)
> >
> > Maintennance = Easy (tens of THOUSANDS of programmers familiar with PC
> > / no extra hardware to fail/ troubleshoot/ service.
> >
> > Manufacturing considerations = Less potential for problems/ rework/
> > third-party vendor delays/ warranties on addt'l hardware/ Parts
> > availability or change of spec /
> >
> > Natural Progression of technology = PC's faster all the time, so its
> > getting easier!
> >
> > Versatility and Improvements = Change the code / change the product
> > capability
> >
> > Open architecture = Exactly the problem you mentioned w/Fashcut is
> > avoided
> >
> > There are other reasons, but these show some "whys"
> >
> > >Yes, Linux has a 'real time'capability <snip>
> >
> > Linux's real-time capability rests on the standard PC hardware!
> >
> > The only real limitation at this point is the ingenuity to use the
> > parts of the PC system WELL. As you know, there is a tendency towards
> > "this is how its done" or "It's always been done that way". But, our
> > platform (the PC) is changing. The pentium RSTCD instruction (not
> > sure i've got that code exactly right) gives us timing resolution AT
> > THE SPEED OF THE PROCESSOR! Just that not everyone has pentiums, yet.
> > The 8254 timer can be (currently, this is how RTLinux is done)
> > programmed to 838ns. Interrupt latency adds to this, but EMC shows it
> > CAN BE DONE.
> >
> > There ARE VXD's (virtual device drivers,used by win9X,NT,and WinME)
> > available which support "real-time" windows; They are just VERY
> > expensive.
> >
> > I think Art Fenerty's "Master" program is on the right track. Maybe
> > "Kcam" also (kellyware.com) but I don't know kcams' internal
> > architecture. They both need some polish for sure, but they are
> > taking advantage of the points listed above.
> >
> > Also, JonE's msg is right on the mark, I think. If you're going to
> > leave the PC to the tasks you mentioned, then let's use a low-
> > cost,simple approach capable of hi-speed. Step-rates are increasing
> > all the time (microsteppers, and servos are driving this)
> >
> > And,the cybernetics Cy545 chips someone mentioned were $75/axis!!! in
> > 1994! Other motion chips and boards work extremely well , but again,
> > they cost arms and legs.
> >
> > I would love to see you put your programming time into using (well)
> > the PC parts we have. With your UNIX background (from earlier posts)
> > I am sure you could advance the state of the art!
> >
> > Ballendo
> >
> > P.S. One area that seems to be left behind in modern programming is
> > the use of some of the "old tricks" used when PC's were slow, narrow
> > bitted, memory poor creatures. We just code up the high math and let
> > the incredible speed of the processor "make up for it". I believe
> > that the use of some of these "old tricks" will free up enough
> > processor time to EASILY accomplish it all on one PC!
>
> When speed is important; find/code a better algorithm.
> Multiple devices especialy Jon's fpld sound like the right approach.
>
> Dave
>
>
> Welcome to CAD_CAM_EDM_DRO@...,an unmoderated list for the
discussion of shop built systems, for CAD, CAM, EDM, and DRO.
>
> Addresses:
> Post message: CAD_CAM_EDM_DRO@egroups.com
> Subscribe: CAD_CAM_EDM_DRO-subscribe@egroups.com
> Unsubscribe: CAD_CAM_EDM_DRO-unsubscribe@egroups.com
> List owner: CAD_CAM_EDM_DRO-owner@egroups.com, wanliker@...
> Moderator: jmelson@... [Moderator]
> URL to this page: http://www.egroups.com/group/CAD_CAM_EDM_DRO
> FAQ: http://www.ktmarketing.com/faq.html
> bill,
> List Manager
>

Discussion Thread

wanliker@a... 2000-08-29 13:53:51 UTC Re: [CAD_CAM_EDM_DRO] Re: Lost Steps => time for microprocessors! Jon Elson 2000-08-29 16:02:05 UTC Re: [CAD_CAM_EDM_DRO] Re: Lost Steps => time for microprocessors! Jeff Barlow 2000-08-29 17:00:15 UTC Re: [CAD_CAM_EDM_DRO] Re: Lost Steps => time for microprocessors! dave engvall 2000-08-29 18:01:28 UTC Re: [CAD_CAM_EDM_DRO] Re: Lost Steps => time for microprocessors! dave engvall 2000-08-29 18:04:35 UTC Re: [CAD_CAM_EDM_DRO] Re: Lost Steps => time for microprocessors! Jeff Barlow 2000-08-29 18:22:38 UTC Re: [CAD_CAM_EDM_DRO] Re: Lost Steps => time for microprocessors! Art Fenerty 2000-08-29 18:22:55 UTC Re: [CAD_CAM_EDM_DRO] Re: Lost Steps => time for microprocessors! Jon Elson 2000-08-29 22:38:06 UTC Re: [CAD_CAM_EDM_DRO] Re: Lost Steps => time for microprocessors! Jon Elson 2000-08-29 22:59:34 UTC Re: [CAD_CAM_EDM_DRO] Re: Lost Steps => time for microprocessors! Ron Ginger 2000-08-30 06:45:19 UTC Re: [CAD_CAM_EDM_DRO] Re: Lost Steps => time for microprocessors! dave engvall 2000-08-30 07:22:01 UTC Re: [CAD_CAM_EDM_DRO] Re: Lost Steps => time for microprocessors! Tim Goldstein 2000-08-30 08:53:10 UTC RE: [CAD_CAM_EDM_DRO] Re: Lost Steps => time for microprocessors! Alan Marconett KM6VV 2000-08-30 10:49:52 UTC Re: [CAD_CAM_EDM_DRO] Re: Lost Steps => time for microprocessors! Jeff Barlow 2000-08-30 11:45:52 UTC Re: [CAD_CAM_EDM_DRO] Re: Lost Steps => time for microprocessors! Jon Elson 2000-08-30 12:50:42 UTC Re: [CAD_CAM_EDM_DRO] Re: Lost Steps => time for microprocessors! Jon Elson 2000-08-30 13:17:03 UTC Re: [CAD_CAM_EDM_DRO] Re: Lost Steps => time for microprocessors! Jon Elson 2000-08-30 13:27:27 UTC Re: [CAD_CAM_EDM_DRO] Re: Lost Steps => time for microprocessors! Carlos Guillermo 2000-08-30 21:19:10 UTC RE: [CAD_CAM_EDM_DRO] Re: Lost Steps => time for microprocessors! Jon Elson 2000-08-31 13:41:53 UTC Re: [CAD_CAM_EDM_DRO] Re: Lost Steps => time for microprocessors!