PID tuning: one vs multiple loops, gain scheduling

Note upfront: I think the best method to document all this is to put in on the wiki.

akb1212 wrote:

Thanks for posting this thread DaBit! It is as others have said a very interesting thread.

If possible could you go through each of the parameters you are using? I have a rudimental idea on what each one means, but if I'm to implement this myself I would prefer to have a detailed knowledge on what each of the parameters do.

No, you do not. You need to fully understand how the system works in order to be able to tune it and make it work the way you want it to work. These kind of configurations are not as versatile as a parport stepper config. The best way to do that is start the HAL file from scratch and build it from the ground up for your situation. It seems a lot of work, but that makes you think twice about every decision, forces you to understand what's going on, and saves you a lot of time killing gremlins in the long run. Whenever you get stuck you peek in various sample files like my configuration to see how someone else solved it. There really is no substitute for 'doing' I'm afraid.

But a flying start never hurts, does it?

I'll take the Y-axis:

It's a good thing you share your config files, but to be honest they are growing so big it's hard to keep track on all the involved parts in there. And for ease of access would you mind posting them all as a zip (or tar) file so we can download them and look at them side by side in our favorite editor?

Sure. I will prepare an archive without too much clutter (the config directory is also full with .halscope files etc. )

Just to clarify a few things first, you are using 3 PID loops here? One for the velocity, one for position and one for scale?

Yes.

And you are using the rotary encoder feedback (mounted on the motor shaft) as input to the first two loops, then use the linear scale as input for the last (the scale) loop?

Yes. The rotary encoder on the servo does the actual positioning, split over two loops. The scale only says 'Hey, you think you are at the correct position, but I measured it and you are 0,04mm off. Would you please move 0,04mm slowly?'

And you are scaling the units so your output are scaled to mm (and mm/s and mm/s^2)?

Yes, indeed. The exception is torque output; that one is scaled so that an output of 1.0 means 'maximum continuous torque'.

I'm not sure I'm able to follow you on how you scale the different PID loops. Could you please break down each one of the loops and clarify what each do, where they get their data from, where they feed their outputs to and how each one is scaled?

I notice you have set num_encoders=8. I suppose that is the correct way to tell it the number of encoder inputs to use. But how do I know what encoder inputs are what number? The 7i77 have only 6. I have a 7i85 card to increase the number of encoders. Will it work for me to just increase the number of encoders as long as I have the hardware to support it? I would hope it's that easy.

It is that easy. I am currently running 7i76+7i77 firmware in the 6i25 FPGA board. The 7i77 provides 6 encoders, the 7i76 allows two more.
I do not have an actual 7i76; the breakout board on the second port is custom. I ordered a 7i85S to replace it with some nicely made hardware instead of a bunch of wires and components on a breadboard.

The output of a dmesg command tells you where the encoders are located. I'll leave the exact answer to PCW (or wait until my 7i85S arrives)

I took a look at the build thread you started about this mill. It's very good. Too bad it's in Dutch though..... I have to use Google translate to read it, but it has big problems with Dutch it seems. The words come out in the wrong order for some reason. I guess Dutch have a different way of putting the order of the words in a sentence.

Well, sorry. The Dutch forum is also the best place to get local help, so it hardly makes sense to create a topic on cnczone.com or so.
Luckily for you there are plenty of pictures.

I'm in the middle of attaching the rotary encoders on my motors as we speak. I'm planning to do most of what you are doing here. But for my part I'm still planning on using the original drives with speed input. So therefore I don't need to implement the inner speed PID loop. That means I need to edit out everything involving that loop. This is why I need to be able to understand in detail where each loop takes it's signals from and where they send them.
I do have a 8i20 amplifier that I plan on implementing soon as well. With that I will need to implement the velocity loop again.

From what I understood you had some problems with homing and index mentioned in your thread. The translation was so bad I wasn't able to understand fully what you were saying. But I think it was something like LinuxCNC doesn't understand there are multiple encoders, and don't know what encoder to take index from when homing. I hope there is an easy way to solve this? And I hope it's fairly straight forward to make it use the linear scale index as homing reference? I have homing working as it should now (with linear scales only). But I would hate to have the rotary encoder index come in and messing this up.
Did you find a solution to this?

