Setting Servo Max Acceleration

andypugh wrote:
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.

These both look interesting but does it limit it over the entire velocity command or can it be tailored to just the initial acceleration? And what sort of values would I be looking at?

if you bound the maxerror, that will limit the correction but not the
main velocity command (which is not an error but rather a feed
forward term determined by FF1)

You could do a rough check of the analog output delay by
looping back an analog output to one of the analog inputs on the field I/O

Hi Michael
If you really want to know the physical possibilities of your hw this is not to difficult.
Use two (new) in dependant switches and position them in the middle of your axes in safe distance to both ends. Write a bit of hal that just inverts he direction of your axle movement. In a way that the axis moves between those two positions. But do not forget the needed breaking distance. Start slow and test. Than augment your analog value till you reach fasted oscillation. That's the max of your system

AND HAVE YOUR HAND OVER E-STOP. ALWAYS!!!

Here is a halscope plot of a 7I77 analog output driving a isolated input
(10V analog out driving input with ~5V threshold):



Note that about 1/2 of the total roughly 666 usec delay
is the 1 servo period pipeline delay (333 usec in this case)
due to the analog write being done at the end of one servo
thread invocation and the GPIO read being done at the
beginning of the next servo thread invocation.

This shows that the delay from LinuxCNC write to
analog output is in the region of 333 usec.

The one servo-thread period pipeline delay
is compensated in the PID via the
"pid.N.error-previous-target" bit being set true.

Before I ditch using these servos in analog mode altogether I wanted to check these ping times are accurate. The very first ping was .310ms and then there are a couple intermittent ones that approach .200ms but for the most part are around .150ms. Any thoughts on these times or ways to improve them if we can?

The first ping will tend to be longer because the ARP cache data will have expired
and a ARP transaction will be needed before the first ICMP echo request (ping) can proceed.
(the driver disables ARP while running)

As long as the servo thread can run without violating real time constraints the actual timing
is not terribly important, as sampling events (such as reading the encoders or stepgens
position) that affect motion can be re-timed by the DPLL

I did try and play with the DPLL and encoder timing in a few different ways and only managed to make things worse. This included the encoder sample frequency filter between true and false, none of which shortened the delay time.
Short of a "real oscilloscope" reading on the drives analog input and encoder output, the manufacturer won't acknowledge that the drive response is the issue. I don't have an oscilloscope.

The DPLL does not shorten the delay time, it just reduces the uncertainly in the sampling time.

Note that my plot shows ~666 usec delay from commanded analog out to detected read data
and as I explained, because of the:

1. Read (encoders)
2. Process data
3 Write (Analog)
4. Wait until next servo thread invocation (step 1)

ordering of operations, about 1/2 of this 666 usec delay is inherent in LinuxCNCs
read. process, write operational sequence. So our hardware /LinuxCNC/Host Ethernet
overhead is only responsible for at most a few 100 usec of delay. The rest is in the drive.

Oh I agree with you and have no doubts that Linuxcnc is solid. Thank you for all the help.

Just getting the drive manufacturer to accept the halscope as fact was surprisingly impossible. I will be running them in position mode until I can afford better servos/drives.