Joint homing offset and following error - HELP

OK thank you everyone! I ran a live session with the Linux installation disk and changed the thread period back to 1000000 (it was saved at 10000). I then tried 700000 and I got a weird A axis burn out, where the axis rotated very quickly and erratically during the homing sequence. So its back at 1000000.

I ran the latency test and didn't see much difference in Max Jitter (ns), around 20100 at each thread rate tested above. (I could not run LCNC and the latency test at the same time due to conflict with the real time processor).

Mesa 5i25 is connected to the 7i77

You will have tot re-tune the PID loops in Linuxcnc if you change the servo thread period. It would not be surprising to have an oscillation induced overload after shortening the thread period if the PID was unchanged.

Even if you are using Mesa stepgens open loop, if you change the thread period you must change the PID settings. For example in the case of open loop stepgens you must change the P term from the default of P=1000 (used for 1000000 servo thread) to P=2000 for a 500000 servo thread.

Tuning a torque mode servo will require substantial amounts of I term in the PID and as much D as you can get without introducing instability. I have also found that it is very helpful to limit the I term using the pin "pid.N.maxerrorI" to prevent windup and overshoot.

So I tried a few things but it seems the burnout is holding back progress. The burnout is when the table rapidly accelerates without command. It always burnout in the same direction regardless of table movement direction, in the X axis case its in the negative direction. When P=100, the x-offset from home is 2 thou. P=200, x-offset from home is 1 thou. P=300 burnout. So I can't get to P values that allow the machine to home to 0,0,0.

I caught a burnout on the Halscope doing a G01 F50 X1 move and you can see the following error oscillates then shoots vertically to 1 (P=300). This is where the burnout starts, and you can see the velocity command drops to 0 when the following error cuts power. Even though power is cut, the table has enough initial acceleration to move almost 2 inches. I put a Halscope of P=100 for reference (there is still a bit of oscillation, not sure if that's normal). See attached.  

Any idea on what could be causing these runaway oscillations?

1. The runaway suggests loss of encoder counts/rotor synchronization (after the oscillation)
oscillation is likely too much P or too low D

2. For torque mode drives a significant amount of the tuning is with FF2

3. P tuning is done only after you have the maximum stable D term


 

After trying many combinations of PID as suggested and what I gathered on the net, it seems I cannot get a stable setup with any meaningful amounts of I or D. So I'm limited to P < 200 and I,D < 10, otherwise the table shoots rapidly and stops with a following error.

What I also noticed is that when I click the quick zero buttons, instead of G54 coordinates resetting to 0,0,0, it goes to the same offset seen at home -0.002, 0.001, 0.0006. Additionally, the G54 zero coordinates (set when clicking the quick zero buttons) change with the P setting (and without homing). Higher P = smaller quick zero offset.

Not sure what kind of connection wiring or software could be causing this? What does the quick zero reference to assign G54 0,0,0 ?