BLDC and fanuc redcap parameter problems?

andypugh wrote:

gmouer wrote:

[I was going to comment about how rough and forgot. Rough is tough to describe of course. The best I can get is like a 4 cylinder engine with one or two not firing, or a V8 with the wrong firing order. I also notice that most combinations turn maybe 60-100 rpm while only a few turn maybe 400, at the same pot.

Can you do some maths to figure out how fast the Fanuc codes are changing compared to the servo-thread time?

At a guess an 8-pole motor at 400 rpm is sending commutation edges at 850Hz. Which is getting a bit close to the servo thread rate.

You might find that you need a faster servo thread to use software commutation.

I set the servo thread to 2khz before I started. It is a weak atom but seems to be doing fine. A few years back I experimented increasing the servo thread speed on the atom and found it throws a realtime error if it can't keep up. I have seen no errors.

I did some more testing. I tried a twin AMC amp I had, same results. I also verified the fanuc gray code wiring with a DVM watching the pins labeled on the actual encoder header and comparing to the led's in hal "watch", all wiring is correct.

I have varied the speed from a slow crawl and see no difference, so I don't believe thread speed or bandwidth is a issue.

Tomorrow, I may pull out my oscope and have a look at the signals at a low speed, see if they are clean and somewhat square.

Some battles are more bloody than others, but I always win ! LOL

andypugh wrote:

andypugh wrote:

You might find that you need a faster servo thread to use software commutation.

Or, indeed, a hardware solution:
pico-systems.com/osc2.5/catalog/product_...opjnvljnsao5hahndcc0

I seen the pico board, but there are 4 motors on the VMC, not including a possible 4th axis, so thats a $600 + solution. I was under the impression that BLDC did the same functionality. A faster computer is in the plans for the actual retrofit after the servo setup is bench proven.

If it turns out BLDC just cannot run a redcap, then the pico might be the only option. A new encoder w/halls isn't much different in price and more work.

andypugh wrote:

gmouer wrote:

I seen the pico board, but there are 4 motors on the VMC, not including a possible 4th axis, so thats a $600 + solution. I was under the impression that BLDC did the same functionality. .

So was I, it is certainly meant to do the same job. One problem is that I have never had a red-cap to experiment with. Most of the practical development was in JS's motors.

I assume you are in the US? If you were anywhere nearer 0 longitude I would be thinking in terms of you posting me a motor and drive to check the component with.

Yes Andy, I am in the US, South Carolina to be exact.

I have been thinking this all over this morning and have a question. That whole math problem of taking the 4 fanuc gray codes and generating 3 hall signals, why would the same problem not exist for fanuc? I am reasoning (probaby wrong) that fanuc has to take those same 4 bits and generate 3 phases of drive to the motor. Its not hall signals fanuc generates granted but it still somehow goes to generate 3 phases of motor drive in a given pattern. I suppose it is possible that fanuc could switch to using the encoder in the process but I doubt it, the 4 bit code would be more complicated than necessary.

Also, I tried another AMC drive last night, a twin, with the same results. I also verified the fanuc 4 bit code wiring with a DVM right at the encoder pcb on the marked terminals while watching the "watch hal" led's follow those lines. It would have been too easy if I just had a couple 4 bit lines crossed, but I figured I had better check. I also buzzed the motor windings again, both to each other and the frame, nothing funny there, about 1.5 ohms phase-phase, infinity to the frame.

I am in contact with John Sheerin via email and in the early stages of comparing setups. He did run 60 deg setting on the drive.

Today, for lack of any other immediate idea, I plan on taking my Oscope and looking at the gray code and hall signals to see if anything looks funny there.

andypugh wrote:

gmouer wrote:

I have been thinking this all over this morning and have a question. That whole math problem of taking the 4 fanuc gray codes and generating 3 hall signals, why would the same problem not exist for fanuc?

The Fanuc drives don't use trapezoidal commutation. They use a quasi-sinusoidal commutation, where each of the 16 states has a fixed current for each phase.

I think your best option is to use the "rough" Fanuc to Hall until the first encoder index, then let the component switch to using the encoder counts to generate the Hall signals. This is actually what the Pico converter does.

I was already thinking that using the encoder would probably be the end result. I am guessing Pico would not have gone that way either if simple code conversion worked well. The same hold true for John Sheerin, he continued on to encoder derived. The process seems pretty complicated and I have not seen any guides to setting it up. Im brave though.

John sent me his hal file which is the same setup I have EXCEPT he has parport running in the base thread and BLDC running in the servo thread (1khz). I have the servo thread at 2khz on my atom and everything running in that thread.

andypugh wrote:

gmouer wrote:

I have been thinking this all over this morning and have a question. That whole math problem of taking the 4 fanuc gray codes and generating 3 hall signals, why would the same problem not exist for fanuc?

The Fanuc drives don't use trapezoidal commutation. They use a quasi-sinusoidal commutation, where each of the 16 states has a fixed current for each phase.

I think your best option is to use the "rough" Fanuc to Hall until the first encoder index, then let the component switch to using the encoder counts to generate the Hall signals. This is actually what the Pico converter does.

Andy, would what you propose be a cfg=fqiH ?? Is that a valid cfg with two input sources?

I assume that I must specify a offset for the encoder index to the first hal location for this to work?

I am going to try this as soon as I understand a bit more.

andypugh wrote:

gmouer wrote:

Andy, would what you propose be a cfg=fqiH ?? Is that a valid cfg with two input sources?

Yes, I think that works. It is a lot like the more common "qih" mode. (small-h)

I assume that I must specify a offset for the encoder index to the first hal location for this to work?

Yes, and I have no idea how to work out where that is, I am afraid. I found my optimum by successive approximation. If the motor runs at the same speed in both directions, then you have a correct number. (there may be many equally good numbers)

I was thinking of energizing the motor U phase with + with Vand W tied together to V- per your wiki to find motor zero and then looking in hal to see how many encoder counts the index is away from that point. Again, my thinking may be flawed.

I will be going out to the shop later tonight and experiment a bit. Going to try homing using fanuc gray code, then (sutomatically?) switching to the encoder and index for ongoing hall signal generation. I will know more after I try.

Thinking further, I believe I had better make the cfg=fqihHT The AMC drive only handles trapezoidal commutation, if BLDC starts trying sinusoidal output that is not going to work.