On 1/9/25 16:39, Todd Zuercher wrote:
The inner loops output would go to the drive. The feedback for the inner
loops would be the velocity feedback from the encoder, connect that to the
same pin on the inner loop's PID component as you do the position feedback
to the outer loop. The input command of the inner loop gets fed the
velocity command from the outer loop (aka the output.). Tune the inner loop
by feeding it a small square wave command that is long enough to get up to
near the commanded velocity and a command velocity of maybe a 10th of the
machine's max. (Not so much that a good jerk won't hurt it.) Tune a much P
and D as it can handle and be stable, then add I to try to minimize
following error. You want to have the fastest rise to a smooth constant
velocity as you can get without overshoot and no wobble.
Tune the outer loop just like All the online velocity mode tuning tutorials.
Good latency is important for tuning a torque mode servo. Running a faster
thread can also be beneficial, so a good PC is a must.
But is far less of a problem in the direction I've gone, which is to
toss out the PID's, and refit closed loop stepper/servo's, This puts an
encoder on the motor and a decoder in the driver. No feedback from motor
to linuxcnc exists. They simply do what the planner spits out.
3 huge advantages can be had. Starting with much higher motor voltages,
up to 90 volts for the nema17 motors, up to 110 volts for the 23's and
bigger.
1. the error from the decoder in the driver determines the motor
currant, so unless the motor is working hard, it runs on a fraction of
the normal burn your hand currant. This is energy you can see in a
reduced power bill.
2. If in approaching stopped, it overshoots, the driver actually
reverses the motor, using all the current the psu can supply, to put the
motor back to where it belongs. And it does that many times faster than
a 1 kilohertz servo PID ever could.
3. because of this, I feed the stepgens from the planner directly to the
motor,'s step input, no PID involved. Absolutely dead stable.
I am gradually converting my machines to these much faster, and more
accurate motors. I have 6 of them in use in the garage now, and am
amazed at the quiet and smooth performance and total lack of homing loss
I am getting.
I have the alarm outputs of these drivers tied into the e-stop, but in 2
years, it has not happened unless I purposely run a tool into a
stationary chuck jaw to test it. Stopped, no damage to carbide chip or
8" chuck jaw.
I've done that to one of my 3d printers. I feed my OpenSCAD efforts to
the slicer, feed the slicer output to the printer and go get that part
when its done, at 7 to 10x the speed that printer could run OOTB. No
excitement, it Just Works. The last project was 3 wrenches to facilitate
changing the leaky 30 yo faucet on my bathroom vanity's sink. Worked
great. And I'm having a ball plowing new ground.
On Thu, Jan 9, 2025, 4:11 PM Viesturs Lācis <viesturs.la...@gmail.com>
wrote:
ceturtd., 2025. g. 9. janv., plkst. 21:30 — lietotājs Todd Zuercher
(<tzuercher1...@gmail.com>) rakstīja:
Ona normal velocity PID loop, the command input and feedback are in
position units, only the output command is in velocity units. For a
torque
command servo, if using a double nested loops the outer one would be a
regular position/velocity loop, but the inner one would be velocity
command
input to torque command output. A single PID loop can be used with
torque
command servos, but tuning them is a lot harder and they are a bit
unstable
when loads change and at high or low speed. For such a loop tune with
lots
of I term with an i-error limit set so the I term can never saturate the
output command. This allows a fast I reaction without windup induced
overshoot causing instability.
This makes sense. Servodrives are Mesa 8i20, input value to the drive
is current, which means "torque". I kind of have them running with
single PID loop, nothing particular to complain but am not very happy
as either the ferror is more than 0.06 mm or motors become noisy and
are vibrating. This explains why I could not get ferror down to
0.01-0.02 mm...
Nested /cascaded PID loops sound good, I found a forum thread
mentioning that as well, but I have no idea how to start with that. I
would appreciate any advice on how to actually tackle this. I suspect
that I should start with inner loop first. I even found that P, I and
FF1 parameters should be used for inner loop, P and FF1 parameters for
outer loop. It is just that I am not sure what should be used for
inner loop's command when outer loop is not there yet. Connect inner
loop's pid.m.command to joint.n.vel-cmd? And should the
"encoder.nn.velocity" linked to pid.m.feedback?
And keeping in mind that I want some jerk limitation as well, what
could possibly go wrong if I put limit3 component between both pid
loops? It is acceptable that overall ferror will be around 0.05 mm
with max accel of 800m/s^2, I just need to minimize those kicks when
actual acceleration value instantly changes.
Viesturs
Cheers, Gene Heskett, CET.
--
"There are four boxes to be used in defense of liberty:
soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author, 1940)
If we desire respect for the law, we must first make the law respectable.
- Louis D. Brandeis
_______________________________________________
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users
