Re: [CAD_CAM_EDM_DRO] Re: tach output
Posted by
Jon Elson
on 2001-12-20 22:57:01 UTC
David Micklethwaite wrote:
across whatever backlash continuously, all the time that the geckos are
enabled. This will be not only nerve-wracking, but will wreck the screw
and nut quickly. It may also overheat the gecko or the servo motor.
If the backlash is more than .001", I think you would find the system
unusable. The gecko would accelerate across the backlash in open
loop runaway, as it is, indeed open loop, because the motor is moving, but
no feedback of that is coming back from the encoder (and there's no
separate tach). Then it hist the other side of the nut and bumps the
encoder hard, overshooting the one encoder count it was trying to
adjust. Then it starts accelerating rapidly the other way.
Clearly, not an example of stability.
Jon
> "Jon Elson" <elson@...> wrote:Well, sort of. the problem is the Gecko will sit there and bang back and forth
>
> >
> > Well, I have a strong preference for real servos. The difference with the
> > Gecko drives is that the CPU has no position feedback. It sends step
> > pulses to the Gecko, and hopes it got there.
>
> Is it possible to use a linear encoder of some sort to provide the feedback
> to the Gecko driver in place of a rotary encoder on the servo motor shaft? I
> realise that this would still not provide position feedback to the CPU but
> it might provide some compensation for backlash in the lead screw.
across whatever backlash continuously, all the time that the geckos are
enabled. This will be not only nerve-wracking, but will wreck the screw
and nut quickly. It may also overheat the gecko or the servo motor.
If the backlash is more than .001", I think you would find the system
unusable. The gecko would accelerate across the backlash in open
loop runaway, as it is, indeed open loop, because the motor is moving, but
no feedback of that is coming back from the encoder (and there's no
separate tach). Then it hist the other side of the nut and bumps the
encoder hard, overshooting the one encoder count it was trying to
adjust. Then it starts accelerating rapidly the other way.
Clearly, not an example of stability.
Jon
Discussion Thread
jakefife
2001-12-17 16:40:34 UTC
tach output
Tim
2001-12-17 16:50:24 UTC
RE: [CAD_CAM_EDM_DRO] tach output
ccs@m...
2001-12-17 16:58:40 UTC
Re: [CAD_CAM_EDM_DRO] tach output
Jon Elson
2001-12-17 22:53:13 UTC
Re: [CAD_CAM_EDM_DRO] tach output
jakefife
2001-12-18 17:38:16 UTC
Re: tach output
Jon Elson
2001-12-18 22:58:37 UTC
Re: [CAD_CAM_EDM_DRO] Re: tach output
Ray
2001-12-19 07:16:52 UTC
Re: Re: tach output
jakefife
2001-12-19 19:15:21 UTC
Re: tach output Thanks for the help
David Micklethwaite
2001-12-20 13:14:23 UTC
Re: [CAD_CAM_EDM_DRO] Re: tach output
Tim
2001-12-20 13:35:48 UTC
RE: [CAD_CAM_EDM_DRO] Re: tach output
mariss92705
2001-12-20 13:57:37 UTC
Re: tach output
Jon Elson
2001-12-20 22:57:01 UTC
Re: [CAD_CAM_EDM_DRO] Re: tach output
Jon Elson
2001-12-20 23:11:34 UTC
Re: [CAD_CAM_EDM_DRO] Re: tach output
mariss92705
2001-12-20 23:27:02 UTC
Re: tach output
rainnea
2001-12-21 03:34:31 UTC
Re: tach output
Tim Goldstein
2001-12-21 07:09:02 UTC
Re: [CAD_CAM_EDM_DRO] Re: tach output
Paul
2001-12-21 13:22:34 UTC
Re: [CAD_CAM_EDM_DRO] Re: tach output
rainnea
2001-12-21 17:01:44 UTC
Re: tach output
Jon Elson
2001-12-21 23:24:12 UTC
Re: [CAD_CAM_EDM_DRO] Re: tach output
Jon Elson
2001-12-21 23:32:37 UTC
Re: [CAD_CAM_EDM_DRO] Re: tach output