[Emc-users] It looks like my encoder noise reducing filter is too laggy

[Gene Heskett]

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 

--
___
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 too laggy

[Jan de Kruyf]

Gene your filter theory might well be right. Because you add a measurable
delay in the loop.

The other thing I found is that the load inertia of a spindle is often
badly matched to the motor inertia. This causes a real head ache setting up
the pid.

Feed forward of the signal might help  in both cases, since then the
feedback amplification needed is much less.

Cant help you with all the variables you refer to.

cheers,

j.


On Tue, Sep 1, 2015 at 9: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
> --
> "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
>
--
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] Supported Servo Motors

[andy pugh]

On 1 September 2015 at 17:24, Jon Elson  wrote:

> As for Yaskawa, I kind of doped out their scheme for the
> SGMP series of Servo-Pak motors from some years ago.
> They had 3 differential outputs, A, B and C.  A and B were
> classic quadrature, C looked the same, but the phase between
> C and the other tracks changed depending on what quadrant
> you were in, or something like that.

That might be useful, I just accidentally bought a couple of Yaskawa motors.
I say "accidentally" as I think I got confused about where I was in eBay.
At £36 each for 1.8kW I am not so upset if I find I can't use them.


-- 
atp
If you can't fix it, you don't own it.
http://www.ifixit.com/Manifesto

--
___
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 too laggy

[John Kasunich]

On Tue, Sep 1, 2015, at 03:12 PM, Gene Heskett wrote:
> 
> 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?

It's already there, it just isn't called sample-hold.

Mux2 can be used as a sample-and-hold.  Tie "in1" to the output.
"in0" is the input.  When select is 0, "in0" is copied to the output.  When
select goes to 1, the previous output enters thru "in1" and is copied to the
output.  Presto, it holds.

-- 
  John Kasunich
  jmkasun...@fastmail.fm

--
___
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 too laggy

[Gene Heskett]

On Tuesday 01 September 2015 15:32:51 John Kasunich wrote:

> On Tue, Sep 1, 2015, at 03:12 PM, Gene Heskett wrote:
> > 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?
>
> It's already there, it just isn't called sample-hold.
>
> Mux2 can be used as a sample-and-hold.  Tie "in1" to the output.
> "in0" is the input.  When select is 0, "in0" is copied to the output. 
> When select goes to 1, the previous output enters thru "in1" and is
> copied to the output.  Presto, it holds.

Now that might be usable, but how to develop the .sel bit? Piece of cake 
IF the 5i25 had an encoder "edge" output set only when an edge has been 
detected that was reset by the card read.  Maybe I can make it out of a 
comp?

I'll go take it out of the circuit and play a bit by running the new code 
in parallel for S It does sound workable if I can make a .sel bit for 
the mul2's.

Thanks John.

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

Re: [Emc-users] Supported Servo Motors

[Dave Cole]

On 9/1/2015 1:36 PM, andy pugh wrote:
> On 1 September 2015 at 17:24, Jon Elson  wrote:
>
>> As for Yaskawa, I kind of doped out their scheme for the
>> SGMP series of Servo-Pak motors from some years ago.
>> They had 3 differential outputs, A, B and C.  A and B were
>> classic quadrature, C looked the same, but the phase between
>> C and the other tracks changed depending on what quadrant
>> you were in, or something like that.
> That might be useful, I just accidentally bought a couple of Yaskawa motors.
> I say "accidentally" as I think I got confused about where I was in eBay.
> At £36 each for 1.8kW I am not so upset if I find I can't use them.
>

Yaskawa is pretty close lipped when it comes to revealing technical 
details.   They are not my favorite company to deal with.

One problem I have had with Yaskawa drives and motors is that if you 
want buy some cable for an older motor/drive combo they really put the 
screws to you.

On a recent job, it was cheaper to buy new Teco servo drives, motors, 
and cables than it was to just buy just replacement cables from 
Yaskawa. Their prices were crazy high.
Apparently some of the older Yaskawa drives used special connectors that 
are not readily available now.

And that was for year 20002001 vintage Yaskawa servos.

