On Thu, 01 Nov 2012 14:19:29 -0400, John Kasunich wrote: > On Thu, Nov 1, 2012, at 01:36 PM, Peter C. Wallace wrote: > >> >> Yes ferror is used: >> >> 1. For tuning (badly since 0 ferror is not 0 pid error when in >> motion) >> 2. for servo fault detection (too large a ferror causes a fault) >> > > Strictly speaking, ferror is used within LinuxCNC only for #2. > > For tuning, the human tuner chooses to probe some pin with halscope. > Peter is assuming they choose the ferror pin (and that is a > reasonable > assumption). But it isn't hard-coded that way - they could choose to > probe the PID block's error pin, which would give Peter exactly what > he > wants. > > I still think that for #2, servo fault detection, it makes sense to > compare the measured position with the last position that the PID > loop > was asked to go to. The alternative is to compare the measured > position > with a target position that the PID loop hasn't even seen yet. How > can > you expect the PID loop to follow a command that it hasn't seen? > > Of course, the answer to that is "that's what FF1 is for". By using > FF1, the PID loop is essentially assuming that the machine will keep > moving at the same direction and speed that it was before - so it can > anticipate the next position, even though it hasn't seen it yet. And > as > Peter points out, when properly tuned it can arrange to be at that > position just as the command arrives. Things probably get a bit more > interesting when the machine doesn't keep going at the same direction > and speed it was before... > > I think the right answer might be keep the ferror calculation as is, > and > to tell people to use the PID loop error pin for tuning. But I'm not > going to get excessively bent out of shape if someone changes the > motion > module so that it calculates ferror using the new command rather than > the old one.
OK. Now I think we are getting places. It does make sense to have an ferror, but as Paul (?) pointed a simple comparison of current position to last recorded makes the error proportional to velocity. Now we can redefine ferror too model the dT from the last position. This would give you a model of where it was last time to where it expected to be this time. This should be very close to the PID loop error, but since we are comparing the forward model to the actualized PID, they are not exactly the same but logically compatible. Also, the dT can be the actual measured time-stamp (in nanoseconds) as opposed to the period. This will remove some of the jitter that is induced into the calculations by assuming that we have 0 latency between expected and measured. Hmmm... I do not think I explained what I see clearly, but I hope you get the idea. Basically add to the ferror calculation the forward model of velocity * dT so that you account for the modeled velocity... ------------------------------------------------------------------------------ Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_sfd2d_oct _______________________________________________ Emc-developers mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/emc-developers
