The very basic motion resolution. Say you want a 1um resolution of a step (no matter how of whether you achieve that), but you also want to keep maximum traverse travel speed of 2m/s. That would need 2 milion steps per second. (Now we don't discuss that without linear drive you can not have accuracy better than 50 microns ;-)) All I asked for is GOOD *output* resolution. You simply NEED to have the potential there.
As for the input... the encoders used for high microstep rate per second are all analog sine/cosine, so that the 14-bit ADC resolution (used to be 12-bit and 14-bit, not 16-bit up to 18-bit is possible) is capable of those say 100KHz per second. Say you divide those 10 microsecond whole sine/cosine periods into only 100 parts and you suddenly ended with some 10 milion microsteps per second. Canon makes LCD litography equipment and the old projector could move the positioning table (with about 2x3m glass on it) 500 milimeters in half a second. All with acceleration, deceleration and precise stop in the accuracy better than 1 micrometer. How many quadrature output changes per second would that equal as a maximum? The theory behind this is this: the machine will be only slightly expensive if we make it 100% faster. But 100% faster in two-three axes translates up to 2-3x the production speed! (or so..) In other words, if you do a lot of empty moves, a faster machine will beat the slower machines. On 3/31/08, Neil Whelchel <[EMAIL PROTECTED]> wrote: > Hello, > It is too early to tell what the reasonable maximums are, I will have a > better idea when I build a few modules. However, I have plans to count 16 > bits worth of changes, so reading the register 10 times a second would be > able to count just about 65536/2*10=327680 per second. With an encoder > with 1024 counts per rev, this works out to be 327680/1024*60=19200 rpm! > The microcontroller will be able to handle up to about 4.5 MHZ worth of > input pulses. I see the major limiting factor here as the response time > from the encoder itself, there are very few encoders around that don't > start missing pulses at around 150 khz, ones with less counts per rev can > usually exceed this however, but look at the resulting RPM.. > Also, when very large RPM ranges are needed, a common trick is to use 2 > encoders, one with a high pulse count for fine positioning, and another > with a low pulse count for high speed rough position. When the RPM falls > below a certain point, a calculation is made to determine the offset to > the high res pulses, and the handoff is made. (This is sometimes done in > the same physical encoder using only the index pulse above a certain RPM.) > What could you possibly need 100,000 counts per second for? > > > -Neil Whelchel- > C-Cubed > 760 366-0126 > - I don't do Window$, that's what the janitor is for - > > > Intolerance is the last defense of the insecure. > > > On Sun, 30 Mar 2008, Mario. wrote: > > > Okay, if you can do turnaround of at least 100 thousand output hardware > > changes per second, I'm in. Quadrature outputs. > > > > On 3/30/08, Neil Whelchel <[EMAIL PROTECTED]> wrote: > >> > >> Hello, > >> I guess I should have been more specific when I was discussing the > >> topology about connecting to a WAN, or even a non-related internal > >> network. I had intended to imply that > >> the WAN/LAN and the module network would be separate, one network card for > >> each. However, with a proper VLAN switch, I feel that it MAY be possible > >> to combine them, but I am not going to spend any time on that. ;) > >> I have looked into a few realtime Ethernet papers and implementations such > >> as Rtnet, Rether, and MicroNet, and it appears that Rtnet has most of > >> what is needed for the host side (if not work just fine as-is). However > >> for the I/O module side, the Ethernet stacks by Atmel and the like are > >> nearly useless to me because they are targeted > >> for much more complex (expensive) microcontrollers. (The compiled > >> Atmel stack is nearly 3 times the size of the total flash of the > >> microcontroller I am considering using.) Call me cheap, you'd be > >> right, but why throw all of the complexity and money at it when it is > >> likely that the cheaper, simpler approach is likely to provide the best > >> answer. > >> > >> > >> -Neil Whelchel- > >> C-Cubed > >> 760 366-0126 > >> - I don't do Window$, that's what the janitor is for - > >> > >> > >> Can anything be sadder than work left unfinished? Yes, work never begun. > >> > >> > >> On Sat, 29 Mar 2008, Jon Elson wrote: > >> > >>> Neil Whelchel wrote: > >>>> Hello, > >>>> I have joined this list because I an working on a project to convert my > >>>> old CNC mill and manual lathe to EMC and I saw that there are what seem > >> to > >>>> be limited methods of interfacing EMC to the outside world, and I think > >> I > >>>> might be able to help in this area, among others. Sure there is the > >>>> parallel port, and a hand full of (supported) ISA and PIC boards, but > >> none > >>>> of them seem to provide an optimal interface, and others are simply not > >> in > >>>> the right price range to make a project feasible. I have been tossing > >>>> around the idea for a few months now of creating some very cheap (open > >>>> source) microcontroller based I/O modules that communicate using > >> Ethernet > >>>> at the layer 3 level (Network Layer). > >>> There is a real-time Ethernet driver already in existance, but > >>> there are a number of restrictions on how it works. Also, these > >>> restrictions means it won't work with off the shelf ethernet > >>> micros and their off the shelf ethernet stacks, such as Atmel > >>> and NXP make. At least, that was my understanding. Whether the > >>> micro's library can be adjusted to make it work with the RT-net, > >>> I don't know. The RT-net requires total isolation of the RT > >>> part from the WAN with a router that can handle the RT-net > >>> flavor, so that pretty much has to be another computer with two > >>> ethernet cards/ports. > >>> > >>> I wanted to provide an ethernet interface to my boards, which > >>> are parallel port based right now. But, this was just over my > >>> head and beyond the time I had available. > >>> > >>> Jon > >>> > >>> > >> ------------------------------------------------------------------------- > >>> Check out the new SourceForge.net Marketplace. > >>> It's the best place to buy or sell services for > >>> just about anything Open Source. > >>> > >> > http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace > >>> _______________________________________________ > >>> Emc-developers mailing list > >>> Emc-developers@lists.sourceforge.net > >>> https://lists.sourceforge.net/lists/listinfo/emc-developers > >>> > >> > >> ------------------------------------------------------------------------- > >> Check out the new SourceForge.net Marketplace. > >> It's the best place to buy or sell services for > >> just about anything Open Source. > >> > >> > http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace > >> _______________________________________________ > >> Emc-developers mailing list > >> Emc-developers@lists.sourceforge.net > >> https://lists.sourceforge.net/lists/listinfo/emc-developers > >> > > > > ------------------------------------------------------------------------- > Check out the new SourceForge.net Marketplace. > It's the best place to buy or sell services for > just about anything Open Source. > http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace > _______________________________________________ > Emc-developers mailing list > Emc-developers@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/emc-developers > ------------------------------------------------------------------------- Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace _______________________________________________ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
