We are basically in agreement. I just imagine that when EMC hits the limits you described we will end up needing to use more intelligent hardware outside the computer not faster bus interfaces to it. Say an FPGA based controller.
On Sat, Apr 10, 2010 at 9:08 PM, Jon Elson <[email protected]> wrote: > evan foss wrote: >> You don't require that kind of bandwidth to move a stepper motor. > Well, let's make up a test case. Say you have a Sherline or Taig with > 20 TPI leadscrews. To do 60 IPM or 1 IPS, the leadscrew needs to spin > 20 RPS. With a Gecko 10X microstepping drive, that requires 20 RPS x > 2000 microsteps/rev = 40000 steps/second. EMC2 can do that on a decent > computer, but it is pushing things a bit. Where the problems start is > that you need to issue a step pulse every 25 microseconds. Now, the way > EMC's stepgen is set up, it needs to have an interrupt every 12.5 us, so > it can raise the step wire and then lower it. 12.5 us is doable, but it > requires a CPU toward the upper end to service the BASE_THREAD and still > have enough CPU left to keep everything else working smoothly. > The other problem is that it can't produce 55 IPM smoothly. That > requires 55/60 = .9167 IPS, or 18.333 RPS, or 36666.7 steps/second. > That is a step period of 27.272727.... us, which doesn't divide cleanly > into 12.5 us. So, the step pulses necessarily have ragged timing. This > is not just at 55 IPM of course, it is at all speeds below 60 and above > 40 IPM! Yes, the next entirely smooth speed is 40 IPM, where it takes > THREE 12.5 us periods for each step, exactly. Anywhere in between, the > step pulses are constantly requiring the stepper motor to accelerate and > decelerate thousands of times a second to stay in sync. > > So, that is why hardware can greatly help the problem of faster, and > smoother step pulses. Taking the above example, the "clock" for the > step timing generator was 12.5 us or 50 KHz, and note that many > mid-range computers may not even be able to do that. My Universal > Stepper Controller uses a 10 MHz clock, or 200 times faster! So, > instead of a timing granularity of 12.5 us, it has a granularity of 100 > ns. In the above example, between 40 and 60 IPM, the timing is jumping > between 2 and 3 12.5 us cycles, for a 33% jump in timing. No motor can > actually follow that, only because the Gecko is a 10X microstepping > drive, the real timing jump in full-step units is 3% (if my logical > thinking about this is correct). With a 10 MHz clock, the timing jumps > are much smaller, instead of 33% it is 0.17% at that rate. Even at the > rated 300 KHz rate, the timing jump is just 3%. > > So, as I said before, the parallel port bandwidth is not the issue, so > maybe I am actually agreeing with you. But, software that is sharing > the CPU with a lot of other important tasks just can't directly generate > the precise timing needed for faster step pulse generation. > > > Jon > > ------------------------------------------------------------------------------ > Download Intel® Parallel Studio Eval > Try the new software tools for yourself. Speed compiling, find bugs > proactively, and fine-tune applications for parallel performance. > See why Intel Parallel Studio got high marks during beta. > http://p.sf.net/sfu/intel-sw-dev > _______________________________________________ > Emc-users mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/emc-users > -- http://evanfoss.googlepages.com/ ------------------------------------------------------------------------------ Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev _______________________________________________ Emc-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/emc-users
