PID tuning FF2 not working

Hi,

Im trying to PID tune my machine but im having issues with the FF2 variable. 

From what i can understand from guides FF2 would be used to remove the spike of ferror that occurs at the beginning and end of a movement. I have also read that very small amounts of FF2 should be applied. For me however, the FF2 term does not change the characteristics at all.

Here is my current baseline with FF2 at 0 and a slow move at 100mm/min:
 
As you can see there is a spike at the beginning and end of movement. The ferror at the top of the spike is 0.0446mm

If i change FF2 to 0.0005 the ferror is slightly higher. That may just be that perticular move, i have seen that the error can variy slightly. Anyway, its not lower. 

Just to make a point i set FF2 to 0.5 with the spike again being unchanged.
 

As a sanity check i also tried to lower the acceleration of the machine by half. Thinking that the machine and servos may be slow to respond. The values i got from that test are the same as above though.

To me it seems that setting FF1 to 1 removes the possibility for me to tune FF2 at all. With this being a Step/dir controlled system FF1 being anything other than 1 causes problems of its own. But it seems to me that the FF2 value gets less and less influence the closer FF1 comes to 1. Could be something? could be nothing.. 

I am sure that i have made a mistake somewhere but i just cant find it. 

Hal and Ini files are attached. 
 

It look to me like the drive itself needs tuning.
(or perhaps some input filtering disabled/minimized)

How do the servos perform with the config set for open loop? (using the stepgen's position feedback for the PID's position feedback.) You can still keep the encoder feedback connected to the joint position feedback, and use it to monitory the f-error. This could confirm that the problem is indeed in the drive's tuning.

@PCW, i hope you are wrong. But i cant honestly say that they are well tuned. I thought they where..

@ Todd

If i do that i get this:
 

Im not entirely sure what it means though. I can see the same amount of ferror as i get at the top of the spike. Does this mean that the servo is "lagging" 0,045mm all the time in relation to expected position?

Yes, sort of. Some lag, is unavoidable. There is always going to be some lag between when the position is commanded, processed, movement made, feadback is read, feadback processed, and following error calculated. At the very least a servo thread cycle or two. So some error proportional to the velocity is unavoidable. The trick is figuring out what is realistic and acceptable. So 0.045 is about 10x what I would expect (assuming I read correctly that your move was at 1.5mm/sec.)

Another thing to consider when you are tuning the closed loop PID loop in Linuxcnc. You should probably look at the PID error rather than f-error. They are not calculated the same and the PID error will lag the f-error by a servo cycle. The result can be frustrating when you think you see following error but the PID loop is not doing anything about it because it is looking at a different error calculation.

I want to rephrase my statement, 0.045mm is about 10x what you could expect from a near perfect response. (Which probably isn't possible either.)

Almost correct, its a 100mm/min move, not that it matters.

If i understand you correct. somewhere in the system there is lag (or the drive-servo tuning is bad and masquerading as lag?).

Not sure if it can be aproached like this but. With that speed and the size of the trailing error the lag (if its mesurable in time) would be about 27ms in this case. (ferror of 0,045mm devided by 1,666mm/sec movement)

I made another move at 200mm/min to check my math and it checks out. at 200mm/min i get double the ferror at 0,088mm.

So somewhere there is a 27ms delay?

While i go over the servo drives settings (again..), is there any potential for delays in linuxcnc or PC that i should look into?

I dont know, jitter? input port filtering etc?

EDIT:
In respons to rephraced statement. 
Surely 0,02mm should be achievable then? 

I would think within 0.02mm should be more than possible. (My router can hold +/-0.01 at 3000mm/min.) Assuming you can clear up the response issue.

in my opinion the ring is either closed to linuxcnc or to the drive. I used dc motors with h 7i40 bridges and 5000 ppr encoder, at F400 I am on 0.01mm ferror, better I was not able to make smooth movement without peaks at the beginning and at the end. Todd's result is very good, but he will have real non-bare bridge drives like me

I have a machine running with step/dir (position mode) input servos, with encoder feedback to Linuxcnc. It gets similar following error accuracy as the machine I have running with the servos in torque mode input. (It is slightly worse but that is because of lower encoder resolution, and has nothing to do with the fact that the drive is closing a position loop between the drive and motor, while Linuxcnc is also closing a position loop between Linuxcnc and the motor.)

Is having the encoder feedback to Linuxcnc necessary with position mode servos? No. But having the encoder feedback to Linuxcnc made fine tuning the position loop in the drives easier on this particular machine that was a difficult one to get a good tune on.