Dave



---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus


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

Re: [Emc-users] Supported Servo Motors

[Jon Elson]

On 09/01/2015 12:36 PM, andy pugh wrote:
> On 1 September 2015 at 17:24, Jon Elson  wrote:
>
>> As for Yaskawa, I kind of doped out their scheme for the
>> SGMP series of Servo-Pak motors from some years ago.
>> They had 3 differential outputs, A, B and C.  A and B were
>> classic quadrature, C looked the same, but the phase between
>> C and the other tracks changed depending on what quadrant
>> you were in, or something like that.
> That might be useful, I just accidentally bought a couple of Yaskawa motors.
> I say "accidentally" as I think I got confused about where I was in eBay.
> At £36 each for 1.8kW I am not so upset if I find I can't use them.
>
>
You could always change the encoders, if it came to that.

Jon

--
Monitor Your Dynamic Infrastructure at Any Scale With Datadog!
Get real-time metrics from all of your servers, apps and tools
in one place.
SourceForge users - Click here to start your Free Trial of Datadog now!
http://pubads.g.doubleclick.net/gampad/clk?id=241902991=/4140
___
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 too laggy

[Gene Heskett]

On Tuesday 01 September 2015 16:39:49 J. wrote:

> 5 msec is not bad. In the olden days we ran on a 20msec position loop.
>
> So it will be inertia mismatch. I also battled my but off last year
> with a Deckel.
>
> My solution for encoder noise is an RS485 connection and if it is
> still bad a computer screen cable ferrite (or similar) around all 8
> cores of the encoder cable simultaneously.
>
> Cheers
>
> J.

Its not cable picked up noise.  Its a combination of not exactly a 90 
degree phase angle in the encoder disk and interruper mounting, and 
throw in a thou or 3 of ecentricity in mounting the disk on the spindle, 
so there is a once per rpm wibble in the detected speed, and the 
backlash reduction in the mill that carved the disk,  The combination 
can result in instantainius jumps in the output of the encoder of as 
much as 10% of the actual rpms.  Really tight ball screws in the carving 
machine will reduce it, as will some time on a piece of 600 grit 
wet-r-dry on a granite plate, wet to smooth away the carving burrs that 
the interrupter see's as a variation in the slot width.  Ditto for some 
time in a vibrating case cleaner us reloaders use to make our ammo at 
least as bright & shiney as brand new remchester stuff.

If there was room enough to make the disk bigger, the carving machines 
errors would fade into the noise, but about 2.9" is as big as I can go 
and still fit it in, and carve 67 slots with a .00315" mill. One longer 
slot for the index or Z from the encoder. Quadrature related errors are 
85% of it, and blending all 4 edges reduces that noise quite a bit. And 
it appears that any positioning error in a G33.1 rigid tap operation, 
from the encode lag as it turns around at the bottom  of the hole, is 
well below what it takes to stress a 4-40 or 3mm.5 tap. A 4 slot lag is 
equ to a 5.37313432836 degree error.  Most taps will ignore that.
>
> Sent from my ASUS MeMO Pad
>
> Gene Heskett  wrote:
> >On Tuesday 01 September 2015 15:35:38 Jan de Kruyf wrote:
> >> Gene your filter theory might well be right. Because you add a
> >> measurable delay in the loop.
> >
> >True, but best case is only 5 milliseconds, thats much faster than
> > any inertial effects.
> >
> >> The other thing I found is that the load inertia of a spindle is
> >> often badly matched to the motor inertia. This causes a real head
> >> ache setting up the pid.
> >
> >Yes, I'd have to assume that the motors armature is a much larger
> > factor in the rotating mass than the spindle itself unless a huge
> > multiple edge fly cutter was mounted.  The geardown, even in high
> > back gear, is at least 3/1.
> >
> >> Feed forward of the signal might help  in both cases, since then
> >> the feedback amplification needed is much less.
> >
> >pncconf set FF0 and FF1 to 1.0, which surprised me too.  In my other
> >tuning I have quite often used 100 as FF0, meaning 100% of the input
> >command is sent to the output as a base. Pgain then is the major
> > error corrector, but here its doing almost all of it.  FF1 is 1.0
> > IIRC. FF0 is normally used herre to put the error so its straddling
> > zero. 1.0 won't do it.
> >
> >> Cant help you with all the variables you refer to.
> >>
> >> cheers,
> >>
> >> j.
> >
> >Thanks Jan.
> >
> >[...]
> >
> >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
>
> --
> ___
> Emc-users mailing list
> Emc-users@lists.sourceforge.net
> 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 

