Prototrak Plus Retrofit with Mesa 7i77 & 5i25 cards

No, negative numbers for those are not cool and at the time that I tried that I did not know any better, and I was getting frustrated, and was trying anything. That pic is quite old (from way back when Linuxcnc v2.5 was new)

The biggest trick I did to tune those particular torque mode servos was to use two PID loops. The first one just uses P and D, its out put is the torque command that is fed to the drive. It closes the velocity loop and I have it running in a floating point base thread, running as fast as I can read/write to the Mesa 5i25 without errors. It's feed back is the velocity feed back from the Mesa card.
The 2nd PID loop is the position loop and is set up like a "normal" PID for commanding a velocity drive. It runs in the servo thread, and it's output is the velocity command that is sent to the 1st PID loop.
My set up seemed to be unusually poorly behaved, and you may not need to go to such lengths to get acceptable motion.

If you are using torque mode servos, I would suggest starting by trying to run the servo-thread as fast as you can without getting latency errors. Then try tuning the servos using a single PID loop. When using a single PID loop for torque mode, some things don't behave quite like advertised in all of the servo tuning tutorials especially the FF1 and FF2.

Here are two screen shots I just made on the same machine running 1st a single PID loop and 2nd two loops.

Many thanks Todd for your screenshots!! I am thinking you are getting close to the 2017 garden season, and wish you the very best with your planting.

I have tweaked the (heaviest load) "y" axes and attached is the screenshot. I have not compared it to the other posts yet, this is at 60"/min. If I can get a stable trace on the hal scope I may not need to incorporate 2 PID loops, is that correct? The "x" axes did not seem to be as sensitive as the "y" axes during this tuning, I may try swapping servo locations, just to see how much of difference the load makes to tuning. Please any suggestions are warmly welcomed.




many thanks!!

Edit: I tried to "run" the sample code (linuxcnc) have a "" emc/task/taskintf.cc 6171 Error on axes 2, command number 280 "" this line comes up in the "terminal" window. This is in "terminal" after linuxcnc is running, "Z" axes moves up a small amount then "error on axes 2 shows". I think axes 2 needs to be "edited out" because there is no "z" for the near future.
many thanks!!

Many thanks for all the great help!

After reading more about the duel loop tuning from Todd's thread and in the hal manual, do I have the overview correct?

Todd Zuercher wrote: There are two reasons for using the duel PID.

1st for good response a torque mode servo needs to run in a faster loop than an ordinary velocity mode servo. Putting the velocity loop in the floating point base-thread let me run it a little bit faster than I could with just a servo-thread.

2nd using the duel loop made tuning much simpler, for me. With tuning strategies that are like a normal conventional velocity loop system. With it I was able to get good results with better following errors after only a minutes of tuning, on a system I had been struggling with for months before. Without using any complex filtering.

The following is necessary to allow the 2nd loop:

loadrt stepgen step_type=1,1 ctrl_type v,v

loadrt pid [2=<loops>] [debug=1]

loadrt pwmgen output_type=0,1

or are there other suggested reading?

thanks for all the help!

Have you seen this little tutorial about tuning a torque mode servo in Linuxcnc? gnipsel.com/linuxcnc/tuning/torque.html
(that is for using a single PID loop.)

A duel PID loop configuration requires two PID loops per axis. Turns the system into the equivalent of a conventional velocity mode servo.
In a conventional velocity mode you have a position loop in Linuxcnc that sends a velocity command to the servo drive and the drive has it's own velocity loop that controls the torque. The duel loop setup just moves that velocity feedback loop from the drive into Linuxcnc.
Here is the thread that inspired me to give a duel PID loop setup a try.
forum.linuxcnc.org/10-advanced-configura...eduling?limitstart=0
However it is a very advanced topic.

There will not be any stepgens in one of these setups. There will be 2 PID loops loaded per joint (motor).
You can run every thing in a fast servothread (if you have a fast computer). The computer I was using was a little marginal, so I worked around it by using a floating point base thread for the velocity loop and read/write to the Mesa cards.
Here is my 2 loop config.
forum.linuxcnc.org/media/kunena/attachments/3190/2PID.zip

many thanks for the links and thoughts, Andy!!

After reading more about 2nd loop, my thinking is to make shore I have tried all combinations 1st. Attached is a better trace for the heavy axes "y", I think the correct pins are referenced in the scope trace elements, ""listed as: pid.y.error; pid.y.output; encoder.01.velocity; jount-vel-cmd""



Is the thinking is to have as much "of the other 3 trace" as possible under the "joint-vel-cmd" trace. With as small amount of "encoder.01.velocity" as possible, to push past. What am I looking for in the trace? All suggestions are welcomed.

many thanks for all the help!

In your hal scope plot you will want to increase the gain on the pid.N.error so that you can actually see what is going on. You are looking for micron sized errors. So your current gain setting of 2 (inches?) per division is all but useless. So select channel 1 (your pid.y.error) and slide the gain slider up until the error spikes fill the screen.

Your goal is to minimize those errors and get the encoder velocity trace to match the joint-vel-cmd as closely as possible. More FF2 can help some with your error spikes during acceleration/deceleration.

Many Thanks!

I have worked on these for a while, the "encoder.00.velocity" trace is as close as I have seen to tracking the "joint-vel-cmd". Does this look acceptable? jog feed is 60"/min. I can see the slower the feed the less chance for error.





I tried FF2 all the way to 10; P all the way to 9000; I & D to 90. I will try more if this is not close enough or there is more tuning to do.

Many, many thanks!!

No, not there yet. You want the pid.N.error to be as close to 0 as you can get it all the time. You don't want that to follow the velocity command.

In the attached screen shot notice how the following error never is more that about +/- 0.0015 (that or better is what you are after.) More P (if it doesn't make it unstable) more FF2 (until you start to see too much overshoot).

Thank you, Todd!!

You reference, +/- .0015 this is at the bottom of the hal screen in line "= 0.00126"(ddt 0.04830) is this correct?

Thank you

Yes, If you click on the trace number button at the bottom of the screen, then hover the mouse over the trace, it will show you the values for that point on the trace there at the bottom of the screen.