From: Jon E. <el...@pi...> - 2010-11-30 02:54:54
|
Colin Kingsbury wrote: > At first I was not really big on this but the more I think about it, the > more I like it. I play with small, benchtop size machines, where inexpensive > steppers and drives generally work well and cost half or less of what servos > would. A pseudo-servo mechanism that simply tripped a fault when something > bad started to happen would provide most if not all of the benefit that true > servos would, at much less cost. It's not magic and won't make the machine > "more precise," but it would make it more fault-tolerant and that seems > significant. It would also be a unique competitive edge that could bring a > lot of users over to EMC2. > > Is this something that could be done just by wiring a few ~$50 encoders into > a parport, or would you need more specialized IO hardware? > Each encoder needs 2 pins, so it could be done with an extra parallel port. But, the software encoder has a speed limit. If you are running a 25 us (SERVO_PERIOD_NS = 25000) then you could keep up with encoders moving at about 40,000 counts/second, but should leave significant margin for noise and timing fluctuations. So, maybe 25,000 counts/sec is a good safety factor. Now, if you have low-res encoders with 200 lines/rev, that gives 800 counts/rev. That is a lot less than a microstepping drive on a stepper, so you really can't use it for closed-loop control, but you can use it for detection of positioning errors. Well, let's take a Sherline or Taig as an example, they have a 20 TPI leadscrew. So, 800 counts/rev * 20 TPI gives 16,000 counts/inch of motion. So, at the 25,000 counts/sec safe limit, this is 1.56 inches/second, or 93 IPM, which is probably excessive for one of those machines. On the other hand, if you wanted to use a 2000 line/rev encoder giving 8000 counts/rev, you would be limited to 9.3 IPM. So, you can do the calculation for the SERVO_PERIOD and the machine/ encoder combination and see if a hardware encoder counter is warranted. Jon |