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
Peter Wallace
Mesa Electronics
(\__/)
(='.'=) This is Bunny. Copy and paste bunny into your
(")_(") signature to help him gain world domination.
------------------------------------------------------------------------------
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
