RE: [CAD_CAM_EDM_DRO] Re: DC motor controller

Not really, this is why we like to have more encoder counts than we do steps
on a servo control.

Think is you tell it to do 10 steps. The servo will count the steps up to 10
and store this.

Then say one step equals 8 count because our encoder CPR is 8 times the step
resolution we need.

So our step count of 10 needs to be 80 encoder steps. The motor will start
to move towards 80 steps, it may overshoot and hit 82 before it reverses and
gets to 80.

So it overshot by two encoder steps, but this is 2/8 of our control input
steps so your have a quarter of a step input error.



On the other hand if your 10 input steps needed 10 encoder steps. Your
overshoot of 2 steps now is quite significant, it's eight times worse. You
could use finer steps in your control software so a couple of input step
errors are smaller and don't matter, but then your speed is limited and
slower based on the maximum pulse output frequency of your PC interface.



The servo will never be instantaneously spot on with its encoder count,
unless it is very slow, it needs to be allowed to overshoot a little. Using
the multiplier in the servo gives you small overshoot compared to your input
steps



There is one omission in my above statement. When the servo takes it's input
step count, this is the error, it will reduce this count as the motor moves
closer to position. All controlled by an up/down counter controlled by the
step inputs, and the encoder as it moves.



I hope that makes sense



Regs Mark



_____

From: CAD_CAM_EDM_DRO@yahoogroups.com
[mailto:CAD_CAM_EDM_DRO@yahoogroups.com] On Behalf Of John Hansford
Sent: 12 November 2006 15:25
To: CAD_CAM_EDM_DRO@yahoogroups.com
Subject: [CAD_CAM_EDM_DRO] Re: DC motor controller



Hi Mark,

I can follow along with that, But doesn't overshoot & undershoot
still equate to missed steps or even added steps? Ruined work?

The encoders I ordered are these...
http://www.surplusc
<http://www.surpluscenter.com/item.asp?UID=2006111209105239&item=10-1834&cat
name=electric>
enter.com/item.asp?UID=2006111209105239&item=10-1834&catname=electric

200 cpr. Is it workable.

I think I understand...It's all in the tuning.

If I used a spindle head at say 1200 rpm one day then a 30000 rpm
router the next, does all this tuning need to be redone.

It can just be slowed down in mach3?

John

--- In CAD_CAM_EDM_ <mailto:CAD_CAM_EDM_DRO%40yahoogroups.com>
DRO@yahoogroups.com, "Mark Vaughan" <mark@...> wrote:

>
> If you go to the Rutex site they show a graph of output position against
> time to a step response input.
>
> In control systems a step response is when you tell the servo to go

x number

> of pulses in zero time. Obviously this is impossible it will take

some time

