On Sunday, May 27, 2012 03:40:41 PM Jon Elson did opine: > 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 > Jon, while the encoder I built for the lathe spindle was pretty crude, one of the things I did in my research was to make it an given that the opto device chosen had an active, high speed CMOS rail to rail output. While the qradrature may not have been accurate enough to be usable as a velocity detector, the output of all 3 channels is absolutely noise free. I may yet carve me another wheel, from even thinner material which would allow me to use a pcb sized drill for the mill to cut it with.
I think, when any of us is shopping for an encoder, any encoder with a TTL level only, or open collector type output should be removed from our purchase consideration. Even differential outputs, which need twice the wires, should not be immune to this purchasing rule. They are simply too susceptible to stray noise pickup to even be considered when they are in a high impedance state 50% of the time. One old farts opinion. Why buy something you know is going to be ultra critical to deal with? Cheers, Gene -- "There are four boxes to be used in defense of liberty: soap, ballot, jury, and ammo. Please use in that order." -Ed Howdershelt (Author) My web page: <http://coyoteden.dyndns-free.com:85/gene> We all know Linux is great... it does infinite loops in 5 seconds. - Linus Torvalds about the superiority of Linux on the Amterdam Linux Symposium ------------------------------------------------------------------------------ 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
