Flying Electron wrote: > Does that mean for most servo based machines, EMC sampling the encoders > at 1khz is good? I think I remember reading the parallel port can get > accessed at 10khz, so does that imply the PCI 5i20 is overkill if I just > want to read 3 encoders for 3 axis and the parallel port based mesa card > is more then enough?
1 KHz is fine for "normal" CNC machines, servo and stepper both. Parallel port communication to smart controllers (controllers that do encoder counting, pwm generation, and/or step generation), like the 7i43, top out around 5 KHz. They definately *do* work well with emc2. The issue with parport-based communication isn't the max control-loop frequency (5 KHz is plenty), it's how much of your CPU time you're spending talking to the controller. Each time through the control loop (often called the "servo loop", even on stepper machines) takes about 100 microseconds over EPP, but only about 10 microseconds over PCI (to the 5i20). So with PCI controllers, your computer has a lot more time left over for updating the GUI or playing mp3s, or whatever. It makes the computer feel faster and more responsive. This is not crucial for a CNC control computer, so the EPP works fine. > Just an off the cuff idea, but would it be possible with a proper hal > driver to have a microcontroller count encoder pulses and then have emc > query the microcontroller across a serial port in realtime using a > custom hal driver? with a baud rate of 115200 maybe it's possible to do > 1000 samples a second? At 115Kbaud, you get about 13KBytes/second. Let's assume we have a 4-channel servo system, and let's use the awesome but not-yet-implemented TRAM feature of HostMot2. Then the transfers per servo loop look something like this. 2 bytes for setup. Reading the hm2 encoders takes 4 bytes for control, plus 4 bytes per encoder channel; 20 bytes total. Writing the hm2 pwmgens takes 4 bytes per channel, 16 bytes total. So that's 38 bytes total. (38 bytes) * (1/13K seconds/byte) is nearly 3 *milli* seconds per servo loop. So you'd get a servo frequency around 300 Hz, which *might* work, but really it kind of sucks. There's also the problem that reading the encoders and writing the pwmgens are separated by about half of that time, so after you get the encoder position and do your PID calculations and get the updated PWM setting out to the controller, it's been running for a millisecond and a half, and it's no longer where you thought it was! You're much better off using the parallel port, which has a throughput of about 1 MByte/second. Or the PCI bus, with about 1 GByte/second. > So with a hypothetical setup of a mesa card, a brushless dc servo drive, > and a 1000 CPR encoder, the mesa card's only job would be to read the > encoder and report back to EMC and EMC would send the pwm signals out > parallel port pins to the servo drive? No, the FPGA on the Mesa card does both encoder counting and PWM generation. The FPGA sends "number of encoder edges seen" to emc2, emc2 does the PID calculation, then sends the "desired PWM duty cycle" to the FPGA. The FPGA emits a rock-steady PWM signal of the commanded duty cycle without using any time on the control computer at all. If you're familiar with the emc2 "base thread", you can think of this as running the base thread on the FPGA. -- Sebastian Kuzminsky ------------------------------------------------------------------------------ This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev _______________________________________________ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
