When I ran the AutoPhaseFind it was very helpful in getting the general setup but I found that I couldn't use the InverseDistPerCycle parameter as shown. The motor ran OK for maybe 2 or three revs but the farther it went the more current it took and the slower it went according to the Step Function test. The Inverse distance was not accurate enough.
What I did was use the values provided on the console and figure out the number of motor poles I had. These are always an integer value i.e. 4, 6, 8 etc.
Use AutoPhaseFind results in (Cts per rev / Cts per cycle) to get an idea of the motor pole count. This will probably not be an integer but from that you can figure out what the integer it should be.
You should be able to tell what the encoder counts per rev is by the motor or encoder part number to make sure the displayed value is valid.
In the example attached I have 8192 cts per rev, 2050 cts per cycle 8192/2050 = 3.996
So that means I have a 4 pole or 4 cycle motor.
Now take 8192 / 4 = 2048 actual counts per cycle
Now take the inverse of that, 1/2048 and you get .0004882 on a typical calculator. But your typical calculator will not give you enough precision.
You have 12 digits you can use in the Kflop and you need to use them all!
My IPhone scientific calculator gave me 0.000488281250
AutoPhaseFind result was 0.000487804878 and that only worked for about 4 revs.
The 12 digit IPhone result ran the motor for over 10 revs with no change in current.
Maybe the AutoPhaseFind could be smartened up in the future to take care of this but it is a very useful tool as is.
I suppose the other option is the change the commutation with Brushless motors so the counts per cycle get reset each revolution when the Zero channel or the Hall channels are seen to eliminate the need for such precision.
Best of Luck
AZ
Brushless AutoPhaseFind suggestions
Moderators: TomKerekes, dynomotion
- TomKerekes
- Posts: 2676
- Joined: Mon Dec 04, 2017 1:49 am
Re: Brushless AutoPhaseFind suggestions
Hi AZ,
You are correct. As I tried to explain in your other Thread I think the issue is AutoPhaseFind rounding to 10 instead of 16. Some encoders have powers of 10 and some powers of 2. For example 2000 counts/rev vs 2048 counts per rev. The invDistPerCyle needs to be exact so the commutation will remain correct after billions of rotations. The inDistPerCycle is a double precision number with ~17 digits of precision.
HTH
You are correct. As I tried to explain in your other Thread I think the issue is AutoPhaseFind rounding to 10 instead of 16. Some encoders have powers of 10 and some powers of 2. For example 2000 counts/rev vs 2048 counts per rev. The invDistPerCyle needs to be exact so the commutation will remain correct after billions of rotations. The inDistPerCycle is a double precision number with ~17 digits of precision.
HTH
Regards,
Tom Kerekes
Dynomotion, Inc.
Tom Kerekes
Dynomotion, Inc.