On Sun, 11 Apr 2010, Karl Schmidt wrote:
> Date: Sun, 11 Apr 2010 16:21:13 -0500
> From: Karl Schmidt <[email protected]>
> Reply-To: "Enhanced Machine Controller (EMC)"
> <[email protected]>
> To: "Enhanced Machine Controller (EMC)" <[email protected]>
> Subject: Re: [Emc-users] High speed I/O for EMC
>
> Andy Pugh wrote:
>> There are several supported by EMC2.
>> http://wiki.linuxcnc.org/emcinfo.pl?EMC2_Supported_Hardware
>> The feeling I get is that most people are using Pico or Mesa cards.
>> (My machine uses the Mesa 7i43 ($79) though my motivation was more IO
>> lines rather than better stepper speed. )
>
>
> I must be missing something. There must be a term for this kind of hardware
> as opposed to I/O hardware like the PP(parallel-port) - (based on a FPGA or
> a dedicated fast uP with PWM I/O written in machine code) that takes 4 axis
> input of steps AND timing information instead of the OS timing each pulse
> the timing is in the cards hardware.
>
> 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'. 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
Not neccesarily, some of the fastest computers still have sizeable latencies
especially if you are trying to generate fast step streams in software.
Multicore does appear to help with latency. I would expect an all PCIE
computer might have better latency, as bus master devices are on the fast
switched PCIE fabric, not a shared bus like PCI where a DMA block transfer
could block all I/O traffic for 10s of uSec. Note that the PCIE interface is
of no great advantage to EMCs hardware devices, just that its less likely to
get in the way. In fact an ISA (or the LPC equivalent that drives many current
motherboard SuperI/O chips) interface is fast enough for most non-exotic CNC
control, as is a parallel port, (probably less the 1 MB per second)
>
>
> The problem is most of this hardware is set up to 'stream' really fast for
> moving digital video etc - but not timed random access - it relies on
> hardware FIFO buffers to cover the interrupts and the timing is generated on
> the graphics card. I'm thinking one could set up a buffer with the move
> pulses and timing and stream it with this hardware rather than depending on
> the OS for the timing.
>
> I write in machine code for embedded micros - I understand very well what is
> going on hardware wise.
> The problem I see is that there are always going to be interrupts that keep
> a PC from being real
> time (there are even hardware only interrupts that the OS can't do anything
> about). If the computer
> is super fast - or multi cored - the time to handle the interrupts can become
> so fast that the
> jitter is no longer an issue. I know enough about the 'real-time' kernel to
> know you can suspend
> most of the interrupts. But there is no way it can provide a 'perfect' output
> sq wave to the printer
> port. There will always be some jitter - ( a poorly written BIOS can make a
> problem here.) The
> jitter may be so little as to not matter, or it may matter.
>
> 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'.
>
> 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"?
EMC does not work well with buffered hardware as it complicates the timing,
and makes many operations that require real time motion response to external
events problematical. By keeping all real time control in one place, EMCs
control model is simple and powerful.
The hardware step generators that I know work with EMC (Pico and Mesa) have no
(unwanted) buffering, They are essentially rate generators which with their
assosciated drivers, comprise a velocity mode servo system. The feedback loop
in this case compares the requested position with the actual step count and
sets the step rate appropriately...
>
> 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.
> (Think about it this way - why tell someone to take one step towards the
> north. followed by many
> others when you really want his to just go to so far north at a particular
> speed? Further you have
> the same guy that is going east at the same - if one direction is falling
> behind a bit you can tell
> the other to slow as well to minimize path error - thus make a smoother path
> than a step interface
> can do.
Well there are step input servo drives, but I would guess with EMC, step
drives outnumber them by a large factor.
For real servo drives, analog velocity mode control basically does what you
expect (go north at 345 RPM) There are at least three EMC compatible cards
that will provide analog velocity mode control (well the vleocity part is
usually handled by the drive)
Using step+dir to run a servo is actually OK if you think of the step rate as
being a velocity command, really no different than an analog velocity mode
servo or sending a velocity command over Ethernet. The real problem with this
system (step+dir servo) is that the position control loop is now in the drive,
not EMC, so you now have an open loop system( a missed step is gone forever),
no ability to monitor following error, and a proprietary, perhaps windows only
tuning program.
Peter Wallace
Mesa Electronics
(\__/)
(='.'=) This is Bunny. Copy and paste bunny into your
(")_(") signature to help him gain world domination.
------------------------------------------------------------------------------
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
