[George Butty]

Hi Tom

Got AutoPhaseFind to work for channel 0 and 1. Ran step responce for both channels and could only get channel 1 to run with with the move comand. Checked values in AutoPhaseFind and ran for channel 0 again with no luck.
Any sugestions.

Thanks
George Butty

[TomKerekes]

Hi George,

I assume you are trying to commutate brushless motors and then get them to servo.

Let's start with only one motor at a time.

What are the results from the AutoPhaseFind.c ?

The AutoPhaseFind.c only prints out the important parameters for your motor. You will then need to apply those parameters to your axis channel for it to commutate properly. The main parameters to do the commutation are the invDistPerCycle and the CommutationOffset.

There is another example program called HomeBrushless.c that can be used to initialize the encoder to commutate properly after the parameters for your motor are known.

Regards

[George Butty]

Hi Tom

The values I got from running AutoPhaseFind are
ch0 counts/rev = 4000
counts/cycle= 997 rounded to 1000
invDistPerCycle = .001000
Commutation offset = 418
input Gain Specified = -1.00

ch1 counts/rev =3999
counts/cycle =1002 rounded 1000
InvdistPerCycle = .001000
Commutation offset 1002
input Gain Specified -1.00

Should the values be the same for each channel?
What I find strange is, when I run autofind for ch 1 it will run with the move command in the Step Response section. I did nothing with the values that where generated by autofind. I do the same for ch0 and nothing happens
on ch 0. I did flash the unit and I am wondering if I unknowingly enter some data that gets ch1 to run when the move command is activated in step responce. How can I check what is flashed to the controller or reset it to default conditions?

GB

[TomKerekes]

Hi George,

Yes everything wired the same and configured the same then the results should be the same. But let's start with one motor at a time.

There isn't a way to read back what you flashed into the board. We don't recommend you do this. There is no benefit for you to do this. It is more straightforward to just configure everything each time with a C program. You can restore the default configuration be re-Flashing "New Version".

It would be helpful if you provide more details on what you are doing. As I described in the last email a HomeBrushless.c program should be used to align the commutation to make the motor ready to servo. But an AutoPhaseFind.c will also do a similar thing. The goal is to be able to power up, run HomeBrushless.c to align the commutation and enable the servo, then make a move. If you post plots of when you make a move we will be able to tell what is happening.

Regards

[George Butty]

Hi Tom

I am making a 5x10 plasma cutting table with a THC. The two main axis are run with the same motor and the THC will also be running with a smaller brushless.
I have all the mechanical components complete and installed and am working on getting the drives running. At this point the only things I dont have installed are the end limits which it looks like I should do next. I have previous experience with servo systems but nothing that ran C logic, so the start is a little slow. With a bit of patience I think I will get there.
Any ways I will re-flash the new version to get a fresh start and also see if I can get the homing.c program to work with one of the axis. Will let you know how things work out.

Thanks
George

[George Butty]

Hi Tom,

As an update, we ran the commutation program autophase.c and it's seem to provide phase information that is repeatable, this I assume indicates that the encoder/snap and amp are working.

This is the output from the program.
0 Position = 3999 PhaseAngle = 3.832000
1 Position = 7999 PhaseAngle = 7.835000
2 Position = 3999 PhaseAngle = 3.670000
3 Position = 0 PhaseAngle = -0.338000
Counts per rev = 4000
Counts per cycle = 999
Counts per cycle (rounded)= 1000
invDistPerCycle (rounded)= 0.001000000000
Commutation offset = 1002
Input Gain Specified = -1.000

We are also able to run the step response program, and the plots seems good and respond to changes on the PID parameters.

Now here's the issue: still can't get the axis to jog. Are the parameters in the step response dialog stored to the KLOP as they are changed, or do they need to be set somewhere else, possibly the homing program?

Please advise what you would suggest.

[TomKerekes]

Hi George,

That is good progress. When you press "Move" on the Step Response Screen the parameters from the screens are downloaded to the KFLOP working parameters. But if you just change the parameters on the Screens this has no immediate effect on what KFLOP is using. There is a Flash video that helps understand the various ways to set parameters in KFLOP.

See here

Regards
TK

[George Butty]

Thanks Tom

Got the Y axis running in jog mode and move mode. Now to the X axis.

George

[George Butty]

Hi Tom

Back working on my project. I managed to get all three axis working with the brushless motors. Jogging and moving with all three axis in the console screen. I have a few questions.

1) I ran the autophase program for each axis to get the invDistPercycle value and the Commutation offset value to insert into the HomeBrushless program for system startup. These are the values I got from the autophase program.

Mon, Aug 20, 2012, 03:20:12 KMotion Program Started

Starting
Index found
Index found
Index found
Index found

REPORT
------
0 Position = 3964 PhaseAngle = 4.214000
1 Position = 7965 PhaseAngle = 8.224000
2 Position = 3965 PhaseAngle = 4.127000
3 Position = -34 PhaseAngle = 0.116000
Counts per rev = 4001
Counts per cycle = 998
Counts per cycle (rounded)= 1000
invDistPerCycle (rounded)= 0.001000000000
Commutation offset = 425
Input Gain Specified = -1.000

