PID tuning: one vs multiple loops, gain scheduling

8kHz is about what I would like to archieve.

What brand/type mainboard are you using? Most H81 mainboards are not very expensive, and neither is the Pentium G3258. I might consider repurposing the Z77/G550.

I am just using 1D gain scheduling on the position controller P only using a lincurve component written by a certain guy named Andy Pugh

Regarding your headache-PID: I wonder if PID control really is the correct answer then. These things have the tendency to just grow this way.
Is that a LinuxCNC system BTW (guess not)?
If so, how did you pass all the map constants? 'setp map1_x0_y0 0.0 setp map1_x0_y1 1.0' etc. already becomes a bit cumbersome for a 5-entry lincurve. So for the correction map of my machine I decided to just create a component with the map constants in a float[] array in source. Some userspace component that reads an Excel/Calc produced CSV file and passes the map data to a RT component would be nicer, but on the other hand editing the table in the source and comp --install works just as well, it is only a little less refined.

Ah, ECU or a testbench for it, probably for some kind of diesel or other kind of CI engine since SI engines are generally more predictable. Am I close? You don't accidentally work for PI Innovo, do you?
I used to be involved in development of a special ECU for larger diesel engines.

This has been a very interesting thread. I think I've learned a couple things.

Any hints for tuning a double loop setup like this.

I was going to start with feeding a square wave to the command input of the velocity loop. (any suggestions how big is a good starting point).

I should probably start another thread.

Tune the velocity loop first, but don't go overboard tuning it to perfection. The position loop will do it's job too, and a slightly less agressive velocity loop but slightly more agressive position loop tends to work better overall, at least in my situation.

Putting a square wave (using siggen) on the velocity command is what I did initially. The disadvantage: when things are not yet tuned perfectly the motion tends to drift towards the end stops which is a PITA.
For the second tuning session I just setted the FF1 from the position controller to 1.0, the rest of the coefficients to 0.0, and turned up the acceleration limits. Then it is easy to introduce a step and enough motion to keep everything in limits.

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.

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?

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?
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?
And you are scaling the units so your output are scaled to mm (and mm/s and mm/s^2)?
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.

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.

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?

Lots of questions here. But you are on to something very useful and powerful here that might be a very strong point for LinuxCNC. So it would be a good idea to document it as thoroughly as possible. It's quite complicated and difficult to follow. So good documentation is key to it's success! I can try to help out here as well if needed. I just need to grasp how it works for myself here first.....

I better end this post now..... it's way to long as it is...

Anders

I decided to copy PCW's setup with a H81 mainboard and Pentium G3258 processor. Works out well: the board displays low latency indeed. With a 200usec servo period I once saw a spike of 5.5us but I was unable to capture a 6us spike.



This indeed allows a higher servo thread. I am currently running at 130usec (7.7kHz). I will feed the system a total torture stream of G1's with deep lookahead before I decide to increase even more.

Does this reduce tracking errors even more? It does, at least for the faster Y-axis servo's (400W; drive uses 12,5kHz carrier). The more sluggish X-axis servo (750W using a 7,5kHz carrier) is less impressed. Still with an unmodified 7i77 BTW, so that's a bit weird.