On Friday 30 June 2017 12:45:55 Peter C. Wallace wrote:
> On Fri, 30 Jun 2017, Gene Heskett wrote:
> > Date: Fri, 30 Jun 2017 12:22:24 -0400
> > From: Gene Heskett <ghesk...@shentel.net>
> > Reply-To: "Enhanced Machine Controller (EMC)"
> > <emc-users@lists.sourceforge.net>
> > To: emc-users@lists.sourceforge.net
> > Subject: Re: [Emc-users] Rough motion with servos
> >
> > On Friday 30 June 2017 09:27:29 Peter C. Wallace wrote:
> >> On Fri, 30 Jun 2017, Les Newell wrote:
> >>> Date: Fri, 30 Jun 2017 12:11:09 +0100
> >>> From: Les Newell <les.new...@fastmail.co.uk>
> >>> Reply-To: "Enhanced Machine Controller (EMC)"
> >>> <emc-users@lists.sourceforge.net>
> >>> To: emc-users@lists.sourceforge.net
> >>> Subject: Re: [Emc-users] Rough motion with servos
> >>>
> >>>> I think it is time to put a scope on the encoder. it sounds like
> >>>> there may be a big duty cycle or phase angle error in that
> >>>> encoder. In other words, at constant speed, the 4 quadrature
> >>>> transitions are not evenly spaced, but at least one of them is
> >>>> out of time.
> >>>
> >>> I can see the phase angle errors in halscope by looking at the
> >>> measured velocity at low speed. There is a regular 4 step cycle. I
> >>> can see the same effect on the other encoders, though it is not as
> >>> pronounced. All encoders have some phase angle error but I have to
> >>> admit this one is worse than I would like. The problem is
> >>> compounded by it being a fairly low resolution encoder. However
> >>> this does not explain the occasional big spikes, especially the
> >>> example where I had a spike of zero velocity for one count. The
> >>> machine was moving at low speed so I could see individual counts
> >>> in Halscope. To read zero velocity that count should have been
> >>> MUCH wider than the others and it was not. There has to be
> >>> something wrong with the the way the velocity is calculated.
> >>>
> >>> Les
> >>
> >> I dont think so, the velocity calculation in the driver has not
> >> changed for many years, and electrical noise can simulate a
> >> reversal which will cause a 0 velocity reading...
> >
> > This has been a very consistent error for years Peter. And I've been
> > sitting here, with halscope running remotely on this machine for the
> > last hour watching it, and just had a thought. This consistency
> > could be explained if there was a difference in the gain as applied
> > to the velocity averager of about 2/1 between the a and b inputs.
> > The timing, and the resultant error I am seeing right now, with the
> > spindle turning around 95 rpms, based on hall effect devices on the
> > 60 tooth bull gear, is telling me the velocity is stepping over a 2
> > division (400mv p-p) range centered on nominally 1.2 volts. The
> > shape of this 4 step pattern can be explained by a gain difference
> > in the a vs b swings. Is this something we've been ignoring for a
> > decade or more? I can bend the opto's a tad on TLM, getting the
> > phasing as perfect as I can, and adjusting the leds for a 50% duty
> > cycle. But the velocity output on TLM, triggered on the index, looks
> > very similar regardless of which of the 3 machines I can look at.
> > The velocity is consistently low while the b input is high, and
> > consistently high while the b input is low.
> >
> > And of course if I crank it up to 1000 rpms, quantization noise is
> > the dominant noise in the a/b pattern, but the general shape of the
> > velocity error only changes because of the rise time of the
> > halscope.
> >
> > It may be Peter, that my encoders are junk, but why are they so
> > consistently junk in the same repeatable direction pattern? Optical
> > or hall effect?
>
> Not sure, but the velocity average is nearly perfect with perfect
> quadrature and the errors are proportional to the quadrature error as
> expected. I have measured this by using a stepgen running in table
> mode fed back into an encoder in table mode and making a 16 step long
> table with a 1 step quadrature error (3/5 steps from edge to edge
> instead of 4/4), in this case you get the expected 1/3 --> 1/5
> velocity steps
>
> This does show that a relatively small quadrature error causes a large
> velocity modulation is the relative time between edge changes so much
>
That appears to also be true, but I don't have a perfect siggen. The
variations in timeing seen on the halscope are of course granular in
nature because the sample read from the card is non-sync to the encoders
input pulses, so moves the apparent edge times seen back and forth by
the thread period, which is nominally 1 millisecond, but this IS an r-pi
3b running locked at 1.2 Ghz, however putting it back in demand mode
makes little if any difference except in the heat. Latency overruns >10x
the 1ms servo-thread are 10 cents a dozen either way. I've the
recommended small heat sinks on it, and a video card fan running on 5
volts blowing directly on the sinks from about 3/8" away.
Now if we just had a kernel that could do decent latency on the armhf,
unfortunately we haven't had one of those critters since 2.6.20 on the
32 bit intel chips. And that predates the armhf's so we may as well
forget about it until we can build our own real time kernel that
actually works. What we have that are called real time by the builder,
are a far cry from it, good latency is 100+ microseconds, and get the
performance they claim by ignoreing 9 out of 10 keyboard or mouse
events. Miss a key up or mouse button release, and its game over
because you just smashed up both the workpiece, and the tool in the tool
post by running it into something, like a chuck jaw turning 1500 revs.
That can get expensive. Fast.
> Peter Wallace
> Mesa Electronics
>
> (\__/)
> (='.'=) This is Bunny. Copy and paste bunny into your
> (")_(") signature to help him gain world domination.
Cheers, Gene Heskett
--
"There are four boxes to be used in defense of liberty:
soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Genes Web page <http://geneslinuxbox.net:6309/gene>
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users
