Setting Servo Max Acceleration

The delay from LinuxCNCs commanded velocity output to analog out is in the 200 to 400 usec range with that hardware.

There is the potential for 1mS delay if the servo thread is set up to write-then-read.
But none of the config tools do that.
still, it might be worth looking at the thread order of components to be sure.

The analog output vs vel cmd seem to be fine and near instantaneous to me. That just leaves the wiring to the drive and the drive itself as sources of problems. 7i77 to drive wiring is only 2ft. I honestly think this delay is a source of tuning issues. As I get to a tune at higher and higher speeds my low speed tuning seems farther off. I can bring the f error spikes down to be consistent throughout the move at speed but going back to a lower speed introduces a under/overshoot that is worse then at high speed.

This is analog out vs vel cmd:


THis is the same tune with two different speeds, can't seem to find a middle ground.

P300 FF1 1.04 FF2 .0065 at 270 IPM


P300 FF1 1.04 FF2 .0065 at 60 IPM

Michael wrote: As I get to a tune at higher and higher speeds my low speed tuning seems farther off.

This is not uncommon. I created the "lincurve" HAL component specifically for this purpose, so that the PID controller gains could be set up to vary with speed (or with temperature, error, etc)

In my day job I am in charge of tuning a system where P, I and D gains are each derived from a temperature / total error map, and there is a map for each of the 12 gears.

I would have no problem going that route but would like for one of the two issues (delayed response, over current at speed) I have to be solved before I go any further with these motors.

Some other thoughts that come to mind. The issue could be a delay in the drive sending out an encoder count. From what I read a lot of these servo's are not a direct pass through on the encoder. The delayed encoder counts would create a similar response. I don't have to use the drives encoder to Linuxcnc, I could use a glass or magnetic scale on each axis, would have a few extra benefits as well. Just some thoughts, I think by the time I added those in I would be near the cost of more name brand servo products, which is another option.

Screenshots look much better now.

So continuing to beat this dead horse. I was able to get the DMM servo/drive combo to reach full speed in its RS232 internal position mode. It was able to accelerate to speed at .18 seconds time consistently. So taking this information back to Linuxcnc analog settings and taking 10% (45ips/s) off to allow for room to maneuver I was still unable to go over 2/3 speed without an over current fault. In fact I wasn't able to get up to speed at half that (20ips/s) acceleration without over current. Double checking the drives current monitor vs the halscope shows that the delayed response is causing an increased velocity command to get the motor up to acceleration parameters, accelerating faster than it can handle.

So taking all this information back to DMM technical help and they responded that the problem is on the Mesa side and that I need to work with mesa to figure it out. Obviously I don't think that is accurate. They also stated to use an oscilloscope to confirm the delay since there stated response time is 300 usec. Unfortunately I don't have one of those and also never used one but could probably figure it out. Any advice on finding/acquiring an oscilloscope to get the information and send it back to DMM? At this point I would very much like to see exactly what the problem is.

Any way to definitively rule out the computer and FPGA as being a problem, past what we have already done? Kind of fell like I bought a car that should do 60 mph but can only get up to 40. Yeah I can get it to work but its not what I paid for from DMM.

Which DMM amps do you have? I've gotten the impression most of their product is geared towards step/dir input, and analog is kind of an afterthought.

Michael wrote: Double checking the drives current monitor vs the halscope shows that the delayed response is causing an increased velocity command to get the motor up to acceleration parameters, accelerating faster than it can handle.

You might be able to dial the current back by limiting the PID.

There are a number of parameters that could help.

pid.N.maxoutput float in
Output limit. The absolute value of the output will not be permitted to exceed maxoutput, unless maxoutput is zero. When the output is limited, the error integrator will hold instead of integrating, to prevent windup and overshoot.
pid.N.maxerror float in
Limit on the internal error variable used for P, I, and D. Can be used to prevent high Pgain values from generating large outputs under conditions when the error is large (for example, when the command makes a step change). Not normally needed, but can be useful when tuning non-linear systems.
pid.N.maxerrorD float in
Limit on the error derivative. The rate of change of error used by the Dgain term will be limited to this value, unless the value is zero. Can be used to limit the effect of Dgain and prevent large output spikes due to steps on the command and/or feedback. Not normally needed.
pid.N.maxerrorI float in
Limit on error integrator. The error integrator used by the Igain term will be limited to this value, unless it is zero. Can be used to prevent integrator windup and the resulting overshoot during/after sustained errors. Not normally needed.
pid.N.maxcmdD float in
Limit on command derivative. The command derivative used by FF1 will be limited to this value, unless the value is zero. Can be used to prevent FF1 from producing large output spikes if there is a step change on the command. Not normally needed.
pid.N.maxcmdDD float in
Limit on command second derivative. The command second derivative used by FF2 will be limited to this value, unless the value is zero. Can be used to prevent FF2 from producing large output spikes if there is a step change on the command. Not normally needed.
pid.N.maxcmdDDD float in
Limit on command third derivative. The command third derivative used by FF3 will be limited to this value, unless the value is zero. Can be used to prevent FF3 from producing large output spikes if there is a step change on the command. Not normally needed.

Todd Zuercher wrote: Which DMM amps do you have? I've gotten the impression most of their product is geared towards step/dir input, and analog is kind of an afterthought.

My post purchase research indicates the same. I wasn't able to find any successful examples of DMM servos in analog speed mode.

I have the DYN4-T01A2-00 Servo Drive. I am just about to buy a 7i78 and cable. The downside is I will lose index homing until 2.9 is ready and even trying to close the position with step and direction maybe problematic if the encoder is delayed in responding. I can keep it velocity but run 2/3 speed which isnt bad but I am also concerned the continual current spikes won't do well for drive/motor longevity.