Well, I will be the first to admit that there are limits to my knowledge. I am primarily a software guy, specializing on the Mac and iOS platforms; however I do dabble in electronics hardware as well. My CNC knowledge is mostly self-taught; so there could well be gaps there.
However, there are things that I am
quite certain of; because of direct hands-on experience. The incremental encoders output signal is one of them; as I have one in my other hand right now...
I'm going to presume that's a typo; and you meant to say ten bits (which is indeed 1024 possible values), not one bit...
A ten bit absolute encoder is not useless in the general sense; it's just not really adequate for CNC positioning applications; and certainly not as a linear encoder for CNC. A good use for a ten bit absolute rotary encoder might be for a volume control on a high-end stereo.
For CNC positioning, especially with linear encoders, you need many more bits than ten... how many depends on the length of the encoder; and how many counts per unit (inches or centimeters) it has. For example, for an encoder with 0.0001 resolution, with a length of 20 inches, there are 200,000 total counts from one end to the other. This will fit into 18 bits (2^18 = 262144).
I have never seen what you are describing advertised. This does not necessarily mean it doesn't exist... just that
I've never seen it. Every absolute encoder I've seen advertised has no battery or capacitor backup; it just outputs the value corresponding to it's current position when powered, no matter what. This is typically done using Grey code; so that there is only one bit changing at any given time (see
https://en.wikipedia.org/wiki/Gray_code for more info).
Perhaps you know more about the insides of a Haas control than I do (likely, considering I've never taken one apart)... how are the axis encoders interfaced to the control? Quadrature? High-speed serial? Where is the backup power supply located? If it's quadrature, is there a hardware counter that's kept powered up by the backup power supply?
I prefer the terms "low end", "mid-range" and "high end", instead of "hobby CNC" - because there are people who make money using machines built with open-loop stepper systems and controls like Grbl or Mach 3... and some of these systems are commercially manufactured and marketed at certain kinds of professionals... and as time goes by, features that were once solely in the domain of high end machines migrate downwards, until they are available on the cheapest of control systems.
I had missed the fact that this thread is in the LinuxCNC forum (I got here via the "Today's Posts" button); so I will now infer that the control we are talking about is, in fact, LinuxCNC; interfaced via parallel ports to CNC4PC C10 cards.
As stated earlier; I
think the original poster is going to need to upgrade his control system to use something with a FPGA in it; such as one of the Mesa boards; in order to add encoders at all. As LinuxCNC is an open-source system; it should be possible to interface a true absolute multi-bit Grey-code encoded set of linear encoders to the system; but I suspect that doing this will involve writing code, both C/C++ for the Linux side, and Verilog/VHDL for the FPGA side. Co-operation of Mesa might be required as well.
FWIW, these Wikipedia articles may shed some more light on the subject:
https://en.wikipedia.org/wiki/Linear_encoder
https://en.wikipedia.org/wiki/Rotary_encoder
Also, just in case anybody was wondering, Verilog code for a FPGA card to do quadrature decoding might look something like this:
Code:
module quadratureDecoder(
clock,
A,
B,
increment,
count
);
input clock;
input A;
input B;
input [7:0] increment;
output signed [31:0] count;
reg [2:0] A_delayed;
reg [2:0] B_delayed;
always @(posedge clock) A_delayed <= {A_delayed[1:0], A};
always @(posedge clock) B_delayed <= {B_delayed[1:0], B};
wire count_enable = A_delayed[1] ^ A_delayed[2] ^ B_delayed[1] ^ B_delayed[2];
wire count_direction = A_delayed[1] ^ B_delayed[2];
reg signed [31:0] count;
always @(posedge clock)
begin
if(count_enable)
begin
if(count_direction)
count <= count + $signed(increment);
else
count <= count - $signed(increment);
end
end
endmodule
That's from something that I'm experimenting with to add closed-loop functionality to Grbl... it hasn't been tested yet on actual hardware (I'm waiting to get all the modules into the project so I can figure out how big of an FPGA development board to order), so don't hook any motors up to it yet! However, I can say that it at least compiles with the Icestorm toolchain for Lattice Ice40 FPGAs...
Multi-bit Grey-code interfacing would be a bit different; but still have the same general feel to it (in other words... it's still Verilog).