Fanuc servo drive integration

More
15 Jun 2012 16:42 #20963 by PCW
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.

Please Log in or Create an account to join the conversation.

More
15 Jun 2012 16:59 #20964 by andypugh
jmelson wrote:

No, without commutation info, BLDC would have no idea what poles to activate.
So, I don't think that will work.

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.

Please Log in or Create an account to join the conversation.

More
15 Jun 2012 17:31 #20967 by PCW
It would be rather a shame to not use the Fanuc encoders as they are 65536 or even 131072 count/turn encoders (I believe they also have absolute data in the serial stream)

Please Log in or Create an account to join the conversation.

More
15 Jun 2012 18:33 #20968 by andypugh
PCW wrote:

It would be rather a shame to not use the Fanuc encoders as they are 65536 or even 131072 count/turn encoders (I believe they also have absolute data in the serial stream)


Do you need a Hostmot2 SSI interface?

Please Log in or Create an account to join the conversation.

More
15 Jun 2012 18:51 #20969 by PCW
Fanuc is not SSI AFAIK

Theres HM2 firmware for SSI and BISS but I have been too cheap to buy a
encoder to test these. The SSI interface should be OK its just a 32 bit version of
16 bit SSI interface we wrote for a customer (who loaned us a very expensive encoder)
For a working Fanuc encoder interface I would probably need a Fanuc encoder to play with

Please Log in or Create an account to join the conversation.

More
16 Jun 2012 01:52 #20977 by jmelson
andypugh wrote:

jmelson wrote:

No, without commutation info, BLDC would have no idea what poles to activate.
So, I don't think that will work.

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.

OK, that sounds quite interesting. You'd have to move the motor up to one
full turn to reach the index position, then the encoder count would jump by how
far you'd moved it when the encoder sees the index position.

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.

Yes, you could put on a Renco or Avago 6-channel encoder, although it would take a bit of hacking.
The Fanuc motors have a proprietary Oldham-like coupling between motor and encoder.
You might be able to adapt a kit encoder to the shaft after removing the coupling part.
Then, you'd have to phase the encoder to the motor poles. The advantage of the Fanuc
encoders is they are VERY high resolution, 32K, 64K, 128K and 1024K counts/rev!
And, the only way to do that is to send a pseudo-absolute position value when requested,
the quadrature rates would become insane.

Jon

Please Log in or Create an account to join the conversation.

More
16 Jun 2012 01:55 #20978 by jmelson
PCW wrote:

It would be rather a shame to not use the Fanuc encoders as they are 65536 or even 131072 count/turn encoders (I believe they also have absolute data in the serial stream)

Only the (alpha)A(resolution) encoders have the absolute data. The (alpha)I(resolution)
models do not give that data.

(alpha) means the Greek lower-case alpha symbol.
(resolution) means 32, 64, 128 or (i think) 1024
to mean 32K, 64K 128K or 1024K counts/rev.

Jon

Please Log in or Create an account to join the conversation.

More
16 Jun 2012 01:57 #20979 by jmelson
PCW wrote:

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.

The data rate is 1.024 MBits/second, and you get a 77-bit asynchronous stream of bits with no
clock after the start bit. So, the clock rate has to be pretty well-matched to stay in sync.

Jon

Please Log in or Create an account to join the conversation.

More
16 Jun 2012 02:14 #20980 by andypugh
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.

OK, that sounds quite interesting. You'd have to move the motor up to one
full turn to reach the index position,


it's not actually that complicated. The point is that all that matters for commutation is the motor magnetic positon. bldc simply takes the position with A at +V and B,C at -V as commutation angle zero (it's as good a choice as any). All the commutation inputs and outputs use this same convention internally, and it doesn't actually matter if this doesn't match the motor or drive assumptions because it all eventually cancels out.

The magnetic alignment process just wiggles the phases clockwise and anticlockwise, converging on the A+ B- C- position (an attempt to shake stiction free)

There are far cleverer ways to do it based on back-emf etc, and sensorless drives do exactly that, but AFAIK there is no way to get that data in to HAL, so it can't be used.

if anyone comes up with a scheme, I am happy to integrate it into bldc. ditto for any encoder schemes, I have already included the Fanuc 16 position commutation as both input and output modes, so for example you can (badly) translate Fanuc Gray code into Hall signals for a non-Fanuc drive. it's not a good solution, as 6 into 16 doesn't go, but it is enough to spin a motor until an index is seen and the component can start commutating sinusoidally.

Please Log in or Create an account to join the conversation.

More
16 Jun 2012 03:19 #20981 by clkeck1
Wow

You guys are currently way over my head. I need to do some major research.

The one servo motor is a model 5 part number A06b-0512-b031 and is marked "pulse coder". The drives are setup with a 6 volt battery so I would assume they are have an absolute encoder. I could really care less if the the absolute part works as homing is no big deal.

I haven't been able to find out if the encoders on the servos are compatible with 6050 drives. That will be the simplest option but I'm not against working outside the box.

Cory

Please Log in or Create an account to join the conversation.

Moderators: cncbasher
Time to create page: 0.185 seconds
Powered by Kunena Forum