Welcome to LinuxCNC.org

clkeck1 wrote:These sound like they are of the vintage that have serial pulse coders
on the motors. I have a prototype decoder for these, and a device
that converts the signal to quadrature, but at present provides no
commutation info for the drive. I'm working on that.

Jon

jmelson 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.

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.

How much better are the digital drives than the analog? For simplicity reasons I may change out the drives and motor encoders for 6050 analog units so that I can stay into standard hardware/programing

Thanks
Cory

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.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

Its probably a fair project to interface to the digital drives because I'm pretty sure all info would have to be gathered by reverse engineering the existing drives/motor/encoder system.

Looking at the interface its likely just a three phase PWM plus fault plus serial encoder interface. HostMot2 already supports the 3 phase PWM with the BLDC comp so main issues on that side would be figuring out the PWM spec (or measuring the outputs of the controller when enabled) Same for the serial encoder interface. I suspect its slow enough that the HostMot2 twiddler interface could sample the serial data all in software. The processor on Spartan 6 twiddler is 125 MHz = 8 ns per instruction which allows bit banging some fairly fast serial protocols.

jmelson wrote:It's not a great or preferred solution, but there is an alignment routine built in to bldc which blindly energises the poles in a particular pattern and takes note of the resulting encoder counts.

It might be simpler to swap (or add) an encoder with a more conventional output. Some exist which also output conventional Hall signals too. (programable for pole count) which largely solves the commutation problem.