linear scale and AC servo set up - sanity check

also why do some people use the pid.N.command-deriv pin?
should I connect this one?

That pin you might want to connect the velocity feedback from the encoder (or what ever feedback devise.) If nothing is connected the value is calculated internally from the position feedback. There have been some historical bugs associated with this pin in the PID code. I am not sure if it is currently effective or beneficial to us it (it might be broken and has been in the past).

chienMouille wrote:

ps: also now the axis goes back and forth between the two closest bits of the scale at rest (no command)

That is called dithering, and is a normal servo condition. You may be able to stop it by setting a small deadband amount. Usually 1-2 encoder counts is enough to quiet it. So If your encoder scale is 200 set the deadband for maybe 0.0075.

Im running in step/dir from a 7i95 mesa card, with the servo driver set in position mode.

So it does seem that with command-deriv pin connected I get slightly better result (but maybe I'm imagining it, it's very minimal).

My current understanding is that what makes the PID hard to tune precisely is the difference between two situations: normal move forward and change of direction. The amount of movement required for the same command is pretty different, so would basically require different PID settings to be accurate and therefore trying to come up with a setting which would work for both requires the PID to be inaccurate  (too wide ranging). Therefore the usual logic would be to try and close the gap between these two situations from a mechanical standpoint, aka removing the backlash.

I get this clearly now, and started CADing the machine to figure out how to replace the leadscrews for ball screws.

HOWEVER, for the sake of investigation and curiosity, here is something I wonder:

I get rather good results in open loop mode (without the scale feedback) and with Backlash Compensation on. (Mainly cause in exchange for a small position error I get much more responsiveness from the machine.) This, as I understand, is a blind software implementation: it watches for a change in direction and speeds through an added predefined distance blindly, before executing the actual move command. Of course backlash tending to be inconsistant between different parts of the screw, one would either need a lookup table with the screw modelled in, or contend with some drifting along the axis. 

I might be delirious, but wouldn't pausing the PID on a direction change event for the time to speed forward the backlash distance and then switching back on to finalize the move work? It could have the advantage of keeping a singular situation for the PID to be tuned to. Basically keeping the closed loop for all forward movements, and opening the loop for the time of a forward jump at direction change. See illustration below.

I have tried to keep the backlash comp option on when set in closed loop, but it doesn't seem to do much, which I'm guessing is because of the constant PID calculations on top.

It doesn't theoretically seems difficult to implement in software as the event detection already exists (as shown by the open loop backlash compensation option).

Does it sound totally naive and stupid?

How would you go about writing a patch to test it? As a HAL component, or a LinuxCNC build?


 

[code][code]joint.N.motor-pos-cmd -> pid.M.command
pid.M.output -> pid.N.command
pid.N.output - > stepgen.N.velocity-cmd
stepgen.N.position-fb -> pid.N.feedback
scale.M.position -> pid.M.feedback -> joint.N.motor-pos-fb

[/code][/code]

Ok thanks Andy, I will try and implement this to test it.