Hello again, Ok, stepper motor, or servo, it really doesn't make any difference, I had assumed that your reason was for torque, not precision. I can see that your point is that you want to record/produce ALLOT of steps in a short time, which is understandable for projects with limited resources. However, in such cases, I would suggest multiplying steps to bring a step size (up) to something more reasonable, or in the other direction around, using a lower resolution encoder. In the real world, I have found little use for more than 100,000 steps per inch, and that is even pushing it a bit. ;) Most CNC software only carries out positioning to 10,000 steps per inch. I am just trying to be careful with high frequency stuff because it ends up being much more complex and sensitive to cabling issues and noise, which simply reduces the chances of overall success, especially when there are other methods available.
As far as your suggestion about losing track of position by switching from/to the index pulse above/under certain speeds, you will have to build a better case.. ;) Let's say that we can count individual pulses under 3000 RPM, and our target speed is 10000 RPM. Then in this case, we could use say 2000 RPM as a handoff, this way we still have 1000 RPM overhead, and we know that in the time of one revolution it would be impossible to go from 2000 RPM to over 3000. So far, as long as all of the hardware and electrical stuff works fine, we would never lose count. So as the shaft accelerates through the 2000 mark, we know exactly when the index will come around, and what our count will be at that point, if all is as expected, we simply ignore the quadrature, and look within a small time window (just wide enough to account for possible acceleration/deceleration) in for the next index pulse. If the pulse shows up as expected, add/subtract however many counts of one rev to it, and re-adjust the window. Then when the speed falls below the handoff, we know that we will have a good quadrature and it will line up with the index, so the handoff is made. In both cases we have a way of checking for failure, when running slow, if the index is in the wrong place, we know we missed a count somewhere, in the other case, if the index appears at the wrong time, we also know we missed something. By the way, when we are only counting index pulses, we can still get a fairly accurate position based on the time window. Since we know how much time until the next index pulse shows, we also can add an appropriate amount of counts to the output data if a read occurs at some time other than when the index pulse is seen (which is almost always the case). For example one of the projects I did in the past was to sense the position of a turbine engine shaft turning at 80,000 RPM using only one PPR. It was a trivial matter to get 1000 counts per rev with an error of less than 2 counts per rev. I just don't see any viable situation that would cause you to lose track.. And afterall, what I am talking about here is more of a limitation of the quadrature encoder than the decoder. I am talking about a work around for a slow encoder, not a workaround for a slow computer/decoder. -Neil Whelchel- C-Cubed 760 366-0126 - I don't do Window$, that's what the janitor is for - "Ask not what A Group of Employees can do for you. But ask what can All Employees do for A Group of Employees." -- Mike Dennison On Mon, 31 Mar 2008, Jon Elson wrote: > Neil Whelchel wrote: >> As far as your stepper machine with 256,000 steps per inch, > It is not stepper, but servo. The belt ratio was chosen to get > sufficient torque to the leadscrew, not for reason of resolution. > I fail to see >> why you would need an encoder that matches that resolution (.000000390625 >> per step), my electron microscope stage is only 50,000 steps per inch. >> I can see why you would need so many steps per inch to get the needed >> torque, but that has nothing to do with the the encoder. >> Also, I'd like to make it clear that I am not attacking anyone's ideas >> here, I really appreciate your input, it will help me make better design >> decisions. If there is a real need for very high count rates, I will be >> forced to include it in the design, however for jogging speeds with very >> high speed motors and very fine encoders, the usual technique is to use >> only the index pulse (or a second encoder or track on the same >> encoder that has a much lower resolution) above a certain speed. > This seems like an excellent way to lose position. The > realignment of the counters has to be perfect, EVERY time. > I can see why such stuff was done back in the days of discrete > transistors and early TTL, but it doesn't make sense anymore. > > 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
