Jeshua Lacock wrote: > > Then, just to see what might happen, I cut the encoder ground connected to > the encoder shield, and it looks like (preliminary speaking) it no longer > faults out. This seems to indicate that the encoder shield was grounded to the wrong place. So, noise coupled to this ground was flowing somewhere and interfering with something. This practice of electromagnetic compatibility and noise reduction is widely viewed as an "art" rather than a "science", because in any complex system the number of possible ground paths becomes mathematically intractable. > The drive is dithering at 0.0003 - 0.0006 with the worst spike now at > 0.0012. Now even when it gets a "spike", it returns to the proper position > (unlike before with the 0.02+ spikes). Interestingly, it seems to act the > identically when I hook the earth ground up to the shield. So I guess I will > use the earth ground for the shield (thanks Gene!). > > Do those numbers seem reasonable? One encoder pulse is 0.0003 on this axis. > Would tuning the PID help with the "spikes"? Currently I only have P set to > 100 and I and D to 0…. > Sure, .0012 is 4 encoder counts. First, there shouldn't be spikes, but gentle bumps of +/- 1 encoder count or maybe two. So, you need to find out what is causing these spikes. is the G320- servo loop responding to noise or encoder counts and jumping too far? Or, is LinuxCNC's PID sensing the normal dithering of the G320 and trying too hard to compensate for it? This could be hard to parse, as you can't view what the G320 is doing, you can only see what the PID is doing. However, you can view pid.0.output, ppmc.0.encoder.0.delta and pid.0.error on the same trace, and wait for one of these spikes. Then, zoom way in so you can see the individual servo cycles (that is the sampling rate of the Halscope data) and you should be able to see if the pid.0.output is RESPONDING to to spike, or the CAUSE of the spike. If there is no significant PID output one cycle before the spike, then it is the G320 that caused it, and checking tuning of the G320 is what you need to do. Probably turn down the gain pot and let the PID handle it.
If the pid.0.output IS jumping a cycle before the spike occurs, then you might want to work with P and D mostly, and possibly also see if a little bit of DEADBAND helps. I usually find that adding a DEADBAND equal to 1.5 x the encoder resolution reduces the annoying dithering. Add too much and you introduce a discontinuity in the servo response, and this can be destabilizing. Jon ------------------------------------------------------------------------------ Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ _______________________________________________ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users