andypugh wrote:
In the interim it should be possible to use the bldc HAL component to read the quadrature pulses, perform a magnetic alignment and then generate commutation signals (Hall or Fanuc) for the drive.
[/quote]
No, without commutation info, BLDC would have no idea what poles to activate.
So, I don't think that will work.
What is the protocol for these encoders? If there is a way to get the serial data into HAL as an absolute postion then that can go straight into the bldc component to generate commutation signals.
It produces a 77-bit string of bits. There is a wide position readout that includes a field for
number of turns (signed) and a field for shaft position, such as 32768 or 65536 counts
(unsigned). It ends with a 5-bit CRC code to verify data quality.
If the encoder is an "incremental" encoder, it has no indication of position, and the
shaft angle value jumps suddenly to zero when it passes the index position for
the first time after power on. So, what they do is provide a backup battery in
the controller, and have brakes in the motor that assure the encoder cannot move
by even one count while powered off. The battery does not power the encoder, it
only powers a CMOS memory that holds the position count while the rest of the
encoder is not powered. This type of encoder could be used to derive commutation
info, but it would need a brake and backup battery, and if the memory was lost,
it would have to be hand-cranked one rev to pass the index pulse.
If the encoder is an "absolute" encoder, it also has a low-resolution field that
reports absolute position with 1024 counts/motor quadrant immediately at power on.
This could be used to derive commutation info without requiring a battery, and
the standard homing routine could pick up the index position. The encoder reader
would need to detect the appearance of the "homed" bit and prevent a servo trip at
that point due to the shift in count.
Jon
