PID in position mode.

Hello,

Maybe it is a silly question, but i dont understand why does my PDI system works with the stepgen set in velocity mode and works totally inestable in position mode.

Another question i have, if i am working with MESA cards, can i link the pid.x.pid-do-calcs to a faster thread than servo-thread? For example to a thread with 50.000 ns. Will it work better??

Thank you and regards.

Hello,

I´ve been trying putting in every functions ( hm2_read, hm2_write, motion_controller and pid-calcs) added to a fast thread and it seems to work similiar, so i will work just with servo-thread.

I´ve been trying to make the PID in postion mode too, it makes a strange thing, i request linuxcnc to move 1 mm, it starts to move, but it just moves a half of milimeter, then it stops. Reading pins with hal meter i see than pid.x.output is giving 0.5 mm it has to move to hm2_5i25.0.stepgen.01.position-cmd and indeed this pin has the 0.5 value too, but the motor doesnt move. Do you know what can be happening?

Thank you and regards.

Sorry Andy,

I have understood now your message, so the nature of the control and the controlled must be different. So if i read position from the encoder i have to command with velocity the stepgen.

Thank you.

First, I dont believe the position mode stepgen can be made to work
very well under external closed loop control.
(certainly never as well as velocity mode).

This is because the stepgen position mode uses lots of clever code
to end up at the right endpoint of each segment. I suspect these will introduce
nonlinearities that will make PID control difficult.

Much better to use the simple, linear velocity command,
where FF1 does almost all the work and just a tiny bit of P is needed
to correct for time base differences, direction change pauses etc.

That said, you can probably do better by adding some integral term to a position loop.
With only P, (and P will need to be small or you will wildly overshoot your target),
you will alway have a fixed error thats inversely dependent on your P term.

If you consider a velocity mode loop, integration is built-in with just a P term.
that is, with _any_ position error, the velocity will be set such that the position
error is reduced over time.

Ok, my pdi command and read are in mm ( position) and the output is in mm/s (velocity).

What i dont know if i have nice coded is the scale for the stepgen, i fix it in 1400. 1400 are the pulses that my motor needs to move one milimeter.

It is well fixed the scale of the stepgen??

So what are the intervals than axis.x.motor-pos-cmd normally works, i mean when i push the botton of jog-moving for 1 mm, really the axis.n.motor-pos-cmd in wich mm intervals does that total movement of one milimeter?? I dont know if this is important, but when i make the operation P = (Commanded - Measured) * Pgain , i should know more or less with what error i am working for seting a good value of Pgain, shouldn´t I??

Thank you.

That looks like the correct scale. I would set a small P gain and tune FF1 first (it should be very close to one). Too much FF1 will make the position lead the command, and too little will make the position lag the command.

Yes, for a perfect velocity mode control you can preset the P gain to what is required to fix the error in one servo period (P=1000 at a 1 KHz servo thread). Unfortunately this will likely be unstable for a couple of reasons, one being the delay caused by zero order hold (the result of the last cycles PID error being applied for the entire next cycle). Practical gains will also be lower because servo thread jitter will introduce large noise in the velocity command.

Remember however that the hardware velocity generator is almost perfect so most of the control can be done via FF1, with only enough P term to correct for the (very small)
contributions of time base errors and direction change pauses at reversals.

I have set Pgain in 8 and FF1 in 0.8.

It works very very fine, i will continue tomorrow but now i´m in the correct way.

Thank you very much.