--
Monitor Your Dynamic Infrastructure at Any Scale With Datadog!
Get real-time metrics from all of your servers, apps and tools
in one place.
SourceForge users - Click here to start your Free Trial of Datadog now!
http://pubads.g.doubleclick.net/gampad/clk?id=241902991=/4140
___
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 too laggy

[Gene Heskett]

On Tuesday 01 September 2015 17:25:04 andy pugh wrote:

> On 1 September 2015 at 20:12, Gene Heskett  wrote:
> > 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.
>
> This sounds like you have a PID controlled spindle and the PID is
> fighting the Limit3
>
> You need the Limit3 _before_ the PID, not after.

It IS in front of it Andy.

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 

--
Monitor Your Dynamic Infrastructure at Any Scale With Datadog!
Get real-time metrics from all of your servers, apps and tools
in one place.
SourceForge users - Click here to start your Free Trial of Datadog now!
http://pubads.g.doubleclick.net/gampad/clk?id=241902991=/4140
___
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 too laggy

[Gene Heskett]

On Tuesday 01 September 2015 15:32:51 John Kasunich wrote:

> On Tue, Sep 1, 2015, at 03:12 PM, Gene Heskett wrote:
> > 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?
>
> It's already there, it just isn't called sample-hold.
>
> Mux2 can be used as a sample-and-hold.  Tie "in1" to the output.
> "in0" is the input.  When select is 0, "in0" is copied to the output. 
> When select goes to 1, the previous output enters thru "in1" and is
> copied to the output.  Presto, it holds.

Nice, but I had to interchange the input assigmnents because the equals goes 
true.  This works and I can see the individual steps propagating thru the 4 
step chain at low speeds, with about 1/4 the noise in the final sum2's output.  
As the spindle speed rises there is a place where its never true, so it just 
falls thru in the reverse of the addf sequence.

But I am still trying to sort the feedback and the pid for a good stiff 
control.  Some of that is a huge loss in the gearchange module that pncconf 
installed because its a 2 speed head, and some of the speed error is there 
because the actual input to the 5i25's pwmgen.value is only about .45xx at 1000 
rpms delivered.  Setting FF0 down to .87 gets a lot closer to 1k revs when 
you've type s1000 though. so I changed that in the ini file. FF1 seems 
ineffective up to 10 or better, Pgain is 2500, Igain is currently .075 and that 
seemed to soften the m3-m4-m3 turnarounds a wee bit.  But even with Pgain at 
2500, the speed if I grab the spindle, is regulated what I'd call poorly.  The 
toy mill, with no encoder on its spindle is much stiffer, so stiff that I had 
to put an ammeter in to see the motor current, as there is no detectable change 
in its spindle speed as the load goes up until it has cleared the motors fuse!  
15 bucks for the ammeter has probably saved me a hundred bucks worth of fus
 es over the last decade since I put the meter on it.
I can slow this spindle 15% just by wrapping a few fingers around it, without 
burning up my fingers from the friction.

Got a honeydo, later.  Thanks John.

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 
--
Monitor Your Dynamic Infrastructure at Any Scale With Datadog!
Get real-time metrics from all of your servers, apps and tools
in one place.
SourceForge users - Click here to start your Free Trial of Datadog now!
http://pubads.g.doubleclick.net/gampad/clk?id=241902991=/4140
___
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 too laggy

[Karlsson & Wang]

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.


On Tue, 1 Sep 2015 15:12:05 -0400
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
> -- 
> "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

--
___
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 too laggy

[J.]

5 msec is not bad. In the olden days we ran on a 20msec position loop.

