Jeshua Lacock wrote:
> Putting these numbers in immediately made the drive stable - even in closed 
> loop which is now what I am tuning.
>
> I was able to get the P up to 150. I can add some D, but it seems that it 
> only makes the drive more jittery without decreasing the error.
>   
Well, then lower the D until the loop is stable.  At some point, too 
LITTLE D will also
start to make it jittery, there should be a valley where it is good.
> Can you tell me what exactly is the goal? Do I want the P as high was 
> possible while keeping it stable? In other words, why not just leave P at 50 
> or 100 and be done with it?
>
>   
Yes, sure.  Once you have good, stable response where the following 
error is fairly low
in the cruise portion of a move, then apply FF1 to make the error nearly 
zero there,
then add tiny amounts of FF2 to reduce the error in the accel/decel 
ramps.  You should
be able to get the error quite small, although with your encoder 
resolution (I'm
guessing from some numbers you gave before that it is about 2000 
counts/inch)
you may not be able to get below .002" or so under all conditions.  That's
probably OK for a router, and already less than the overall accuracy and 
backlash
of the mechanical part.
>> And, it may be that you are having feedback from the G320 drive's PWM 
>> outputs to
>> the encoder cables.  This may be what is causing the "increasingly 
>> jittery" effect.
>> Do you have shielded encoder cables?
>>     
>
> Yes. Do the shields need to be grounded to be useful?
>
>   
Of course.  You should ground the shield at the control end only, so 
either the
USC or the Gecko interface.
>> Are you using US Digital encoders that
>> are known to be noise sensitive?  
>>     
>
> Not on this first axis I am trying to tune. It is a Renco. My other two 
> axises are US Digital, but those will be replaced by CUI AMT102 encoders when 
> I get around to installing the new much more powerful motors for the other 2 
> axises.
>
>   
Hmmm, the AMT encoders have a lag in responding to acceleration, but it 
isn't
as bad as I originally thought.  It seems to help to use less than the 
maximum
resolution the encoder can provide.
> I just went ahead and ordered some differential encoder/decoders just to be 
> safe. Due to the size of the machine they are pretty long cables, I would 
> guess around 15 feet.
>   
OK, that's a good plan.
> Also, I routed my motor power lines as separately as I could. My encoders 
> exit the machine on the left side and the power on the right.
>   
That should also help, although shielded encoder cables can be routed 
next to motor cables
in most cases.  At least with my drives, that is fine, but they have the 
filters on the output.
>
> What is the goal with I once P and D are good?
>   
Well, that's the problem.  I works great in a steady-state system, but 
CNC never is
steady-state for long.  It looks back in time at the average error over 
some period
and applies a correction.  But, as soon as the axis reverses, the 
correction is
now in the wrong direction!  There are a bunch of other places where I 
also fails,
such as the change from accel to cruise to decel, or when the cutter is 
cutting vs.
out of the cut.  So, I would not work very hard with tuning I, and use it
sparingly.  If you want, you can try setting I to 10% of P and see how 
it works.
But, if the other params (P, D, FF1 and FF2) have reduced error to a good
minimum, then the I term really has no error to work on, and is benign.
> Interesting, I can't seem to get D anywhere near that high. With P at 150 or 
> 200, it gets real jittery with a D of over 0.5.
>   
Well, this all depends on INPUT_SCALE, motor response and inertia, and 
all sorts
of other things, both software and mechanical.  Don't think that your 
numbers should match
mine, as the motor to encoder link is so critical to the whole 
response.  One thing is if
there is any backlash between the motor and the machine part to be 
moved, it really
complicates the tuning.  Whenever the gear, or whatever, taps from one 
side to the
other of the backlash, it creates a big impulse to the system.
> I see. So when I am tuning, I should start out with a modest acceleration 
> factor, then bump it up until I see a spike?
>   
Yes.  If a big spike suddenly appears in a system that was previously 
well-behaved,
that is a strong indication that some limit has just been reached, most 
likely the
current limit if it appears on the accel/decel ramps.  You want to back off
maybe 20% from there to allow cutting forces to be developed.  You don't
want 100% of available torque to be used solely for acceleration.
>
> Yeah, I think the 5:1 gear box will get me somewhere in the same neighborhood 
> as your Bridgeport. 
>
> My motor is definitely not weak though it is a 1125 oz-in Peak 90V/40A.
>   
But, with the Gecko 320 turned all the way up, you only get 562 Oz-In 
since you
can only feed it 20 A.  But, you are less likely to fry such a motor.
> Besides much more torque, I will be getting much better resolution. Just 
> dithering I am currently at 0.002+ inch, and currently when I rapid I am 
> getting an error of around 0.01. I think when I gear it down I could get that 
> closer to 0.001...
>   
Yes, a 5:1 reduction should automatically give a 5:1 improvement in 
resolution.
I hope those gear reducers are zero backlash, though.
> Thanks again! You really got me feeling much better about tuning it went from 
> scary to feeling like I am almost in command now!
>   
Yeah, the FIRST time, it is TOUGH!  Once you see how the various 
parameters interact,
you start to understand what each one does.

Jon

------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Reply via email to