Setting Servo Max Acceleration

I didn't have much time to play with this today but when I did I was messing with the higher p values and got good results.

Unfortunately I am now getting an over current alarm on the drive at 400 ipm regardless of settings. It happens as I start the jog motion. It was suggested that this may be because I am lacking a line filter for the incoming power for the drives.

Also any thoughts on the acceleration plotting I did?

The 200 IPS/S (~1/2G) looks quicker than the drives can do with the
existing inertia. (This may also cause overload alarms)

The 20 IPS/S plot looks OK except the the drive has about a 5ms delay
from command to motion, this causes the positive ferror spike (due to lag)
and the subsequent overshoot. If the drive has any filtering of its velocity
command, you should turn this off.

I have not had much success getting that down. There is an acceleration smoothing that I have turned up a bit to reduce the hum the servos were putting out but according to the manufacturer it shouldn't limit the response of the servo. I settled on using 50ips/s as that seemed to respond well but still has that 5 ms delay in responding.

I honestly think these servos are designed only to be run in position mode. Most of the settings and literature revolve around that mode of operation.

Edit:
Went back out and gave some stuff a shot. Turned every setting in the drive, all 5 of them up, down, left, right. No change to that 5ms delay. Should probably look at the other axis and see if they have the same. Any mechanical reason there would be a delay? Its definitly playing catch up to the command and overshooting, probably causing a lot of issues down stream.

Something to bear in mind when looking at the following error during an axis move is that this is an error _along_ the direction of motion, so has a lot less influence on the accuracy of the parts made than error across the direction of motion. That is typically the steady-state error of the orthogonal axes.

I guess 100 % tangential acceleration would cause 0 path deviation, just feedrate
deviation from the velocity ramp. I wonder if a (for 2D) a 45 degree path would suffer the
largest path deviation? (and that might be significantly reduced by the approximately
matched delay in the two axis)

Assuming a commanded 70IPM move and acceleration of 50 ips/s a 5ms delay would mean the axis should move roughly .005" in that time. So assuming a linear move:
X0Y0 starting
G1 F70 X5
G1 F70 X6Y1

The transition from a linear to diagonal move could be off by .005" on the corner. If the rough math is correct and not assuming smoothing. I would love to get that delay down to say maybe half that and definitely like to not have an over current at speed. I havent given up on it. Its getting close and it was nice to see the numbers, especially at cutting speeds, are within very reasonable ranges.

Would the servo drives dead zone setting have any effect on response time? Or its dead zone center value? I currently have both set to dead zero. Would there be benefit to having it off zero or expanding the dead zone?

Michael wrote: Assuming a commanded 70IPM move and acceleration of 50 ips/s a 5ms delay would mean the axis should move roughly .005" in that time. So assuming a linear move:
X0Y0 starting
G1 F70 X5
G1 F70 X6Y1

The transition from a linear to diagonal move could be off by .005" on the corner. If the rough math is correct and not assuming smoothing. I would love to get that delay down to say maybe half that and definitely like to not have an over current at speed. I havent given up on it. Its getting close and it was nice to see the numbers, especially at cutting speeds, are within very reasonable ranges.

I would expect the error to be quite a bit smaller than 0.005 because of the corner radius (min 0.027 at 50 IPS/S and 70 IPM)
That is the commanded Y does not move very much in the first 5 ms.

My thought would be that while the y is not moving for 5ms the x is still traveling at full speed. But in thinking that through the x would slow down a bit because the total velocity would be the sum of both the axis moving together eventually. But one axis would be in motion while the other is starting a coordinated motion. Just some thoughts.

When I get home from work on Sunday I can play with the ideas a bit more. If it's not working out though I will do some tests in position mode. I have searched pretty deep in various forums about these drives and analog control and while I can't confirm all of the settings they tried for the posts I read, I only found instances of people running into similar issues in velocity mode. I did see some verification that the delay issue and issues with running at speed go away in position mode and the following error became very acceptable.

Is there anything I should be checking on the LinuxCNC side of things to see why I have a 5ms delay in movement? The drive has a 100us sample rate so it should be sampling it.

I am using this J3455 motherboard, 10ft of Cat5e to a 7i92 and 7i77.

Thank you for the continued help.