On Friday 30 June 2017 17:29:39 Peter C. Wallace wrote:
> On Fri, 30 Jun 2017, Gene Heskett wrote:
> > Date: Fri, 30 Jun 2017 16:59:19 -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 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.
>
> You can have relatively bad latency without any serious
> encoder/stepgen side effects
>
> Latency has nearly 0 effect on the velocity estimation since its done
> on a delta-counts/delta-time basis and delta-time is calculated from
> time stamp differences (or from the free running timestamp counter if
> no counts have occured since the last servo thread invocation)
>
> The time stamp counter is driven by a crystal oscillator
>
>
> The encoder (and stepgen) position will of course have latency related
> noise (especially at high speeds) because of the position sampling
> error caused by the sompling time jitter. If this is an issue, a
> config with the DPLL module can be used to reduce the encoder (and
> stepgen) sampling time jitter to the 100 ns region
>
I believe I have that turned on. Let me scan the hal file. I think this
is it:
# This, ack the hostmot2 man page, should reduce following errors
# and it applies to all stepgens enabled
setp hm2_[HOSTMOT2](BOARD).0.stepgen.timer-number 1
Or is that something else? Doesn't sound like its encoder related
though.
Encoder sampling is: (from ini file)
ENCODER_SAMPLE = 500000
And is used in the hal file via:
A non-existent statement, so I am assuming 500 kilohertz is the default
because that is what the halmeter reports. Nevertheless I should add
that to the .hal file in case it ever needs a tweak.
Thanks Peter.
> 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
