On May 27, 2012, at 10:12 AM, Jon Elson wrote: > 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.
Hi Jon, Touche! >> 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. I captured a big spike event (16 encoder counts!), but for the life of me, I cannot figure which came first (the seem to be at the same instant?). I have two screen captures online, 1 so you can see the whole event and the second zoomed in as far as possible at the beginning of the event: <http://3DTOPO.com/spike-event.png> <http://3DTOPO.com/spike-event-zoom.png> > 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. Yes, deadband did help remove most of the jitter I was experiencing, so I started trying to tune the P and D (again!) - but I think I might have made the "spikes" worse. Can I hire you to VNC on the machine while I have you on the phone? I think if I watched you tune one drive I would learn a great deal. Cheers, Jeshua Lacock Founder/Engineer 3DTOPO Incorporated <http://3DTOPO.com> Phone: 208.462.4171 ------------------------------------------------------------------------------ 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
