erroneous following error trip

(Didn't see a good topic to place this in)

I'm running a pretty stock 2.5.4 version of LinuxCNC on my
Bridgeport. The only thing I have changed is to add the
camera tab to Axis with camview. I think this install was built from source about
May 11, 2014. The motion system is my
PPMC analog velocity board set. I have lately started
getting following errors during slow motion. I at first
suspected a chip in the ballscrew, but then it started
happening on different axes. I lately have left Halscope
running, hoping to trap what is going on. Well, I finally
got it, and it is really strange!

See pico-systems.com/images/false_error.png for the
Halscope trace.

The selected trace is in white, the X axis following error
(pid.0.error). Trace 4 (purple) is amp-enable, and triggers
the capture on the falling edge. You can see the X
following error is quite small, and actually decreasing. It
is well below the following error threshold in the ini
file. I did get the "following error on axis 0" message on
the Axis screen. This can happen several times during a
machining session, seemingly at random. MIN_FERROR = 0.005
so, it is about 50 times larger than the following error was at the time the trip ocurred!

Has anyone seen this before? I have no idea what is
happening, but clearly the PID component is not sending out
any indication of a large following error, but whoever reads
that and declares a following error thinks that it has!

Thanks for any insight anybody can offer!

Jon

Hello,

Most easy way to test something is to upgrade the linuxcnc version that you are using. Although the result is probably the same, at least you would know that you are using a more recent version of linuxcnc that could bring new functionality to resolve the issue.

Could it also be possible that another error occurs that place the machine in a error state then a following error occurs due to the first error? In this case the following could be momentanius (not incrementing) and not captured by the halscope?

Is it possible theres a problem thats developed with the encoder interface and you are getting transient wrong counts?

This should show up in a plot but maybe single cycle errors are missed somehow. It would be nice if the peak following error was recorded by motion.

Following errors from axis.n.f-error and pid.n.error are not the same. I wonder how they compare when your error occurs, maybe we can see if something goofy is going on there.

PCW wrote:

Is it possible theres a problem thats developed with the encoder interface and you are getting transient wrong counts?

This should show up in a plot but maybe single cycle errors are missed somehow. It would be nice if the peak following error was recorded by motion.

I cdrtainly suspected this as possible, but it would show up in the pid.0.error trace. How would LinuxCNC know to declare a following error without PID seeing it and reporting it on pid.0.error?
Does whoever declares following errors compute it separately from the PID component? I certainly hope not!

I have troubleshot this kind of error before, and it clearly showed up in the pid.x.error plot.

Jon

The calculation that trips the joint following error is all done in "motion" with the difference between commanded and feedback positions.
There's a one servo cycle pipeline difference between the commanded position that PID error and motions error calculation use so they
are not identical (but should be close).

This is arguably a bug that has been papered over with the PID comps pid.N.error-previous-target option

PCW wrote:

The calculation that trips the joint following error is all done in "motion" with the difference between commanded and feedback positions.
There's a one servo cycle pipeline difference between the commanded position that PID error and motions error calculation use so they
are not identical (but should be close).

This is arguably a bug that has been papered over with the PID comps pid.N.error-previous-target option

Yes, I remember the discussion of this. So, pid.n.error should be quite similar to what motion is calculating, especially when moving at a slow and continuous velocity. I will have to see if I can get the motion calculation on the same plot as pid and see if there is a discrepancy.

Thanks,

Jon