Well, I think I have figured out most of what this encoder can do. It seems to have a 16-bit binary count per revolution plus a 16-bit signed count of revolutions, and these are battery-backed. It also has a 10-bit count of absolute angle per quadrant.
If the backup battery doesn't save the high-res position, then it starts off counting from zero, and then jumps back to zero when it passes the index mark the first time. There is a bit to indicate it has found the index mark. So, I think I can see how one could use this with EMC, but it is just a little bit crude to deal with homing if you don't want to deal with the battery. What I am thinking is the 10-bit absolute angle could be sent to the bldc component for initial commutation alignment. The high-res angle part could be used, but the driver would have to watch for the jump when it passed the index the first time, and fudge the count with an offset so it didn't cause a following error. This fudging would be crude, as the encoder might only be sampled at 1 KHz. I guess the last velocity could be used to figure out about how fast you were moving each sample. Then, when the homing sequence searched for the index, the fudging offset could be removed when the rotation sign bit changed, and the system would be perfectly aligned at the index mark of the encoder. Only the 16-bit angular count would be used, and the driver could sign-extent the value for multiple rotations. There are two things I'm trying to accomplish with all this. First, if you don't use a backup battery, the encoder count jumps suddenly when it passes the index position the first time after power on. Second, there doesn't seem to be a command you can send to the encoder to zero the count at index. And, since the encoder is only sampled at some rate (about 10 KHz is the maximum) then you are likely to miss the exact moment when the index pulse is passed when homing, so you have to just accept that it happened recently, and the encoder count WAS zero at that moment. One other concern I have is that if the motor was to be rotated while encoder power was off, I believe the battery-backed count would no longer be correct. This seems to be a serious flaw in this serial absolute encoder scheme. Now, maybe the encoder actually re-zeroes EVERY time it passes the index position, so what would usually be a small error won't accumulate. (If you moved it more than a turn, then the count of turns would certainly be off.) So, anybody have any comments on this? There probably are quite a number of machines out there with these encoders on them, all newer than the very first series of AC "red cap" motors. Jon ------------------------------------------------------------------------------ Achieve unprecedented app performance and reliability What every C/C++ and Fortran developer should know. Learn how Intel has extended the reach of its next-generation tools to help boost performance applications - inlcuding clusters. http://p.sf.net/sfu/intel-dev2devmay _______________________________________________ Emc-developers mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/emc-developers
