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

Reply via email to