I have been told that LinuxCNC could read encoders on steppers and actually stop the program with a position following error(ferror) if the motor lost position due to a stall, drive fault, or loss of power. Although it would not correct itself, it would stop the machine if the motor got out of position.
The ferror setting in the .ini of the LinuxCNC controls this value and mine is currently set at .002 inch. This means that if the position error ever exceeds this value at anytime during rapid moves, heavy cuts, dull tool, etc., the program would stop and allow an opportunity to correct the problem. It also provides the added benefit of not having a tool set down out of position after a heavy cut.
Recently, I purchased some used stepper motors that had encoders already mounted on them, and connected them to my machine using two parallel ports. One port outputs the step and direction commands to the Gecko 203v drives, and, the other port reads the limit switches and encoder counts. I assumed the encoder counts would have to match the motor counts (i.e. 10000 step pulses per inch must equal 10000 encoder counts per inch,) but that is not the case. It appears that LinuxCNC can read just about anything that can be interfaced. My encoders are 1024 quadrature=20480 counts per inch, however, my motors only require 10000 steps per inch.
Although this is not a problem for LinuxCNC, in my case, the only drawback is the amount of encoder counts per second that I can read in realtime, which is limited by my breakout board. I can generate enough step pulses to move my quill at 240 ipm rapid, but, since my encoder count is more than twice what my motors require, the encoder becomes the bottleneck. Since motors can't run any faster than either step pulses can be generated, or encoder counts can be read, my encoders determine my maximum rapid rate. I currently have my machine working flawlessly at 100 ipm rapid with realtime feedback. I am happy with this because my machine only had 120 ipm rapid from the factory, and, I know that if my encoders matched my motor counts, it would be twice as fast.
I am posting my .ini and .hal files for anyone who wants to use them as a guideline. If anyone adds encoders to their stepper motors, they won't be disappointed. Additionally, if encoders with an index channel are used, they will also home to the index. This means it will set itself to a particular mark on the encoder so that homing will be on the money everytime, just like a real cnc.
The next logical step would be to link the feedback to the adaptive feed rate in LinuxCNC. This would actually slow the feedrate down if the motor approaches a stall and let the machine continue operation without losing its position. If the load continued all the way to a feed rate of zero, it would halt the machine with an ferror. Potentially, It could also provide an acceleration increase due to the fact that the motor won't stall. This method allows utilizing everything that the motor is mechanically capable of providing.