Geert De Pecker wrote: > Is the problem with software encoding related to the speed of the pulses > coming in? If so, would a low res encoder (homemade) of eg 20 ppr be a > solution? > Yes, but you don't want it to be too coarse. There is some filtering in the motion of the slaved axis, but if the encoder was too coarse, there could be some stair-step like movement in the Z axis. 20 slots in a home-made encoder would give 80 quadrature counts, or 4.5 degrees per count. I would expect that to work fairly well. Without quadrature, it would be 18 degrees per count. I'd have real doubts about the accuracy or "linearity" of a thread with an encoder that coarse. I am using one with 6912 counts/rev, I know that is overkill, but it is what I had. > Does it have to be a quadrature encoder (see in the HAL doc that both A > and B are used) or is there a solution with 2 signals: one index Z and > eg only 'A'? I would assume that when 'B' is not used and > encoder.N.x4-mode is false, it would also work? > The current code and hardware available all expect a quadrature encoder. You could set up a variation on the code to allow a different encoder scheme with only 2 channels, for instance. Without changing the code, I don't think you could get it to count with just one channel, even with the N.x4 mode false. That just divides the counts by 4. > Jon
------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ _______________________________________________ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