So it will be inertia mismatch. I also battled my but off last year with a 
Deckel.

My solution for encoder noise is an RS485 connection and if it is still bad a 
computer screen cable ferrite (or similar) around all 8 cores of the encoder 
cable simultaneously.

Cheers

J.


Sent from my ASUS MeMO Pad

Gene Heskett  wrote:

>On Tuesday 01 September 2015 15:35:38 Jan de Kruyf wrote:
>
>> Gene your filter theory might well be right. Because you add a
>> measurable delay in the loop.
>>
>True, but best case is only 5 milliseconds, thats much faster than any 
>inertial effects.
>
>> The other thing I found is that the load inertia of a spindle is often
>> badly matched to the motor inertia. This causes a real head ache
>> setting up the pid.
>
>Yes, I'd have to assume that the motors armature is a much larger factor 
>in the rotating mass than the spindle itself unless a huge multiple edge 
>fly cutter was mounted.  The geardown, even in high back gear, is at 
>least 3/1.
>
>> Feed forward of the signal might help  in both cases, since then the
>> feedback amplification needed is much less.
>
>pncconf set FF0 and FF1 to 1.0, which surprised me too.  In my other 
>tuning I have quite often used 100 as FF0, meaning 100% of the input 
>command is sent to the output as a base. Pgain then is the major error 
>corrector, but here its doing almost all of it.  FF1 is 1.0 IIRC. FF0 is 
>normally used herre to put the error so its straddling zero. 1.0 won't 
>do it.
>
>> Cant help you with all the variables you refer to.
>>
>> cheers,
>>
>> j.
>>
>Thanks Jan.
>
>[...]
>
>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
--
___
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

[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 too laggy

[Gene Heskett]

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  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 
> >
> > 
> >-- ___
> > Emc-users mailing list
> > Emc-users@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/emc-users
>
> --
> ___
> Emc-users mailing list
> Emc-users@lists.sourceforge.net
> 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)

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

[Gene Heskett]

On Tuesday 01 September 2015 15:35:38 Jan de Kruyf wrote:

> Gene your filter theory might well be right. Because you add a
> measurable delay in the loop.
>
True, but best case is only 5 milliseconds, thats much faster than any 
inertial effects.

> The other thing I found is that the load inertia of a spindle is often
> badly matched to the motor inertia. This causes a real head ache
> setting up the pid.

Yes, I'd have to assume that the motors armature is a much larger factor 
in the rotating mass than the spindle itself unless a huge multiple edge 
fly cutter was mounted.  The geardown, even in high back gear, is at 
least 3/1.

> Feed forward of the signal might help  in both cases, since then the
> feedback amplification needed is much less.

pncconf set FF0 and FF1 to 1.0, which surprised me too.  In my other 
tuning I have quite often used 100 as FF0, meaning 100% of the input 
command is sent to the output as a base. Pgain then is the major error 
corrector, but here its doing almost all of it.  FF1 is 1.0 IIRC. FF0 is 
normally used herre to put the error so its straddling zero. 1.0 won't 
do it.

> Cant help you with all the variables you refer to.
>
> cheers,
>
> j.
>
Thanks Jan.

[...]

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

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

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

[andy pugh]

On 1 September 2015 at 20:12, Gene Heskett  wrote:
> 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.

This sounds like you have a PID controlled spindle and the PID is
fighting the Limit3

You need the Limit3 _before_ the PID, not after.

-- 
atp
If you can't fix it, you don't own it.
http://www.ifixit.com/Manifesto

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

[Emc-users] Supported Servo Motors

[andy pugh]

I know that LinuxCNC can run nicely with conventional incremental
encoders and also with Resolvers using either the Pico convertor or
the Mesa 7i49 card. (In fact my Mill runs with a 7i49)

Looking through eBay for servos to convert my lathe I find lots of
Mitsubishi and Yaskawa servo motors. These seem to use absolute
encoders and a proprietary interface.

Does anyone know which, if any, use a SSI, BISS etc interface which
can be interpreted by the Mesa absolute encoder interfaces?

