What do you mean by "encoder is in an invalid position". Every position read from an absolute encoder is valid in the sense that it reflects the actual position of the encoder within its tolerance.
If you used a 256 count encoder for your 24 positions, each tool position would correspond to 256/24 = 10-2/3 counts. So if the encoder read from 0-10, that would be position zero. 11-22 would be position one, etc. On power up, you would read the encoder and that would tell you what position you were at. Assuming that the tool positions corresponded to the start of each range, 0 would correspond to position 0, 10 would correspond to tool position 1. 21 would correspond to tool position 2, etc. To allow for some "slop", you would probably set things up so that 255, 0, 1 were tool position 0. 9, 10, 11 were tool position 1, etc. If you found that you were between positions, it wouldn't really matter. The first time you seek to a tool, you would still know where you are and where you have to go. A true absolute encoder is a static device. You can read a value without moving it. Ken Kirk Wallace wrote: > On Sun, 2008-07-20 at 14:28 -0400, Kenneth Lerman wrote: >> When you power up, you read the 8 bit value (for a 256 position absolute >> encoder). That will give you an unambiguous position. >> >> Ken > > On my original design for a tool changer encoder, I had a sprocket > engaging the carousel chain: > > http://www.wallacecompany.com/machine_shop/Shizuoka/00030-1a.jpg > > with a gearbox to get one encoder revolution per chain revolution. The > encoder then needs twenty-four positions or five data bits. I was going > to use IR LED's and photo-transistors on each side of a disk: > > http://www.wallacecompany.com/machine_shop/Shizuoka/Tool_Changer_Encoder-1a.png > > A sixth bit was added as an "in position" signal. > > Currently the chain is moved by a Maltese Cross: > > http://www.smom-za.org/MalteseCross/mechanics.htm > > so only valid positions would be possible at rest. The problem here is > that the Maltese Cross moves the tools in a jerky fashion for each > position change and it is slow. I want to drive the chain with a simple > gearbox with acceleration/deceleration control for the start and end > position. With this and the disk encoder, there will be invalid input > between positions, which is mostly okay because I'll control the motor > to stop at validated positions. The problem is when the system powers up > and the encoder is in an invalid position. The only way to validate the > position is to move the chain. I don't want to do this automatically, > for safety. I could have the user manually initialize the changer on > each power up, but I prefer to not have to do that. > > I could go to a high resolution encoder, but this just reduces the > chance of getting an invalid start. I would prefer to have an encoder > that has no invalid states. > > ... > > Now that I have given this more thought, an invalid start may not be a > problem, because when a tool change is requested (and expected), the > position will validate on the first position change. The only down side > is possible wasted motion by guessing which way to go or how far. > -- Kenneth Lerman Mark Kenny Products Company, LLC 55 Main Street Newtown, CT 06470 888-ISO-SEVO 203-426-7166 ------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ _______________________________________________ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
