Re: [CAD_CAM_EDM_DRO] Re: step pulse timing resolution
Posted by
Art Fenerty
on 2000-10-14 10:51:37 UTC
Unless your microstepping the time remains constant. Thats why microstepping
is so much smoother.
Art
is so much smoother.
Art
----- Original Message -----
From: "Terry Ackland" <hexagon@...>
To: <CAD_CAM_EDM_DRO@egroups.com>
Sent: Saturday, October 14, 2000 6:11 AM
Subject: [CAD_CAM_EDM_DRO] Re: step pulse timing resolution
> Hi,
> just a side question that is related to steppers.
> When the feed is altered using F does the motor really slow down or
> is
> just the pause in between the steps that just get longer and the
> actual time taken to move from one step to the other remains the same?
> Terry Ackland
>
> --- In CAD_CAM_EDM_DRO@egroups.com, "Art Fenerty" <fenerty@h...>
> wrote:
> > Ballendo:
> >
> > Couldn't agrre more.
> > Art
> > ----- Original Message -----
> > From: <ballendo@y...>
> > To: <CAD_CAM_EDM_DRO@egroups.com>
> > Sent: Friday, October 13, 2000 8:27 PM
> > Subject: [CAD_CAM_EDM_DRO] Re: Re: step pulse timing resolution
> >
> >
> > > Jon Elson Wrote:
> > > >Well, using a timer, it is easy to do arbitrary granularity for
> ONE
> > > >axis, but it gets into big trouble with 2 or more! What if you
> have
> > > >two axes that need pulses that will come out very close together?
> > > >Of course, you can have some code that figures out when this is
> > > >going to happen, fudges the pulses at the same
> > > >time, and then compensates later. The more axes, the more fudging
> > > >will go on.
> > >
> > > Jon,
> > >
> > > You are exactly right.
> > >
> > > Unless you are running co-ordinated and independant timing for
> each
> > > axis you WILL have these sorts of issues. And if perfection of
> motion
> > > is the goal, you will be limited TO such a setup.
> > >
> > > Everything we do here is about defining, determining and
> controlling
> > > the error(s).
> > >
> > > Its always:
> > > 1.Where are we? (current position)
> > > 2.Where SHOULD we be? (commanded position)
> > > 3.Are we close enough to where we SHOULD be? (error)
> > > 4.If not,What do we NEED to do to get there? (correction)
> > >
> > > With one timer, we must "slave" the axes to some "master".
> > > Traditionally this "master" is the axis making the longest move.
> All
> > > other axes are run at some sub-multiple of this.
> > >
> > > As long as these sub-axes(distance) are factors of the "master",
> time
> > > and position correspond and there is no problem. For example:
> > >
> > > With x=12,y=4,z=3 (numbers are in steps/units to move) we can set
> any
> > > arbitrary "rate" of pulse output, and the position at any point is
> > > exactly where it should be.
> > >
> > > But if x=12,y=5,z=7, we've got problems! This is where traditional
> > > stepper systems and servo systems diverge.
> > >
> > > As a blanket statement(please don't beat me up re: this) Stepper
> > > systems control position directly; servo systems control position
> as
> > > a function of time.
> > >
> > > So the stepper system says, How the heck am I gonna get 5 and 7
> steps
> > > divided evenly into 12??? and it does the best it can, which means
> > > the position is NOT going to be where it SHOULD BE.
> > >
> > > The servo system says, No problem, I'll speed up(increase
> current)
> to
> > > the sub-motors such that we all arrive together. The analog
> component
> > > of the servo system comes in and saves the day. BUT, the servo
> GETS
> > > its position information from a DIGITAL encoder(typically).
> Leading
> > > to the same sort of problem, but on "the other side, so to speak"
> of
> > > the problem.
> > >
> > > So how is all this resolved?
> > > By accepting that we're not always gonna be where we think we
> are(#1
> > > above) and; we may not BE ABLE to do anything about it(#4 above).
> > > So we modify our assumptions re: error(#3).
> > >
> > > The net point of all this is to say that "good enough" is a LONG
> way
> > > from mathematical perfection. And that's OK. If our parts meet our
> > > needs.
> > >
> > > Ballendo
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > > Welcome to CAD_CAM_EDM_DRO@e...,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@a...
> > > Moderator: jmelson@a... [Moderator]
> > > URL to this page: http://www.egroups.com/group/CAD_CAM_EDM_DRO
> > > FAQ: http://www.ktmarketing.com/faq.html
> > > bill,
> > > List Manager
> > >
>
>
>
> 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
Jon Elson
2000-10-12 23:47:34 UTC
Re: step pulse timing resolution
Matt Shaver
2000-10-13 05:19:20 UTC
Re: [CAD_CAM_EDM_DRO] Re: step pulse timing resolution
Art Fenerty
2000-10-13 12:07:19 UTC
Re: [CAD_CAM_EDM_DRO] Re: step pulse timing resolution
Jon Elson
2000-10-13 12:21:23 UTC
Re: [CAD_CAM_EDM_DRO] Re: step pulse timing resolution
Jon Elson
2000-10-13 16:24:07 UTC
Re: [CAD_CAM_EDM_DRO] Re: step pulse timing resolution
ballendo@y...
2000-10-13 20:27:20 UTC
Re: Re: step pulse timing resolution
ballendo@y...
2000-10-13 20:53:54 UTC
Re: Re: step pulse timing resolution
Jon Elson
2000-10-13 23:34:21 UTC
Re: [CAD_CAM_EDM_DRO] Re: Re: step pulse timing resolution
ballendo@y...
2000-10-14 00:13:36 UTC
Re: Re: Re: step pulse timing resolution
Anne Ogborn
2000-10-14 00:41:36 UTC
Re: [CAD_CAM_EDM_DRO] Re: Re: step pulse timing resolution
Art Fenerty
2000-10-14 05:12:10 UTC
Re: [CAD_CAM_EDM_DRO] Re: Re: step pulse timing resolution
Terry Ackland
2000-10-14 06:11:58 UTC
Re: step pulse timing resolution
Art Fenerty
2000-10-14 10:51:37 UTC
Re: [CAD_CAM_EDM_DRO] Re: step pulse timing resolution
ballendo@y...
2000-10-14 11:54:21 UTC
Re: step pulse timing resolution
Alan Marconett KM6VV
2000-10-14 12:22:12 UTC
Re: [CAD_CAM_EDM_DRO] Re: step pulse timing resolution