Re: [Emc-users] It looks like my encoder noise reducing filter is toolaggy

[Jim Craig]

Gene,

You say you were using a limit3. Did you have limit3.maxv or limit3.maxa 
set to limit the acceleration? Since the input is a rotational velocity 
you only want to limit rotational acceleration which would be maxv. maxa 
would limit the change in rotational acceleration causing overshoots. I 
propose that you try limit2 with just the maxv parameter to limit the 
acceleration/deceleration of the spindle.

I could be way off though.

Jim

On 9/1/2015 2:12 PM, Gene Heskett wrote:
> Thinking that a direct motor reverse is a bit brutal on both the motor,
> and probably explores the current limit facility built in the Pico pwm
> servo amp, I tried adding a limit3 between the signal from
> motion.spindle-speed and the input to pid.s.command, which was formerly
> a direct net in the .hal file.
>
> Without it, a spindle reversal from 1000 rpms is accomplished in just a
> fraction of a second.
>
> But while it did slow down the turn around of the spindle, I am getting a
> huge overspeed in the new direction until it settles back to the
> commanded rpms.  Not at all usable IMO when the spindle may be turning
> 350 revs driving a 4-40 tap in a G33.1 cycle, and the reversal runs the
> spindle up to 2850 revs.  The head keeps up, but still it looks
> dangerous to me.  It literally goes wide open and jerks the tap out of
> the hole, in perfect synch, beautiful threads.  A larger tap would be
> self cleaning by spinning itself clean.  Now theres a grin causing
> thought. :)
>
> One of the things I did in hacking up this filter, basically a 4 stage
> shift register with all 4 stages feeding a triplet of sum2's, with a
> weighting scale factor of .2500 so basically the final sum2's output is
> the updated average of the last 4 encoder transitions, unforch this
> results in single value being clocked thru the sample_holds by the
> servo-threads repetition cycle when the spindle is turning slow enough
> that we get the same reading several times in between transitions.
>
> Thats pretty slow as the encoder disk has 268 edges per revolution.  So
> at low speeds, the filter degenerates into whatever the last edge
> transition set into the 5i25's registers by clocking that value all the
> way thru the shift registers the S_H's are in about 5 milliseconds.  So
> I made a hold signal out of a comparison between the encoder out and the
> S_H's first stage out. But, and this is what I think is actually biting
> me, the encoder and the S_H's have to have a conv_float_to_s32 and vice
> versa wrapped around them.
>
> So I may as well just go ahead and either junk the whole idea, or figure
> out something that does not need all the float to s32 and vice versa.
>
> Sample_hold is s32 except bit "hold", and the man page doesn't even say
> what state is hold & what state is fall-thru.
>
> comp is float, incompatible with the S_H
>
> Sum2 is float, incompatible with the S_H
>
> So the processing chain is too long and likely in the wrong addf
> sequence.  But it would be a huge help if we had a float version of the
> sample_hold.
>
> Any chance of that ever happening?
>
> I'll test the theory that the filter delay is the culprit by bypassing
> the filter.
>
> Another possibility is that at the instant of polarity reversal going
> into the .command port of pid.s, a reset signal could be slammed into
> the pid.s to cancel any effects of the spindles overshoots in the wrong
> direction, the lack of which is causing a windup in the pid. Halscope
> should be able to show me that I would think.  But how to generate that,
> I haven't a clue, but that almost HAS to be the cause of the
> windup/catchup.
>
> A 2nd question then, pid.s.error-previous-target, bit in, should be what
> for a velocity loop such as a spindle?  Currently set true, by pncconf &
> I haven't touched it.
>
> Anybody else got a better idea?
>
> Thanks all.
>
> Cheers, Gene Heskett


--
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] It looks like my encoder noise reducing filter is toolaggy

[Gene Heskett]

On Tuesday 01 September 2015 16:06:50 Jim Craig wrote:

> Gene,
>
> You say you were using a limit3. Did you have limit3.maxv or
> limit3.maxa set to limit the acceleration? Since the input is a
> rotational velocity you only want to limit rotational acceleration
> which would be maxv. maxa would limit the change in rotational
> acceleration causing overshoots. I propose that you try limit2 with
> just the maxv parameter to limit the acceleration/deceleration of the
> spindle.
>
> I could be way off though.
>
> Jim

I just got some hints from J.K. that could lead to a better solution.

No one has commented on this question though.

> On 9/1/2015 2:12 PM, Gene Heskett wrote:
> > Another possibility is that at the instant of polarity reversal
> > going into the .command port of pid.s, a reset signal could be
> > slammed into the pid.s to cancel any effects of the spindles
> > overshoots in the wrong direction, the lack of which is causing a
> > windup in the pid. Halscope should be able to show me that I would
> > think.  But how to generate that, I haven't a clue, but that almost
> > HAS to be the cause of the windup/catchup.
> >
> > A 2nd question then, pid.s.error-previous-target, bit in, should be
> > what for a velocity loop such as a spindle?  Currently set true, by
> > pncconf & I haven't touched it.

Some insight here might be helpful.

Thanks Jim.

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 

--
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users