No, not reliable, and this is something still on the list but not with a very high priority.
I had a situation where all I got was a single following error, and when I 'powered the machine back on' I could restart the homing sequence and all was fine.
But I also had a severe crash. During homing my limit switches are disabled (they work as limit switch until the machine is homed, then I switch over to soft limits), and somehow the resetting caused a fullspeed move toward the mechanical stop. The crash was hard enough to bend a 20mm thick piece of aluminium out of shape.
The second problem is that the index pulses of the 1um scale happen at very inconvenient locations. With the Z axis 80mm down, for example. With 200mm travel that is almost half the range.

All in all I don't like the 'reset counters on index pulse' method LinuxCNC uses although I understand why they do it. Being able to just latch the position when an index pulse occcurs would suit me better. then it would be easy to say 'hey, you think you are at machine coord -100.00, but I measured it and you're 0.02mm off. Can you correct that position for me?'. This could be done at any location when the axis passes that location.

The hostmot2 encoder components seem to offer latch-xxx pins for a function like that, but they are not documented in the manpage (maybe in the source, didn't check that) and in the 5 minutes I played with them I was not able to capture a position. Probably user error. As I said before: index homing is a bit low on the priority list since homing to switches is quite accurate too.

At a technical note here, the hostmot2 firmware can reset on index but that function is not used by
the hotsmot2 driver, the latch-on-index function is used instead. The driver simulates clear on index via an offset

(This is necessary because clearing the hardware counter on index would break velocity estimation)

I actually think the driver should always enable latch on index and do the rest of the index logic
in software (the latched count can be valuable as a encoder sanity check if always available)

I think its also arguable that low level (servo) positions should be separate from machine positions
so that no low level position is ever cleared (right now there are a number of ugly work-arounds for index related steps in position)

On the homing.
I understand you have a problem with index on the linear scales not being at the end of travel. That is one of the downsides of using inexpensive gear not particularly made for your use. Many of them come with an index pulse at the mid travel point only, don't they?

On my mill homing is only possible with index on the linear scales though.... the only hardware switches in there are the hard limit switches. These physically switches off the enable signal going to the servo drives. So it's not possible for me to use these when homing. There is an override switch in the cabinet to bypass these switches in case I trip them. But there is no way to use them as part of homing.
This is why it is a showstopper for me if homing to index doesn't work with dual encoders. Installing extra hardware switches in there will involve a lot of work, and if it's not absolutely needed I would prefer not to. I do have several switch blocks normally used for this lying around. It's just not possible to install them on 2 of the 3 axes. No room to replace the single switch block with a 3 of 4 way switch (which I already have several of).

But I don't understand why it's impossible to exclude the index pulse of the rotary encoder from being used.... In my case I don't even need them. So for me it would be a possibility to not connect them in the first place..... That way it would not be a problem to use all index pulses for each axis as a reference to homing. The only index pulse the controller ever will see is the one from the linear scales, which is the one I want it to use.

Is there a situation where I will ever need the index pulse of the rotary encoders for my system? I can't think of any situation where I need it. Even if I convert one of more of my axes to torque mode I can't think of situations where this index is needed. At least not is needed in a way I can't use the index from the linear scales.

If anyone know a situation I will definitely need the index pulses from the rotary encoders please tell me now. If not I will not connect them.
I don't think it's a good idea to take the index pulse from the linear scales and feed that to the index input of the rotary encoder inputs. Or is it? It could be done as an alternative....

I'm fortunate enough to have high end Heidenhain 20 ua p/p scales with index on each side. That way I'm able to set my machine up to home in the most convenient position no matter how I configure my machine.
I can even increase the resolution on my scales by replacing the standard analogue to digital interpolator unit (also known as EXE boxes) with one with higher interpolation factor. For now I have two EXE boxes with higher interpolation rate lying on the bench waiting to be installed. These are available quite cheap on eBay. I think this will increase the resolution with a factor of 5, giving me a resolution of 0.0002 mm/pulse instead of the present 0.001 mm/pulse.

There is backlash in my system now, and increasing resolution will in a way increase that. I actually found it a lot harder (or in fact impossible) to tune the system with this increased resolution when trying to use a different controller. This was single PID loop only.
But with a dual PID loop system I expect this to be solved. Or I hope the dual loop system is able to use the increased resolution to an advantage instead of it being a problem as it was with single PID loop system.

I agree it's a good idea to get local help like you do on that Dutch forum DaBit:-) I would do the same if I had the opportunity. It's also evident you do get good advice there! The only downside is that us others who would very much like to see what you were talking about aren't able to understand what you are saying. From looking through it there is in fact loads of things you discuss in that long thread I find very interesting! So it's too bad about google translate not being able to understand Dutch sentence building rules then..... as it is now it's more or less completely unreadable, unfortunately. It's translating word for word, but what comes out is more or less completely gibberish.......

BTW, a wiki is obviously the place to put the detailed info on this. If someone can start it I can contribute when I see the need (and feel confident I know enough to contribute).

I will go through each of the constants in detail, and possibly poke in your comments on them to get better understanding when it's something I don't get. I appreciate you are willing to comment and provide insight to us other users in this. It's very valuable!

I agree it's possibly best if I build a complete HAl file and configuration myself from scratch. But the thing is that Other systems are able to make dual PID loop systems as part of the standard package. So I think it's a good idea to make a standard template for it available. After all there are not so many of the LinuxCNC users that have a degree in control technique. And to be honest that is what is needed of you are to make one yourself with no help.
For now it will probably be only people with a more than basic understanding of it that will know enough to understand the benefit of using it. And the skills needed to tune a dual PID loop is probably also higher than most users have.
But the increased capabilities of a system like this is a clear advantage. And it can be an important factor in making LinuxCNC the best choice!

One of the obvious uses for dual PID loop systems is to compensate for backlash, This is a link to a tutorial video made by the manufacturer of the other controller I have explaining the advantages of using dual PID loop to compensate for mechanical backlash: www.galil.com/learn/online-videos/dual-l...compensation-methods.

Unfortunately you have to register as a user to access it (so I didn't include a direct link). That is straight forward, and there is no approval time of delay when registering. But you will have to provide a valid email as normal on sites like this.
But the video is quite informative, and it explains all the thinking behind dual loop and why it works. So it's recommended watching for everybody interested in dual loop systems. He is also giving examples on the possible improvements possible on systems with backlash. And it's quite evident it's possible to get a real benefit if your system have backlash.

I've seen discussions elsewhere (don't remember where) that the benefit of dual loop is lower on a highly stable and tight system. But I guess that isn't an issue for most of us since we can't afford high end machines with little or no wear.....
So to me this way of overcoming mechanical inaccuracies and non ideal solutions due to low budget in an elegant and effective way. And the cost of the involved hardware is decreasing so fast it's no longer a major issue. Decent rotary encoders are quite cheap now, and used industrial grade ones with very good data can be had for next to nothing. Input cards to read them are also very cheap now.

There is a trend towards going for lesser demands on accuracy in the mechanical parts. And then instead compensate for this in electronics and controllers. This is a very good example of this. And it will contribute in to making better and more accurate machines available to users with lower budgets.

Anders

PCW wrote:

At a technical note here, the hostmot2 firmware can reset on index but that function is not used by
the hotsmot2 driver, the latch-on-index function is used instead. The driver simulates clear on index via an offset

Can the position of an index pulse be found using latch-polarity/latch-enable/count-latched/position-latched pins? Or only through a workaround using rawcounts for example?
(I didn't do my homework BTW, other than finding out that these pins are not documented in the manpage)

I think its also arguable that low level (servo) positions should be separate from machine positions
so that no low level position is ever cleared (right now there are a number of ugly work-arounds for index related steps in position)

I fully agree. Everything has to now that a reset occurred, including the PID controllers etc.
LinuxCNC can do this offset thing perfectly well by the way; at homing it sets the motor offset.

It would be even better to take the referencing logic out of the LinuxCNC core and make it a separete HAL component. If it suits you use it, if it doesn't replace with custom component, ClassicLadder program, whatever. It would also make the use of absolute encoders easier. But that's another topic.

akb1212 wrote:

On the homing.
I understand you have a problem with index on the linear scales not being at the end of travel. That is one of the downsides of using inexpensive gear not particularly made for your use. Many of them come with an index pulse at the mid travel point only, don't they?

Mine produce an index pulse every 100mm. The pulse itself is available on the Mesa encoder component BTW, but capturing that pulse in software is close to impossible. It lasts only 1 micrometer.

I am indeed using fairly cheap components. My mill is for hobby only so i have to keep the cost in 'hobby range' otherwise the household CEO makes me sleep on the couch.
So far I am succeeding well in keeping cost low while maintaining accuracy and speed.

On my mill homing is only possible with index on the linear scales though....

LinuxCNC hardly imposes any limits, so it is not impossible. I just didn't spent enough effort to make it work yet. That is a matter of priorities; until now using the index pulses proved to be not trivial and the proximity sensors are fairly accurate so I am better off doing more urgent things first.

The only index pulse the controller ever will see is the one from the linear scales, which is the one I want it to use.

Yes, and that resets the encoder position which causes a deviation between scale and rotary encoder positions and a lot of trouble.
It's not impossible to account for that. The 'rawcounts' pin is not reset, btw. It is just some work.

I don't think it's a good idea to take the index pulse from the linear scales and feed that to the index input of the rotary encoder inputs. Or is it? It could be done as an alternative....

I did that as a quick test, without much luck. Again, I didn't dive deeply into it.

But with a dual PID loop system I expect this to be solved. Or I hope the dual loop system is able to use the increased resolution to an advantage instead of it being a problem as it was with single PID loop system.

Scale feedback + lost motion = trouble.
Get rid of that backlash. It doesn't only cause trouble with the controller, but also with milling itself.

The only downside is that us others who would very much like to see what you were talking about aren't able to understand what you are saying. From looking through it there is in fact loads of things you discuss in that long thread I find very interesting!

It is. I am an electronics engineer, not a mechanical engineer, and I started that thread when I was as green as grass.
That part of engineering is pretty new to me. But since I can read datasheets and understand math, I can figure things out, and that thread answers a lot of questions someone else might have.

So it's too bad about google translate not being able to understand Dutch sentence building rules then..... as it is now it's more or less completely unreadable, unfortunately. It's translating word for word, but what comes out is more or less completely gibberish.......

I can answer specific questions, but a complete translation is not going to happen. My English is not good enough for that anyway

I agree it's possibly best if I build a complete HAl file and configuration myself from scratch. But the thing is that Other systems are able to make dual PID loop systems as part of the standard package.

With LinuxCNC you basically get a box filled with Lego blocks, and you use that to construct your system. That is exactly the very best part of the system.
Having a couple of standard 'building instructions' to build something with those lego blocks is a good thing, but for more complex situations such as machines with a toolchanger, nontrivial kinematics, special servo needs, etc. you really have to study and understand otherwise you will keep on chasing gremlins.

So I think it's a good idea to make a standard template for it available. After all there are not so many of the LinuxCNC users that have a degree in control technique. And to be honest that is what is needed of you are to make one yourself with no help.

It would be possible to create a sample configuration just like all the others you get when you install LinuxCNC.

For now it will probably be only people with a more than basic understanding of it that will know enough to understand the benefit of using it. And the skills needed to tune a dual PID loop is probably also higher than most users have.

I tuned using trial and error, just like you would tune a single PID. Not difficult at all, even easier. But a little 'howto' would help of course.

One of the obvious uses for dual PID loop systems is to compensate for backlash, This is a link to a tutorial video made by the manufacturer of the other controller I have explaining the advantages of using dual PID loop to compensate for mechanical backlash: www.galil.com/learn/online-videos/dual-l...compensation-methods.

I will watch that video later, but the idea of compensating for backlash makes me shudder. If I can choose only one thing that is totally undesirable in a CNC machine it would be lost motion and especially backlash. You can compensate a gazillion of mechanical issues in software, but lost motion is not one of them. Yes, in a stationary situation you can. But not when the teeth of an endmill are chewing through a block of material. It is dangerous when climb milling, and when interpolating a circle there is a finite time needed to do the compensation and during that time the joints are not in sync.

backlash is A Very Bad Thing.

I've seen discussions elsewhere (don't remember where) that the benefit of dual loop is lower on a highly stable and tight system. But I guess that isn't an issue for most of us since we can't afford high end machines with little or no wear.....

Use fat temperature-stabilised C3-class (or better) ballscrews, preloaded nuts, high quality bearing blocks equipped with P4A (or better) bearings, put the machine in a conditioned space, and linear scales do not add much benefits unless they are of a very high resolution.

But one of such a linear drive system would cost more than my entire machine does (still below EUR 3000 and the spindle+VFD took about half of that amount), so I chose lower quality and pre-used parts and more hard work for the electronics. Seems to work out well.

I have seen it, and noticed that it uses Ziegler-Nichols to determine coefficients. I am not a fan of Ziegler-Nichols to setup motor control coefficients; they often turn out to be quite agressive, and then you still have to 'cram in' the feedforwards.

It does work. Tried it once when I was using LinuxCNC (well, halrun actually) as a simple temperature controller for an experiment (using a Microchip TC77 sensor and SSR on the parallel port). Took some fiddling with number of cycles and tune effort though, and I didn't actually check whether the PID coefficients were really good; it did the job and that was all I cared about during that 'had to be finished yesterday' rush job.

If I need a bit of play time I'll try it on my X axis just for fun and see what it does.