Optimizing servo tuning.

[TomKerekes]

Hi Judleroy,

Yes that is what I tried to describe in the earlier post. If you add a "watchdog" program loop you can create simulated (virtual) limit switches. We would like to add some functionality to make it simpler and more automatic but for now you can do it by adding the code below to the end of your Init.c program so that instead of the Init.c program exiting it continues to loop and watching the axis position forever. It then sets and clears virtual IO bits as if there really were hardware limit Input bits. Virtual IO bits are just like real IO bits in that they can be set and cleared and read just like real IO bits except they don't physically exist other than in the internal memory of KFLOP.

The code below assumes your system has 200 encoder counts per MM and that you want to limit the range to between 10 and 300mm. You will need to change those parameters for your system.

Also the code is shown for only one axis. You will need to duplicate the code and use other virtual IO bits (50,51, ...) for other axis if needed.

You will then need to configure the axis to watch those limits as shown in the attachment.


#define COUNTS_PER_MM 200.0
for ( ;; )
{
WaitNextTimeSlice();

if (ch0->Position < 10.0 * COUNTS_PER_MM)
SetBit(48);
else
ClearBit(48);

if (ch0->Position > 300.0 * COUNTS_PER_MM)
SetBit(49);
else
ClearBit(49);
}

[judleroy]

I would like to know the max allowable values and practical values for feed forward. What happens when you apply to much or to little? I believe things are becoming much easier to understand but my biggest problem in understanding a lot of the features is not knowing what my limits are. If 0-1 is the limit I can understand it as meaning 0-100 percent. If 10000000 is the max I can still break it down into 0-100 percent. Are there areas that negative numbers would apply? I assume there is a point where adding a higher amount of something above a point does nothing or is then becoming a bad thing.
Those will help me understand a lot I believe. I know it may be just me but knowing my limits helps me set boundaries I can really understand. If there are no limits I can except that to. Thanks.
Judleroy

[judleroy]

Also merry Christmas and if your busy for the holidays I can wait for a reply. You've been such a help and I know we all need a break. Thanks.
Judleroy

[TomKerekes]

Hi Judleroy,

There aren't really any limits on Feedforward. But only positive values would nomally make sense. The values can vary a lot depending on the system. There will be an optimal value that reduces the following error the most.

If the value is too small or zero the position will tend to lag slightly behind causing a negative error and the PID+Filters will have to generate the output for the motion, if just right there will be almost no error and the servo feedback will make almost no correction, if too high the motion will surge ahead causing a positive error and the servo feedback will have to make a reverse correction to stay on the trajectory.

The Feed Forward calculates the output as:

Current Commanded Velocity x FFV = output
and
Current Commanded Acceleration x FFA = output

Where the units of Velocity and Acceleration are in Encoder Counts and seconds, and the output is in output counts.

So for example: if your system needs an output count of 50 to maintain a speed of 100,000 encoder counts/sec then a FFV value of 0.0005 should be used

100000 x 0.0005 = 50

The simplest method is to just start with a tiny value like 1e-6 and verify that it has no significant effect (while plotting following error). Then start doubling the value until you see an effect then go in smaller increments until you find the optimal value.

You should find that the FFA is most useful in reducing errors where acceleration is occuring and FFV is more useful in regions of constant velocity. They will also be somewhat interactive so you might want to optimize one and then the other several times.

It probably isn't worth spending too much time dialing it in to within 1% and getting what appears to be a beautiful looking plot because remember this is all open loop compensation. So if anything changes like friction, cutting forces, payload, feedrate, etc... then somewhat different settings would be needed anyway. But even if the FF is only 80% effective it can still make a significant reduction in typical following errors.

HTH

[judleroy]

That is around the area I was thinking but I keep getting larger values and that worries me at times. For I gain you said probably between .0001 and .001. I found between .01 and .06 worked best and that seems a lot bigger number. Also the same with feed forward. I got around .02 to help the most on velocity and .001-2 for acceleration. This reduced the error from as much as 80 counts on x to a max of less then 15 counts. The same with yandz. Those were. Reduced even more from around 30 max error to around 7-8 max error. My x is moving pretty smooth on rapid moves but on coordinated moves it seems to be a jumpy motion. When the motor is off and I move it by hand it's smooth.
Not sure what to do to fix it. Or if it needs something mechanical and not a setup issue. This is a personal issue seeing as it does cut to size.

Also I know that .032 is a lot of backlash but I don't know why there is so much on the rack and pinion axis. It is spring loaded to the rack. I am wondering if the pinion is to small. Maybe? Thats a question for everyone not just Tom. I'm thinking there's to few teeth engaged maybe. It's a three quarter inch pitch or about 2 1/4 inchs per rotation. Any suggestions would help. Thanks for any help from anyone.
Judleroy

[judleroy]

Also when I tried backlash comp on the y it goes unstable and acts funny the way it moves. I didn't have that problem with the x comp. Any suggestions on that .
Judleroy

[TomKerekes]

Hi Judleroy,

I don't know why backlash would make an axis go unstable, it shouldn't. Maybe if it was marginally stable and the backlash is making a quick jerk it could trigger it into an unstable mode.

We would need to see some plots and your final settings.

I don't think you ever told us the resolution of the axes.

Regarding the "jumpy" coordinated motion we would need more information.

Coordinated motion is all 2nd order motion which means there is no Jerk limit. It also uses separate Acceleration limits which are set in the Trajecory Planner. You can do Step Reponse Screen plots with Jerk set to infinity (1e9) to simulate similar motion. Sometimes Acceleration is set too high but with limited Jerk the max acceleration is never reached so the problem isn't obvious.

Or could it be "facets" in the GCode causing the "jumpyness"? We have methods of smoothing the Gcode.

If you can't demonstrate the problem within KMotion to find the issue then we have a means of triggering data capture from GCode (an MCode) to help locate the problem.

HTH

Regards
TK

[judleroy]

The data capture sounds like a good idea for seeing what's really happening during operation. I will get some plots together and screenshots. It will be a few days before I get back to the shop. Thanks.
Judleroy