Starting
Index found
Index found
Index found
Index found

REPORT
------
0 Position = 3987 PhaseAngle = 3.790000
1 Position = 7988 PhaseAngle = 7.790000
2 Position = 3987 PhaseAngle = 3.718000
3 Position = -12 PhaseAngle = -0.285000
Counts per rev = 4001
Counts per cycle = 1000
Counts per cycle (rounded)= 1000
invDistPerCycle (rounded)= 0.001000000000
Commutation offset = 1004
Input Gain Specified = -1.000

Starting
Index found
Index found
Index found
Index found

REPORT
------
0 Position = 3092 PhaseAngle = 3.184000
1 Position = 7092 PhaseAngle = 7.184000
2 Position = 3094 PhaseAngle = 3.135000
3 Position = -907 PhaseAngle = -0.867000
Counts per rev = 4000
Counts per cycle = 1000
Counts per cycle (rounded)= 1000
invDistPerCycle (rounded)= 0.001000000000
Commutation offset = 409
Input Gain Specified = -1.000

All the motors have then same physical setup and if you look at the invDisPerCyle, all the values are the same. For some reason the Commutation offset value is close to the same for two motors ( 425, 409) and the last motor runs around 1000. Any idea of why the differance? Machine runs with these settings.

2)What does the irr[0].B0=1 and so on, mean in the autophase program?

3) Sometimes when I run the autophase program, it finds the index pulse and stops running. The overload light comes on and I get a ticking sound from that axis. I stop the program, compile, reload and run the same program without changing anything and it works fine. Any ideas on that?

4) Is there a clear screen comand for the console screen. Right click (select all) does not work for some reason and the only way I can clear the screen is to restart the program or select with high lite scroll and delete which is a pain when the console sceen is long.

Thanks

GB

[TomKerekes]

Hi George,

1- The reports all look very reasonable. I don’t know why the commutation offset is different for the one motor. Possibilities are that the motor phases are wired differently or that the index pulse on the encoder is physically different relative to the rotor position on that motor for some reason.

Or there might be some asymmetric load on that motor. The technique that the AutoPhase find uses is that it rotates magnetic field to move the motor much like a stepper motor moves. The assumption is that the motor rotor will move and stay aligned to the magnetic field. Under no load and with no friction this will be exactly correct. But with friction for example the rotor will lag behind by some amount and there will be an error. The AutoPhase find moves through the index pulse going both directions and averages the results to attempt to eliminate the error due to something like friction. But if the load is always pulling one way (i.e. gravity) then the error will not cancel out. But I wouldn’t expect this type of error to be as large as the 425 -> 1004 like you observe. BTW moving the commutation offset one complete commutation cycle will have no effect so a commutation offset of 1004 is the same as 4.

Also once the commutation is working well enough to servo then you can use the Step Response Screen to test and optimize it further. Make a fairly big move of a few cycles and observe the smoothness and current required. Then tweak the commutation offset a bit and observe if things get better or worse.

2 – I didn’t think the IIR coefficients are normally set in the AutoPhaseFind.c program. But those coefficients are for the 2nd order Z-domain filters to do things like low pass filter, notch filter, lead/lag, etc… With the B0 coefficient set at 1 and all others 0 the filter has a flat gain of 1.

3 – possibly the peak current limit you have selected is close to the current you are using in the Auto Phase Find. The tick-tick-tick is caused by constantly hitting the peak current limit, faulting, delay, then it attempts to re-enable.

4 – there isn't a clear screen button. The Console Screen is meant to be logged to the LogFile.txt file. CTRL-Home, CTRL-SHIFT_END, DEL should clear the screen.
Regards

[George Butty]

Hi Tom

All the axis will work in servo mode. They will move nicley at high speeds and will accel and decel to programed positions.

I do not have any gravity loads on the machine so I don't think that is an issue. It may be possible that the wiring may not be the same for all the motors. I will check them.

Mean while I will spend more time on tuning and playing with the current limits to see if that helps.


Thanks

George

[George Butty]

Also Tom, what are the allowable value range for the current limit?

thanks

GB

[George Butty]

Hi Tom

I am try to set up the start up programs to initialize the machine running the brushless DC motors. I am modifiying the homebrushlesSnap program to to this. I have no problems with ch0 and ch1 on snap0 but for some reason I can't get ch2 to move on snap1. Hear is a copy of the initializing program I am trying to run. It is the basic move program to get the motor too find the index pulse. The program sets the current limits on the controller but the moter will not move. It is free to turn by hand. If I change outputchan1 too 2,
then the motor locks up but does not turn to find the index pulse. This same format works fine for the other two axis. Any idea's

George

#include "KMotionDef.h"

