Karl Schmidt wrote: > I under stand what Jon is saying - the OS latency isn't good enough to keep > the pulses coming > perfectly smoothly at very high speed - you would get 'jitter'. > Well, even with totally zero latency, the sample rate is just too low. But, the end effect is the same, at certain speeds, the pulse timing varies sharply. > So if you set up EMC to toggle a PP line at say 8hz - then looked at the > square-wave on a fast scope > - you will see jitter - and average jitter isn't the issue - it is max > jitter. (There is no way to > measure this in software.) This is what I'm getting at. Is a possible > solution throwing hardware > at it until it doesn't matter? Say: > > * Fast multi-core computer? > * PCI-E I/O > No, these don't really solve the problem. And, a fast CPU costs more than any of these boards do. Even a blazingly fast DSP like Blackfin can't completely solve the problem, although it would sure do for most CNC step & direction drives. > With PCI-E one should be able to write a DMA transfer to a PCI-E card that is > independent of other > things going on (this is what the E in PCI-E is all about). One could form a > buffer in memory that > is streamed to the card - the card would have a $5 FPGA chip with a PCI-E > block. You could set up a > Fifo buffer, and then the data would get clocked out 'perfectly'(there will > always be 'some' > aliasing jitter if the output is not a perfect multiple of the top clock). > This would keep most of > the work of ramping coordinating on the PC and in EMC as compared to a 'smart > controller'. > Well, this sounds good, but I'm not sure you can depend on streaming a LOT of data to a PCI-E device to be real time, ALWAYS, guaranteed. It may be that some other device hangs the bus for a while when you do something on the computer, maybe causing a screen region to be revealed, and a big DMA block transfer from memory to the graphics card is performed. RTAI guaranteed the availability of the CPU, ONLY, for the real time threads. Memory bandwidth can even be a problem if a lot of DMA is going on. RTAI has no control over that or the system busses. Let's see how this would work. Say you wanted to send up to 4 axes of step and direction info to a drive. Let's say you wanted to be able to run the drives up to 200 KHz. To get good timing at 200 KHz, you need to have a sampling rate of, say, 2 MHz, so the rate jump will only be 10% at the highest rate. So, you have to send 2 megabytes a second to the interface device ALL the time. And, the CPU has to generate a 2 MB data stream every second, mostly the same data repeated over and over. Yes, I think this WOULD go faster than using pure software, but it may not be the best way to solve this problem. I've been making my Universal Stepper Controller since 2002 for exactly this reason. It isn't limited to just step pulses, it also handles digital inputs, digital outputs, an interface to a spindle speed DAC, E-stop circuit, and can be used with encoder feedback on one or more axes as well. > So what I'm asking is: " what is the proper term used with EMC for buffered > and clocked pulse I/O > cards? "step timing generator"? > > I'm also wondering does EMC compile a pulse list and timing before the move > so there would be no > computation latency, or is it generated on the fly? > > Going even further - most "stepper motors" aren't really steppers - they take > step inputs and drive > a DC servo-motor looking at position feed back. Somehow the history of the > evolution of CNC has all > this working in a disjointed way. We shouldn't be generating steps - we > should have an I/O card/box > that is really a coordinated multi-axis DC motor servo controller that EMC > knows how to talk to. > OK, that's why I came out with a variant of the stepper controller called the Universal PWM Controller. Instead of generating constant-width pulses of varying frequency, it makes varying-width pulses of constant frequency, to directly drive a PWM power output stage. So, there are no steps anywhere in the system. EMC2 sends out a PWM output command, and reads encoder position from the board's counters. With this, I can drive both DC brush motors and brushless motors, using the appropriate drive units.
I have these boxes, and have been selling the PWM controller since 2004. I do believe servos are better than steppers, if just for the peace of mind of knowing that ACTUAL position is always being tracked. Minor crashes happen all the time, and you may not always notice the axis has jammed and thrown the position alignment off. Be sure to understand that while Gecko, Rutex and others do make step-driven servos, a LOT of people are still using REAL stepper motors on a wide variety of machines. The Gecko 201, 250 and variants greatly outsell their step-servo drives. > Hmm.. They call it a "Universal Stepper Controller" looks like 100ns - 4 axis > - They claim > 300ksteps/sec - What is the number on the big chip - looks like a xilinx - > I'm guessing an FPGA. Yes, Xilinx XC2S50E currently, the picture probably shows an older board with a 5V FPGA. > How does EMC talk to these? Does it just send it a Rate and a count for each > axis and then a start > command? No. It sends a rate, only. > Can it buffer two moves? Ramp? All done by EMC, a new rate is sent every millisecond, by default. If you have a buffer, then EMC is no longer in "real time" control of the machine, it has run somewhere ahead. Might as well use Mach for that. > (The hardware probably has just linear ramps I would bet and > no buffer - The USB receiver probably has a FIFO in it that could act as a > buffer - Pulling in that > buffer would cause some amount of pause as the next move is set up unless > they have a dual data path > where one is set up as the other one is running. It is parallel port, not USB. If it was buffered, then it would not be able to involve EMC in the servo loop when encoders are used. 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
