Michel Gouget wrote: > Dear All, > > I am considering adding encoders and home switches to my Sherline CNC mill. > > I see 2 benefits: > 1) Being *sure* of not loosing steps (estop, ...) > 2) Using (low precision) home switches and the index of the encoder, I get > *excellent* repeatability when homing. > > The mill is equipped with regular sherline steppers (135 oz-in, 1.8 degrees) > and a P/N 8760 driver (800 step/rev.) connected to a parallel port. The > steppers have a double ended 1/4" shaft. They are driving a 1mm master > screw. Everything is connected to EMC2 running on a dedicated PC. All is > actually working fine, with rapids of 450 mm/mn. I have a 4th axis on a > turntable with the same stepper. > > I expect to use US digital E2 quadrature encoders with 400 CPR and index, > giving a maximal theorical resolution of 1/400 mm, more than needed :) for a > cost of about ~200$. > > I expect to use the E2 T model, which will be sticked on the rear of the > stepper, in place of the handwheel, using the US digital centering tool. > > I expect to connect the outputs of the encoders to a second parallel port on > a PCI card. > > My questions: > > 1) Is it stupid :) ?
Encoders with steppers comes up every so often. I wouldn't call it stupid, but there are issues. If you lose a step because the load torque was more than the motor can deliver, a PID loop is not the answer. PID's response to feedback falling behind command is to drive the motor harder. With a stepper, that means step faster, which will just result in less motor torque and more lost steps. That said, there ARE benefits to encoders with steppers. If you avoid closing the PID loop, you can still use the encoder for position feedback. That would give you a following error if you ever lose steps. Better to find out right away instead of much later. It would also give you position feedback when the motors are disabled - basically a DRO during manual operation of the machine. The idea of using the index pulse for accurate homing is an excellent one. > 2) Has anyone already done that? > > 3) Is a parallel post fast enough for reading the 4 axis encoder pulses at > full speed? I'm not sure whether your "400 CPR" encoders are 400 counts per rev or 400 cycles per rev. The latter would give you 1600 counts per rev. If the former, the parport is definitely fast enough - you have 800 steps per rev, and EMC's software based encoder counter can count at LEAST as fast as the software based step generator can step. If it is 1600 counts per rev, you need to do the math. A speed of 450mm/min with a 1mm screw is 450RPM. 450RPM/60 = 7.5 revs/second. Times 1600 counts per rev = 12,000 counts per second. Add 50% to allow for variations in the quadrature waveform and you get 18,000 samples per second minimum. That corresponds to a base period of 1/18000 = 55.5 microseconds. Just about any computer can do 50uS, and many people are running much faster base periods in the 20uS range. > 4) Are there other encoders suitable? Is 400 CPR the correct value? That depends on what your goals are. With 800 step per rev drives, you might want at least 800 counts per rev on your encoder. > 5) I suspect that HAL+classicladder is powerful enough to handle the > *complex* homing (eg. Zero till the home switch trips (low precision > microswitch), then forward to the encoder index pulse, for all joints). Am I > right? If not, is it possible to program the homing sequence in C ? Actually, EMC2 can already do homing to an index pulse. It finds the switch, then continues on to the index. However there is a problem using that with steppers. In a servo system, when you reach the index pulse during that final stage of homing, the feedback value suddenly jumps to zero from whatever it was (the encoder counter resets on index). EMC is aware of that, and the position command ALSO jumps to zero at the same time. The result is that the command and feedback to the PID match, and everything works. But with steppers, you aren't using PID. When the feedback jumps to zero, EMC will make the command jump to zero, and the stepgen module will see and attempt to follow that command jump. One way to avoid that problem would be to run the stepgen in velocity mode with a normal PID loop. (The default is to use position mode which doesn't need a PID loop and lets you avoid tuning.) But doing that gets you into all the joys of PID tuning. An alternative approach would be to NOT reset the position feedback when the index pulse arrives. Instead, the index pulse would be ANDed with the home switch to provide a "precision home switch". The problem with that approach is that the "home switch" would only be on for a very short interval. The homing code expects the home switch to turn on when you hit it, and not turn off again until you've backed off of it. I'm sure there is a way to solve that problem, but nothing springs to mind right now. Regards, John Kasunich ------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ _______________________________________________ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