main()
{
float k=0,A=10.0f; // set coil current amplitude PWM units
double p0;

WriteSnapAmp(SNAP1+SNAP_SUPPLY_CLAMP0 ,SNAP_CONVERT_VOLTS_TO_ADC(70.0));
WriteSnapAmp(SNAP1+SNAP_SUPPLY_CLAMP1 ,SNAP_CONVERT_VOLTS_TO_ADC(70.0));

WriteSnapAmp(SNAP1+SNAP_SUPPLY_CLAMP_ENA0,1);
WriteSnapAmp(SNAP1+SNAP_SUPPLY_CLAMP_ENA1,1);

WriteSnapAmp(SNAP1+SNAP_PEAK_CUR_LIMIT0,14); // current limit
WriteSnapAmp(SNAP1+SNAP_PEAK_CUR_LIMIT1,14); // current limit

Delay_sec(1); // wait for any fault to clear

// rotate until we find the index mark

ch2->Enable=FALSE;
ch2->OutputChan1=12;
for (;
{
Delay_sec(0.001); // wait a millisecond

Write3PH(ch2,A, ++k/1000.0); // move the pole

if (ReadBit(104)) // check for index mark

p0=ch2->Position; // save position
ch2->Position=0; // set current position to Zero

// set commutation offset to 1/4th of a cycle
// encoder has 4000 counts/rev
// motor has 3 cycles per rev

ch2->CommutationOffset = 405; //3*8000/2.0/12.0 * 1.02

printf("Position = %f\n",p0);
break;
}

}

[George Butty]

Sorry, Outputchan1 to 0 (not 2)

[TomKerekes]

Hi George,

For Brushless 3 phase motors there is just one output device used which is specified by OutputChan0 (OutputChan1 is unused).

Side A of the 2nd Snap Amp consists of Full Bridge Drivers 12 and 13. These are used as a pair to form a 3 phase driver. Only a single number is required to define this.

So try setting:

ch2->OutputChan0=12

Regards

[George Butty]

I tried that and the motor would lock up but does not rotate to look for the encoder index pulse. Any idea's on this. Also how do I set the scaling factor for encoder counts to linear distance? (inches). I would like to run you Gcode files for a test.

Thanks

George

[George Butty]

Hi Tom

Got ch2 working nicely. I am still having problems when I load the HomeBrushless program. I get an overload fault when I first run the program and when I run it again without changing anything it works fine. I have the curent limits set at 11 which should be more than high enough. Do I have to increase the A=10.0f value to get more torque for initial startup. Can you tell me what the f stands for?

Also how or were do I set the scaling factor for encoder counts to linear distance so I can get true inch values to run your test Gcodes?

Thanks

George

[TomKerekes]

Hi George,

I can't think of why it would fault on the first run of the HomeBrushless.c program. But you aren't explaining what steps you are doing or what changes you have made to get it to work. Exactly what are you doing between powering up and first running the program?

Did you end up using my recommendation of:

ch2->OutputChan0=12;

??

I don't understand why you said you tried that when you had described doing something different.

The amount of voltage that is applied to the motor is determined by the:

A=10.0f;

In C a number specified like 10.0 is considered to be a double precision floating point number (64-bits with ~17digits of precision). Adding an "f" after it tells the compiler to consider it as a single precision floating point number (32-bits with about 6 digits of precision). Since A is defined as a "float" it is a 32-bit variable so the idea is to avoid any required conversion from 64 bits to 32 bits. This is considered good progamming practice to avoid any unnecesssary conversions, but in this case it wouldn't really matter if the "f" was left off.

The brushless 3 phase motor is being moved like a stepping motor. A constant voltage is being applied that causes a constant current to hold position. The current is then slowly moved through the coils to rotate the motor. There isn't really any "start up" current.

Hang in there I'm sure you will get it! Brushless servos are one of the most complex configurations.

HTH

[George Butty]

Hi Tom

Thanks for the help.

After you explained that the outputs run only in ch0 for snap1, I realized I also had them set wrong for the inputs as well. Looking back at the config settings , it is obvious that all I/O is running on ch0 for snap1. Once I set them properly, the ch2 axis worked fine. I managed to combine all three axis start up programs into one and it is working great. The only problem now is the overload issue and I think I know what thats is. Ch0 axis has a 175lbs load and I don't think there is enough torque in the stepper start sequence to over come the load. The first attempt gets the position close but overloads before it is finnished. On the second atempt, the position is close enough and it starts properly.
Is there any way to increase the torque by maybe 20% in the stepper mode. I think that should solve the problem.

Yes the brushless set up is more difficult and I thought it was just me making it that way. The only thing I can say is that this is worth it because once these motors run they do kick ass. It throws that 175 lbs around like nothing and I my power supply is only giving 57 volts. I will be changing it to 75 v once I get everything going. Can't wait.

Now to get the Gcode to work. I found that the scaling is set in the set tool options under the trajectory planner.


Thanks
George

[TomKerekes]

Hi George,

Not sure what you mean by "overload". If there isn't enough voltage applied to the motor then there won't be enough torque to overcome friction and the motor will "stall" much like a stepper motor. The motor will just vibrate or oscillate back and forth rather than progressing smoothly. In this case increase what the A variable is set at to increase the amplitude of the applied voltage. It should not be increased so much that the motor will overheat if left on indefinitely.

Regards