I think that Fanuc is another option, but I don't know how to
differentiate between the various Fanuc encoding and commutation
schemes.

-- 
atp
If you can't fix it, you don't own it.
http://www.ifixit.com/Manifesto

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

Re: [Emc-users] Supported Servo Motors

[Jon Elson]

On 09/01/2015 07:12 AM, andy pugh wrote:
As for Yaskawa, I kind of doped out their scheme for the 
SGMP series of Servo-Pak motors from some years ago.
They had 3 differential outputs, A, B and C.  A and B were 
classic quadrature, C looked the same, but the phase between 
C and the other tracks changed depending on what quadrant 
you were in, or something like that.  Also, Yaskawa makes 
industry-compatible motor/encoders that can be used with 
other maker's drives.

Jon

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

Re: [Emc-users] Supported Servo Motors

[el cringo]

Hi andy,
i know of 4 different protocols versions for the Mitsubishi absolute 
encoders:
- Mitsu01
- Mit02-4
- Mit02-2
- Mit03-4

Mit02-2 uses an half-duplex UART over RS485 with 2.5Mbps. The others 
have an additional clock line. According to Heidenhain the four variants 
are similar to each other.
Our motors (HA-FF38-UE-S1, 17bit absolute encoder + multi turn) use 
Mit02-2, therefor we implemented a small subset in STMBL (see: 
https://github.com/rene-dev/stmbl/blob/master/src/comps/encm.comp).
see also:
http://www.deltatau.com/manuals/pdfs/ACC-84E.pdf
http://www.heidenhain.de/de_EN/php/documentation-information/brochures/popup/media/media/file/view/file-0668/file.pdf

Siemens motors often use EnDat, which is electrically equal to BiSS 
(clock + bidirectional data over rs485).
see also: 
https://www.heidenhain.de/de_DE/php/dokumentation-und-information/prospekte/popup/media/media/file/view/file-0219/file.pdf

Bosch and Berger-Lahr/Schneider-Electric motors often use Hyperface 
(SIN/COS encoder + slow absolute position + motor data over rs485).
see also: https://www.sick.com/media/pdf/0/90/190/IM0015190.PDF

If you find more infos on other protocols please share.
We are alway looking for new stuff to implement (next PCB version 
supports SSI, Biss, EnDat, Mit02-2, Hyperface, ...).

Nico

> I know that LinuxCNC can run nicely with conventional incremental
> encoders and also with Resolvers using either the Pico convertor or
> the Mesa 7i49 card. (In fact my Mill runs with a 7i49)
>
> Looking through eBay for servos to convert my lathe I find lots of
> Mitsubishi and Yaskawa servo motors. These seem to use absolute
> encoders and a proprietary interface.
>
> Does anyone know which, if any, use a SSI, BISS etc interface which
> can be interpreted by the Mesa absolute encoder interfaces?
>
> I think that Fanuc is another option, but I don't know how to
> differentiate between the various Fanuc encoding and commutation
> schemes.
>


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

Re: [Emc-users] Supported Servo Motors

[Jon Elson]

On 09/01/2015 07:12 AM, andy pugh wrote:
>
> I think that Fanuc is another option, but I don't know how to
> differentiate between the various Fanuc encoding and commutation
> schemes.
>
There are two basic forms of Fanuc red-cap encoders.  The 
original red cap had standard differential quadrature plus 
index, and a proprietary 4-channel commutation code.  I have 
converters that make this look like standard Hall sensors.

The newer scheme is serial.  Some have absolute data, some 
don't. So, for instance, an (alpha)I64 is pure incremental, 
hence the "I", and you can't determine commutation 
immediately when it is powered on.  Once it is moved to the 
index position, the angle code jumps to zero, and my 
converter can produce commutation info.  If you provide 
battery backup to the encoder, then it will be able to give 
commutation immediately when the CNC control is powered on.  
The (alpha)A64 has additional absolute data that allows my 
converter to produce commutation at power on, with no 
battery backup.

Fanuc uses at least 5 different types of connectors on their 
encoders.

I also have a converter for the Panasonic MUMS series motors.

Jon

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