Chris Radek wrote: > On Fri, Oct 07, 2011 at 08:48:33PM -0700, Bruce Klawiter wrote: > >> The machine did not dither or do the jerking with the old Anilam >> control.Someone said the axis might be drifting then snap back into >> position, I put an indicator on an axis and it holds position and when >> it jerks it moves about .002" out of position then back, hard to tell >> it so fast. >> > > That's really weird, and sounds more sinister than noise on the > encoder signals. > Yeah, actually, I'd like to see one of these spikes zoomed in on the time scale so it is several divisions wide on the screen. I still don't know what it represents. it could be a disturbance on the encoder input, but Bruce says he has run it back and forth for a half hour, and it was within one encoder count of proper position (.0005") It seems VERY unlikely it could do that without errors accumulating. So, that leaves a couple possible mechanisms. I doubt it is communication errors between PC and PPMC encoder board, as these spikes are never more than a few encoder counts. The typical burst of errors is due to the ppmc driver and the PPMC boards getting out of register synch, and the wrong bytes end up in the wrong position bytes, leading to huge errors like 256 or 65536 count jumps. So, I am ruling that out, too.
I think with a blown-up picture of one of these jumps one could tell if this is real movement of the machine. Due to the bangs Bruce reports, they at least are followed by a position jump. But, looking at the compressed ones, I don't see a jump one direction and then a violent recovery. What I THINK I see is a sudden jump, and then a well-controlled recovery with a little overshoot. So, what I think is happening is the servo amps are getting "upset" for some reason and delivering a major acceleration to the amps for a cycle or two. Now, this could be some kind of electrical interference getting into the servo amp inputs. It might be useful to go over the grounding between the PPMC and the servo amps. Or, it could be a communication problem where the PPMC DAC is getting loaded with an incorrect byte and so the output has a one-millisecond jump in it. I think Bruce has an oscilloscope, so it might be instructive to put the scope on the DAC output and see if there are large, short pulses when the jumps are heard. The more I think about this, the more I think this last investigation should be carried out first, assuming my memory of Bruce's available test gear is right. It would at least help to understand where this is coming from. It could also be quite confusing, however, as the bangs would naturally contain a transient when EMC corrects position after the jump. But, the magnitude of the transient might tell if it was an intended correction or a completely wild transient due to data corruption. If this is seen, then turning down P would tell if the magnitude of the spike at the DAC output was intentional or not. If reducing P to half reduces the spike, you know it was the PID response. If there's no change, then it is not what PID ordered. One other way to test things is to shut down the servo amps, and start EMC, and go to machine on. Have the MIN_FERROR limit set pretty high before starting EMC. Use a scope to watch the DAC output. Move the machine manually, and the DAC output should smoothly climb, positive in one direction, negative in the other direction. If you get jumps in the DAC output, then PC <=> PPMC communication has a problem. Bruce, can you try some of these tests and report back? Jon ------------------------------------------------------------------------------ All of the data generated in your IT infrastructure is seriously valuable. Why? It contains a definitive record of application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-d2dcopy2 _______________________________________________ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
