BLDC and fanuc redcap parameter problems?

post in error

andypugh wrote:

gmouer wrote:

Thinking further, I believe I had better make the cfg=fqihHT

You can't have "f" and "h" at the same time.

Yea, figured that out quick last night, it threw a BLDC error message in Linuxcnc. The h had no place being in there, a dumb mistake.

I changed to fiqHT and experimented after making some HAL connections for the pins I thought necessary in HAL. As far as I could tell the motor seemed to behave the same as in straight code conversion (fHT) I could not notice any homing operation take place when I cycled the init pin.

Next I tried qiHT and that did seem to go through a homing process with the init pin. The motor ran afterwards although poorly. I experimented with encoder offsets which made a difference in running but nothing even close to useable. I tried encoder offsets in a range from 50-3000 and have no idea if that range is even close to appropriate. Encoder offset of 100 seemed about the best, although very poor.

I will go play more tonight. I am lost why homing with the gray code and then using the encoder did not seem to play. (fqiHTT) I also notice that there is only one hall pattern choice, so homing and running would have to be with the same pattern by necessity. Still, homing with the gray code seemed to be non functional.

The encoder is a fanuc pulse coder, 3000 count. Does the bldc encoder count parameter get set to 3000 or 6000 allowing for quadrature. Just another item I am unclear on.

andypugh wrote:

gmouer wrote:

I changed to fiqHT and experimented after making some HAL connections for the pins I thought necessary in HAL. As far as I could tell the motor seemed to behave the same as in straight code conversion (fHT) I could not notice any homing operation take place when I cycled the init pin.

In that mode it won't init. It will run on the fanuc-to-hall commutation until it sees the encoder index, then it should switch to sinusoidal commutation.

Which pins dis you connect?

It might help to halscope the bldc state pins.

Next I tried qiHT and that did seem to go through a homing process with the init pin. The motor ran afterwards although poorly. .

Is your "poles" setting right?

Not in shop now, but going from memory on hal connections , encoder index enable, rawcounts, set pole parameter to 8 and encoder parameter to 6000, thats what I remember right now, will check later when I get into shop.

Didn't know that it wouldn't go through init/homing using the fanuc gray code. Switching to sinusoidal isn't going to play, the AMC drive is trapezoidal input only.

I did set pole count to 8

andypugh wrote:

gmouer wrote:

In that mode it won't init. It will run on the fanuc-to-hall commutation until it sees the encoder index, then it should switch to sinusoidal commutation.

Ah, ok, didn't know that. Sinusoidal commutation isn't going to play with the AMC drive which accepts trapezoidal only.

Well, when I said "Sinusoidal" I meant "Using the encoder". The output should still be Hall-pattern in "H" mode.

Ok I got ya. Encoder offset seemed to have no effect in that mode. That is why I thought it kept on running in code coversion mode and didn't switch over when the index when hit. I will retest more later.

I am going now to get my hal file and post it in just a few minutes.

Ok, here is the hal file I used for tests. I have a mesa 7i77 and 5i25 along with the parport breakout board. The encoder is connected through the 7i77 encoder0 inputs.

andypugh wrote:

gmouer wrote:

andypugh wrote:

gmouer wrote:

In that mode it won't init. It will run on the fanuc-to-hall commutation until it sees the encoder index, then it should switch to sinusoidal commutation.

Ah, ok, didn't know that. Sinusoidal commutation isn't going to play with the AMC drive which accepts trapezoidal only.

Well, when I said "Sinusoidal" I meant "Using the encoder". The output should still be Hall-pattern in "H" mode.

Ok I got ya. Encoder offset seemed to have no effect in that mode. That is why I thought it kept on running in code coversion mode and didn't switch over when the index what hit. .

Quite possible, that is why I suggested watching the out_type parameter to see what is happening:

github.com/jepler/linuxcnc-mirror/blob/m...nents/bldc.comp#L501

It should start at 0x10 then change to 0x0C then 0x02.

Great ! I will check that for sure during tonights tests.