> to accelerate, and then decelerate to position.
>
> (To those control systems engineers out there, I am going to try and

keep

> this simple and avoid PID, nyquist, poles and zero's etc)
>
> There are several things that can happen to a step response.
>
> In a slow system you see it move to position, and slow down before

it gets

> there taking a long time to move the last little bit to position.
>
> In a fast system, overshoot (go past it a little), and then pull

itself back

> to position. But it may get to position, or it may oscillate above

and below

> for a while.
>
>
>
> The servo drive has a gain figure which controls how quick it gets there
> when there is an error, more error and it must get there quicker,

but too

> fast and it will overshoot, and too much gain causes this

oscillation which

> you don't want.
>
> You normally up the gain until you get a little oscillation, you

then add

> some damping to stop the oscillation.
>
>
>
> Depending on the servo control there are then other adjustments that

work

> slightly differently with each manufacturers servo drive.
>
>
>
> Remember the step response is not a real situation, it's a standard test
> method, software like mach3 would control the acceleration within

the limits

> of the machine, and then the servo's work is much easier.
>
> The thing is to allow the servo to know when there is a slight error

so it

> can correct it within a few encoder pulses, you give it room to

play, but so

> fine you never see it.
>
>
>
> If you watch commercial machines with controls of the 1980's and early
> 1990's fitted with hand wheels perform a fast G0 move to position before
> slowing to cut, you will actually see the index on the hand wheel

stop and

> reverse a bit. As a control systems engineer, the control is rather

sloppy,

> but a normal cut is very much slower so the system is then much more
> precise. Most of these machines typically use 250 cpr encoders, if

you put a

> 2500 CPR encoder on and run mach3, you won't see any over or undershoot.
> It's real impressing to CNC operators that think our DIY stuff might be
> inferior.
>
> This is also why we tend to rough cut, and then finish cut with a slower
> feed which is more accurate as well as having a better surface

finish, the

> older machines suffered from a lot more positional lag during normal
> operation.
>
>
>
> To get a fast machine running well might take several hours to set

up the

> servo drives. I never really know when to stop. I like to see a fast
> response with very very little overshoot, perhaps 1 to 2 counts max.

But I

> also see machines especially some of the old ones with analogue controls
> that are very sloppy and they still work quite well, it depends how

hard you

> push them.
>
>
>
> Hope this gives you a little insight
>
> It will all make sense when you start to play.
>
>
>
> Regs Mark
>
>
>
> _____
>
> From: CAD_CAM_EDM_ <mailto:CAD_CAM_EDM_DRO%40yahoogroups.com>

DRO@yahoogroups.com

> [mailto:CAD_CAM_EDM_ <mailto:CAD_CAM_EDM_DRO%40yahoogroups.com>

DRO@yahoogroups.com] On Behalf Of John Hansford

> Sent: 12 November 2006 11:44
> To: CAD_CAM_EDM_ <mailto:CAD_CAM_EDM_DRO%40yahoogroups.com>

DRO@yahoogroups.com

> Subject: [CAD_CAM_EDM_DRO] Re: DC motor controller
>
>
>
> Thanks Mark,
>
> I'm trying to follow along, but I've never seen a servo setup
> run. I feel like I did 4 years ago when I got my first kit
> from stepperworld with 80 oz motors. The vids I've seen show
> them(servos) zipping around with real authority.
>
> I am greatly appreciative of all this help and advice.
>
> I've got some stuff ordered to get into "Trial & Error" phase
> as soon as possible. I guess a great deal will become clear
> when Hook-up time comes.
>
> I'll refer back to these posts many times.
>
> I usually build a machine 2-3 times before I'm satisfied with it,
> so I'm not counting on getting it right the first time.
> The main reason the machine's 80% MDF.
>
> For anyone interested, I'm going with the treadmill motors &
> cheap encoders from surpluscenter. Gecko G320's.
> Mainly because something similar has worked for Les for years.
> I need to run ANY servo to get an idea of what to expect.
> I can't go wrong having these motors on hand.
> The parts I need(for now) are basic geometric shapes from MDF.
> I won't know what I want to improve til I see something running.
> The Gecko's are akin to currency...If I can't use them somebody
> else can.
>
> I want to do this in a way that the next guy can learn from it too.
>
> We're all very fortunate to have such helpful and informed people
> from all around the world giving their input.
>
> Thanks Mark,
>
> John
>
> --- In CAD_CAM_EDM_ <mailto:CAD_CAM_EDM_DRO%40yahoogroups.com>
> DRO@yahoogroups. <mailto:DRO%40yahoogroups.com> com, "Mark Vaughan"

<mark@> wrote:

> >
> > Les wrote >>. Higher CPR encoders make it easier for the drive to
> > compensate.
> >
> >
> >
> > This is a very good point for diy'ers. Many diy'ers look at the
> output speed
> > of programs like mach3 together with acceptable accuracy/resolution to
> > decide how many count they will select for their encoder. But
> resolution and
> > accuracy are not necessarily the same.
> >
> > Many modern servo controllers have a divider to allow you to set one
> step
> > input pulse to correspond to several encoder output pulses. This
> allows you
> > to use a hi count encoder so the servo drive has very good

accuracy and

> > several counts per step so it can see errors within each step and
> keep those
> > error small to much less than one step resolution. The divider then
> lets you
> > set the step resolution, and maintain speed with your step
> resolution being
> > pretty much your maintained accuracy even with a little over and
> undershoot
> > error. (cogging problems excluded in poor servo motors). Try

selecting a

> > pulse count resolution of at least 4 times your step resolution.
> >
> >
> >
> > Regs Mark
> >
> >
> >
> > _____
> >
> > From: CAD_CAM_EDM_ <mailto:CAD_CAM_EDM_DRO%40yahoogroups.com>
> DRO@yahoogroups. <mailto:DRO%40yahoogroups.com> com
> > [mailto:CAD_CAM_EDM_ <mailto:CAD_CAM_EDM_DRO%40yahoogroups.com>
> DRO@yahoogroups. <mailto:DRO%40yahoogroups.com> com] On Behalf Of Leslie

Newell

> > Sent: 12 November 2006 09:29
> > To: CAD_CAM_EDM_ <mailto:CAD_CAM_EDM_DRO%40yahoogroups.com>
> DRO@yahoogroups. <mailto:DRO%40yahoogroups.com> com
> > Subject: Re: [CAD_CAM_EDM_DRO] Re: DC motor controller
> >
> >
> >
> > Hi John,
> >
> > The servo drive will have to work to reduce the effect of the

cogging.

> > Modern drives are pretty good and can mask most of it. On my mill,

if I

> > watch the pulleys very closely I can just see the motor speed varying
> > slightly at certain feed rates. It appears to have no discernible
> > effect on accuracy or surface finish so I don't worry about it.

Higher

> > CPR encoders make it easier for the drive to compensate.
> >
> > Les
> >
> > John Hansford wrote:
> > > Hi Dave,Ron,
> > >
> > > Pictures...
> > > http://www.flickr <http://www.flickr
> <http://www.flickr <http://www.flickr.com/photos/26361144@N00/>

com/photos/26361144@N00/> com/photos/26361144@N00/>

> > com/photos/26361144@N00/
> > >
> > > I took the CW to mean the nut would probably fly off if it ran
> > > the other way. I opened it ...Nothing flew apart.
> > >
> > > What's the Bad news...How _BAD_ could they be as servos?
> > >
> > > I wouldn't have noticed the very slight cogging if I weren't
> > > trying to find it.
> > >
> > >
> > > John
> > >
> >
> >
> >
> >
> >
> > [Non-text portions of this message have been removed]
> >
>
>
>
>
>
> [Non-text portions of this message have been removed]
>

[Non-text portions of this message have been removed]