On Tuesday 01 September 2015 16:06:30 Karlsson & Wang wrote:

> By limiting the signal I guess you get "wind-up" in the integrator of
> the PID controller. I think there is a maximum acceleration option in
> the *ini which is better suited to limit acceleration.
>
I did check that some time back. It has no effect when the commanded 
speed simply switches from 500 to -500 on the next servo thread, or vice 
versa as I type m3 or m4 on the mdi screen.

Thanks for the reminder.

> On Tue, 1 Sep 2015 15:12:05 -0400
>
> Gene Heskett <[email protected]> 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
> > --
> > "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>
> >
> > --------------------------------------------------------------------
> >---------- _______________________________________________
> > Emc-users mailing list
> > [email protected]
> > https://lists.sourceforge.net/lists/listinfo/emc-users
>
> ----------------------------------------------------------------------
>-------- _______________________________________________
> Emc-users mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/emc-users


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>

------------------------------------------------------------------------------
_______________________________________________
Emc-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/emc-users

Reply via email to