Re: [CAD_CAM_EDM_DRO] Bridgett update

"Kevin P. Martin" wrote:

>
> I ran into the same effect when testing some motors on a G340. I had two
> apparently identical motors with 1000-line encoders recovered from a Calcomp
> plotter. One motor ran great; the other jumped around as described above. With
> no step input, you could hear the whine from the servo dithering interrupted by
> random thunks as the motor jumped to a new spot.
>
> I could not accept the explanation of electrical noise in the encoder outputs:
> The G340 was suddenly getting large positional errors, and to get this from
> encoder noise would require the generation of a stream of alternating rising and
> falling edges *in the correct phase* on *both* encoder lines.

Depending on the mechanism used to filter the encoder signals, it may
not take much in the way of noise pulses to upset the encoder counter.
A scheme I used was to ignore any transition which caused both A and B
signals to change state at the same time. Not all encoder counters use a
filtering scheme like this. Also, if you do refuse such transitions, it is likely
that when the encoder inputs recover from such a state, that one channel
may recover first, thereby causing a transition that appears correct, but is
not actually valid. Another possible cause is noise on the +5 V supply to
the encoder, causing incorrect signals at the output.

> It seemed much more likely that the encoder simply stopped producing pulses on
> its output for a short time; the motor built up speed (due to the
> ever-increasing motor drive generated by the PID network); eventually, the
> encoder came online again, the G340 saw the motor whirring around, and braked it
> to a halt, and backed it up to where it was when the encoder started working
> again.
>
> I had no way of testing this theory, however. To do so would require a way of
> observing the shaft speed on the oscilloscope using some kind of linear encoder.
> I thought of connecting the two motors shaft-to-shaft and frame-to-frame, and
> testing one motor with the other's encoder, but I have more pressing things to
> do...

It would be interesting to try combinations of this setup, to isolate whether
it was a particular Gecko drive, or a particular motor/encoder unit. Applying
some simple filtering (capacitors) to the encoders and the Gecko inputs might
also help determine the source of the problem. A logic
analyzer might be useful for trapping invalid code transitions, or impossible
pulse rates.

Jon