BLDC and fanuc redcap parameter problems?

Does not seem different with fanuc gray codes routed through inverted input. Motor runs identical also.
( I attached to the -not pin of C1-C8 in BLDC first try, same results, so I tried -not of the parport instead)

Hal file attached

So there the -not is not a valid pin for bldc C1-C8 then? It did not crash.

I will experiment right now. I will include a intentional syntax error in hal to prompt a intentional crash. That should verify I have the active hal file at least.

More results in a minute

You were correct, it was not the active hall file !!! I configured the launcher wrong. I fixed that and confirmed I am working with the active hall file now. Sorry about that.

Using the -not option on the BLDC C1-8 pins does indeed cause a crash, so I reverted to using the -not on the parport input pins. The halscope hall signals now look proper for standard hall commutation !! The motor runs much faster but not very smooth. Now that I have a good commutation pattern, its time to try different hall sequence patterns for smoother running. Agree?

I seem to have also lost velocity control, acting like a run away condition. Went back and removed the -not pin change and fine speed control returned. Something strange there but the commutation pattern looks more like it.

addl info

Switched to pattern 25 which cured run away type condition and restored fine speed control. Of interest is that motor runs considerably smoother in one direction vs the other. In the smooth direction it is the best yet by far.

Need to try all the patterns.

Update: Pattern 17 is the winner, great torque both directions, velocity loop in drive maintaining speed under load changes, behaves the same in both directions of rotation, speeds up well. Only complaint is cogging sound is quite apparent but no doubt that is because of 16/3 problem yielding slightly imperfect commutation.

I believe this is probably as good as it will get using straight code conversion mode. Time to move on now to encoder derived commutation I believe.

Comments?

andypugh wrote:

gmouer wrote:

Of interest is that motor runs considerably smoother in one direction vs the other. .

That is slightly strange.

Do the Hall patterns look similar in both directions?

Check my edit of the post above, switching patterns cured that.

I am running the encoder into linuxcnc through a mesa 5i25/7i77 combo so no speed problems there. The parport and the atom computer (2khz servo thread set) are the limiting factors. The parport only handles the fanuc code input and hall output signals to the drive.

I think as long as I keep the motor rpm's down at reasonable levels I should be ok for this bench test setup. After proven, suitable mesa hardware will handle the commutation chores.


Quitting for the night while I am winning. Thanks much Andy ! To be continued.

Started setting up a new ini and hal file for using the encoder for commutation. I have a few questions.

is mode fiqHT valid ? I think we discussed this before, should home using gray code conversion to hall signals then switch to encoder generated commutation. (see note at bottom of this post)

parameter bldc.0.scale my encoder is 3000 line, do I setp this for 6000 allowing for quadrature?

bldc.0.encoder-offset no idea where to start so I set it for zero with setp

I left bldc.0.output-pattern set at 17 which worked well in straight code conversion mode

bldc.0.pattern confuses me ! I assumed this would be the pattern output after the homing process but setting it throws a error in the mode fiqHT that I am testing. No such parameter

Lastly, I assume I have to pull the init pin true and release it once the motor is turning in code conversion mode?

I attached my prelim hal file in case you see anything wrong or missing.

Note: I tested this config quickly, it appears to remain running in code conversion mode, init-done does not change and nothing appears to happen toggling the init pin. Motor continues running exactly as it did in code conv mode.

Thanks!