Eureka! A big problem solved, maybe…
Since switching to the 128-cpr encoder I’ve been having a slightly peculiar problem and I think I may have found the cause: serial buffer overflow.
What’s happening is that during program operation, when the DRO is receiving updates, if I spin the encoder very fast, the LCD display would lock up and refuse to display any values. Originally, the only way to recover was to reset the Arduino, but I made some improvements that allowed for a softer recovery. Basically, if it froze, you had to wait a second, then jiggle the encoder a little, and the display would come back. It still wasn’t robust, though, and I couldn’t see what was going on.
Well, it turns out that the Arduino’s serial buffer is a whopping 128 bytes, which isn’t very much. With 6-byte messages streaming in and 3-byte messages going out, it seems very possible that I’m getting buffer overruns. If this is in fact the problem, there are a bunch of different possible solutions, but they all basically come down to reducing the amount of data moving over the wire, particularly the update rate of the encoder.
On the incoming side, I’ve already made a major change in ditching the DRO display during program operation. Instead, I created a different page which displays the spindle and feed rate override percentage values, which are what you’d actually control in that setting. Next, I’m changing the way updates are sent so that only the “hot” parameter gets updated more than twice per second. In other words, if you’re manually jogging the X axis, then the X axis DRO will update ten times a second, but everything else will only update twice. Likewise, in program operation, if you’re tweaking the FRO, then the FRO% and velocity will update fast, but the spindle RPM will go in the slow lane. Taken together, this will reduce the number of updates without, I think, reducing any utility.
On the encoder side, there are a few possibilities. I didn’t have this problem with my old encoder, which was I think due to (1) it being only 32 CPR, so you’d have to spin it 4x faster to get the same amount of data output; and (2), it had detents, which slowed down the spin rate even further. All told, I think I liked the feel of the old encoder better. I *really* like the detents, because they allow for precise positioning. The lower pulse rate does make it less nice to use for long jogs, but since the pendant has continuous-jog buttons for both X and Y, I think the main use of the handwheel is primarily for nudging, where 32 CPR is plenty.
A true CNC MPG wheel like this one might be the best of both worlds, but it adds a lot of expense ($60-$80 vs $20-$30). I also picked up some really basic encoders of the type used in consumer audio/video equipment which I’m interested to try. They’re 24-count, detent type, and cost under $5 each. I previously tried some Panasonic encoders like this and they failed, because the output was unreliable for steady rotation, but maybe these will work better. If they do, it could trim $30 or more from the price of a finished pendant.