On 9 Apr 2012, at 18:05, Jeshua Lacock <jes...@3dtopo.com> wrote:
> > So I had assumed that it was based on the encoder resolution. It possibly is, but indirectly. It may be that the drives move one encoder count per input step, so with high encoder resolution you run out of input (to the drive) step rate. > > In other words, if issuing pulses to the Gecko was not a bottleneck, how fast > can the Geckos count the encoder lines - as fast as needed? Probably. It would be an odd design choice by Gecko otherwise. > > Sounds good. I guess I am still confused. For a open-loop servos with > LinuxCNC closing the loop setup, I guess I would connect the encoders > straight to the pins of the 5i22? Would they still need to be split the > encoder signals and go to both the 5i22 pins and the Geckos? I don't think that you can move the loop into LinuxCNC with those drives. (well, you could, by running a velocity mode stepgen and a HAL PID but I am not sure you would gain much. ) I think that a switch to hardware step generation is all you really need. But see Jon's post about adaptive f-error. ------------------------------------------------------------------------------ Better than sec? Nothing is better than sec when it comes to monitoring Big Data applications. Try Boundary one-second resolution app monitoring today. Free. http://p.sf.net/sfu/Boundary-dev2dev _______________________________________________ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
