On Wed, 27 Oct 2021, Ted wrote:
Date: Wed, 27 Oct 2021 14:35:30 -0400
From: Ted <[email protected]>
Reply-To: "Enhanced Machine Controller (EMC)"
<[email protected]>
To: [email protected]
Subject: [Emc-users] Fwd: Requesting a short history review,
if you'd be so kind.
Greets - although I haven't read every post of late, I've been an LCNC
follower since we had BDI's of EMC; LCNC has been my platform of choice for
many projects.
Like many, I started with software stepgens driving open loop steppers, and
although my shelves are full of them, I typically reach for a Mesa board and
position-capable servos these days. I have a particular love for Yaskawa and
Allen Bradley drives, and Yaskawa or Fanuc motors. Typically I end up mixing
brands from ebay finds when we hit the 3Nm mark (or 500w, whichever comes
first), so for my own gear, it's never a perfect numerical match, but with
appropriate care it functions fine.
I recently decided to redo my lathe (a Tsugami NCM, 6" chuck, 2" bore, 12
station turret, 6 station live) which I had a rather old (perhaps 2.3) LCNC
on, more to work on a custom glade gui, as well as try and stay more up to
date, particularly with the RT kernel changes. (Yes, it was that old).
The prior command path was LCNC Axis gui -> motmod -> Mesa Stepgen position
mode, quadrature out -> AB Ultra 100 drive in position follower mode -> AC
servomotor with encoder -> drive encoder output electronically geared 1:1 ->
Mesa Encoder input, scaled in inches -> LCNC axis feedback. Effectively that
was a closed loop stepper system, wherein the feedback came from the encoder
(motor) shaft - and this all worked well. It sounded like a servo (velocities
didn't sound like a stepper), it acted like a servo and its following was
really close both in time and position. Enough for the things I was cutting.
(ok, it held +/- 5 tenths in 12L steel)
In having read some past posts, it became clear that the old config files I
had were not going to be easily translatable, so I gave Stepconf a try
(something I haven't used in years). Although it generated "working" configs,
I was really puzzled by the inclusion of PIDs and their connection in the
command chain, despite the fact I was still using the Mesa stepgens.
I figured it must have been an update I missed, perhaps a higher-performance
path with the new motion planner (recalling I did skip a lot of the posts
during the early PathPilot discussions), so I just went with it.
I was completely unable to get either axis to respond consistently. Sometimes
the drive would fault because of improper quadrature state (namely changing
pulse states while disabled), or it would move 0.5 inch one way, then 1.0
inch the other way, despite scaling matching the real world. Sometimes on an
0.1 move it wouldn't move at all, and would wait for my FERROR to get almost
limited out then it would snap the full distance.
I'm not new to PIDs; in an earlier time between steppers and position servos,
I used to enjoy the task of tuning both torque and velocity loops.
(preferring velocity, though). However I have not until now observed both pid
error and command increase in the same direction before, wherein the PID just
seemed to be oblivious.
I chalked it up to the possibility that my servos and drives, although
mismatched but working prior, may have reached their useful life. Other
potential electro-mechanical variables such as connectors could easily be the
culprit, so I decided for another upgrade - a pair of brand new Bergerda
1500w servos.
Those arrived a week back; I'm very happy with them. After mounting and
checking appropriate defaults, I wrote a quick hal config so I could test the
base pulses-per-inch for drive against the newly-installed glass scales I
decided to add to the mix. With this combination, I expected that there
really weren't any assumptions - the glass scales have a known resolution,
wherein the drive->motor->screw although numerically believed to be known,
may have been a little off due to age or manufacturing tolerances. however
things like rotor pole counts, internal electronic gearing and actual screw
pitch were no longer going to be of issue.
Without too much trouble I found base scale, velocity and accel from the Mesa
stepgen (51010 scale, 9.0 vel, 7.0 accel) - which gave me more than
acceptable rapids, and the 5um glass scale has an encoder scale value of
5101.0. Mathematically, yes, it should have been 5080 or some multiple, but
clearly there is a small amount of error in the system compared to my other
metrology gear. That might get tuned closer to the mathematical real once I
get the ability to cut again.
However, in using a clean new StepConf generated config, with the above
values, the system just seems to want to drift into oblivion on its own.
Similar PID discontinuities as described above. No amount of simplicity in
tuning (even down to PID=1,0,0, FF0=1, FF1=0) would cease the drift. This
isn't microns of drift - it's tens of thousandths per second (1-5mm / sec or
so). This is also the first time I have observed the PID output to remain
locked at 0 if FF0=0. Thus my knowledge of LinuxCNC's PID module config is
clearly outdated.
So here's the big question - is there some major change that would prevent me
from using the Mesa stepgen mode 0 (position) without the PID and use the
glass scale as the feedback source? Is there a change to the motion planner
that doesn't try to get the position to track continuously anymore on its
own, and is that why the PID is in place? The PID just seems to be a clunky
insertion just to force the stepgen to run in velocity mode, so unless I
completely missed the reasoning, I'm not sure why the extra effort.
Much obliged,
Ted.
--
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus
_______________________________________________
Emc-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/emc-users
In general you should use pncconf to setup a basic Mesa stepgen configuraton
Pncconf sets up the stepgens in velocity mode and then uses the stepgen position
feedback to close the loop. If you use encoders to close the loop you just
change the feedback source from the stepgen position to the encoder position.
For velocity mode, FF1 = 1.00 (this does the heavy lifting) For stepgens
the P term is usually set to 1/servo thread period (1000 for a 1 ms servo
thread) The physical meaning of this is that any position errors are corrected
by the next waypoint. The P term cannot be as high with encoder feedback
because of the delay between the step commands and the actual motion.
You cannot really use the stepgens position mode with encoder feedback
and even with local stepgen feedback the velocity mode with externsl PID
feedback tends to work better than the built-in position mode
Peter Wallace
Mesa Electronics
(\__/)
(='.'=) This is Bunny. Copy and paste bunny into your
(")_(") signature to help him gain world domination.
_______________________________________________
Emc-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/emc-users
