Low cost slim glass scale

That's the good thing about glass scales, they are dead on, or they are NFG from the beginning. Just have to keep swarf out of them.

For giggles I have 1um scales on Z and X. Of course I can't hold 1um on them, the locking shifts things about, but it's possible to hold 0.0001" with a extreme care. That's more than good enough for me. Most of the time I'm pleased to be within a few thousandths. You can always ignore the resolution, but it's hard to add it back, if you don't have it.
Aim small miss small...
 
Aim small miss small...
So this can backfire pretty badly in some cases. Many low cost DROs use software to process encoder pulses, which is usually factors of magnitude slower than hardware decoders. There are "modern" DROs that use ATMega MCU running at 16MHz to do everything. Those can handle many be 50KHz edge frequency (50mm of travel per second for all axis inputs combined), 10KHz more realistically. This is adequate for 5um scales if you use them gently. A 1um scale on the quill or apron can easily overwhelm the CPU, which will lead to missed pulses, etc. This is especially a problem if you have any chatter, since the micro-movements are VERY quick. The end result is a LOT of missed pulses, and then you miss big and inconsistently.
 
So this can backfire pretty badly in some cases. Many low cost DROs use software to process encoder pulses, which is usually factors of magnitude slower than hardware decoders. There are "modern" DROs that use ATMega MCU running at 16MHz to do everything. Those can handle many be 50KHz edge frequency (50mm of travel per second for all axis inputs combined), 10KHz more realistically. This is adequate for 5um scales if you use them gently. A 1um scale on the quill or apron can easily overwhelm the CPU, which will lead to missed pulses, etc. This is especially a problem if you have any chatter, since the micro-movements are VERY quick. The end result is a LOT of missed pulses, and then you miss big and inconsistently.
You are so right. I tested my encoder SW to ensure that wouldn't happen. My platform can handle up to 250 KHz inputs, which is more than sufficient for my ELS. 100KHz is the max bandwidth of my spindle rotary quad encoder. (And that 100 KHz corresponds to 5000 RPM, which I will never do, since my chucks can't go that fast!)

Linear encoders, at least the scales I have, are much slower. I have 1um Z & X scales on my lathe, but won't run into an issue as I will never traverse that fast on feed or threading. (It would scare the heck out of me, for one thing.) For fast travel on a mill, or CNC, I'd want to redo the math to ensure myself there wouldn't be any issues. If you play in this domain, you need to check and double check things to avoid BIG problems.
 
You are so right. I tested my encoder SW to ensure that wouldn't happen. My platform can handle up to 250 KHz inputs, which is more than sufficient for my ELS. 100KHz is the max bandwidth of my spindle rotary quad encoder. (And that 100 KHz corresponds to 5000 RPM, which I will never do, since my chucks can't go that fast!)

Linear encoders, at least the scales I have, are much slower. I have 1um Z & X scales on my lathe, but won't run into an issue as I will never traverse that fast on feed or threading. (It would scare the heck out of me, for one thing.) For fast travel on a mill, or CNC, I'd want to redo the math to ensure myself there wouldn't be any issues. If you play in this domain, you need to check and double check things to avoid BIG problems.
So, funny thing is that over the last two weeks I've had three email threads about using TouchDRO next to an ELS setup. One guy has a 43,200 lines per rev. Renishaw encoder that he wants to run at 4000 RPM. That is 2.8MHz pulse rate... I have no clue what he is using for the ELS (I imaging an FPGA of some sorts, or possibly a Teensy?). He was complaining that TouchDRO "freezes" at that pulse rate, so I added some guard rails to the new firmware to prevent the freezing (I assumed that 100KHz was already pretty insane for a tachometer...) :)
 
So, funny thing is that over the last two weeks I've had three email threads about using TouchDRO next to an ELS setup. One guy has a 43,200 lines per rev. Renishaw encoder that he wants to run at 4000 RPM. That is 2.8MHz pulse rate... I have no clue what he is using for the ELS (I imaging an FPGA of some sorts, or possibly a Teensy?). He was complaining that TouchDRO "freezes" at that pulse rate, so I added some guard rails to the new firmware to prevent the freezing (I assumed that 100KHz was already pretty insane for a tachometer...) :)
I'm using a Teensy 4.1 for my ELS, so I can get away with some fairly ridiculous interrupt rates, but nowhere as fast as an FPGA could handle. I have a 1024 quad rotary encoder for the spindle (4096 counts/revolution). I only can do 4us per interrupt, but that includes doing a full position update and calculation whether to move the lead screw or not. Everything else is done off interrupt, including my DRO and display update and touch panel sensing and state machine. At sane chuck speeds there lots of margin for everything. Supposedly the CPU could keep up at rates that would blow up chucks, but I'm not going to test that! I tested the CPU for encoder performance with a encoder simulator, not a live system. But my rotary encoder is only 100 KHz BW (10us) vs 4us for the interrupt so there's some built in limiting. The encoder just can't rise and fall faster than roughly 10us, due to its internal circuitry.

2.8MHz is a pretty quick pulse rate for Arduino grade CPU's but not much for higher end stuff. Many higher end CPU's, even like a Teensy have built in quadrature encoders (hardware). Mine is limited to 32 bits. I didn't want to deal with (testing rollover issues) it, so I went to a signed 64 bit quad encoder in SW. That's what is running at 250KHz on my ELS now.
 
Back
Top