[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

[TomKerekes]

Franc2es,

I'm not sure I fully understand, but if you have a working servo and you wish for it to move the opposite direction you will need to reverse both the input and the output. If you only reverse one or the other there will be positive feedback instead of negative feedback and the axis will run away.

So when reversing the Analog input also reverse the output drive by changing the connection to drive the channel 2 (Z axis) by changing:

ch2->Dest -= ch3->Output; // move ch2 at speed of ch3 output

to

ch2->Dest += ch3->Output; // move ch2 at speed of ch3 output

Regards

[George Butty]

Hi Tom

The limits are working when running in ch3 mode using 430f. One thing I noticed is that the Dest count for ch3 and ch2 in the axis screen does not stop counting after the switches are hit. I am assuming that should not happen.
Also the + sign change for the // move ch2 at speed of ch3 output direction solved the problem.

On a side note. Could you give me a better explanation of how your Persit.UserData[ ] funtion works. Aslo how it corralates to NotifyPlugins ( ).
I find it confusing and I cant find a good explination for it.

Thanks

George

[TomKerekes]

Hi George,

Good. The numbers keep counting because you (heh heh), your program keeps adding to the Dest regardless. It shouldn't matter because the motor is disabled anyway. But to stop it add the axis enables as a condition such as:

if (ch2->Enable && ch3->Enable)
ch2->Dest -= ch3->Output; // move ch2 at speed of ch3 output

The persist.UserData[] array is just a global array of 200 general purpose 32-bit variables where KFLOP threads and the PC can share data and communicate.

Special NotifyPlugin() message ranges have been set aside to move 64-bit double prescision values between KFLOP and Mach3. It is a bit tricky because a 64-bit Mach3 DRO values must be placed into a pair of 32-bit User Data variables. Here is an example that takes a Mach3 DRO, sends it to a KFLOP UserData pair of Variables, KFLOP reads, adds a number to it, and places it into a different UserData pair, then Mach3 Uploads it to an different DRO for a full round trip test.

Mach3 Plugin Passing DROs

Here is a more complex example for rigid tapping in Mach3. A number of parameters are sent to KFLOP to define how do the Rigid tapping operation, and the result is uploaded to know when it is complete.

Mach3 Rigid Tapping


HTH
TK

[George Butty]

Hi Tom

Happy New Year. I have been working on finnishing my machine and I am getting very close. If you rememer I had a tough time getting my Brushless motors to start without over currenting and then I had trouble getting the controller to find the index pulse for setting the comutation for the motors. I put a scope on the control line and found that I have a large amount of noise onthe lines and this noise is coming from your snapamps. At this time the machine will start most of the time and run well but I will have to figure out ways to get the noise down since my index pulse is only a TTL 5 volt signal and its not to happy with the mess in the line.
Anyways I ran into another strange problem with the negative 0 axis limit switch. I have the switches set to "Disallow drive into limit". The axis comes to a stop but I cannot get the axis to come off the switch even after reloading the int.c program. This only happens on the 0 axis negative switch. All other switches behave fine. If the axis is on the switch and I reload the int.c file, it enables the axis and then disable it. If I enable it in the axis screen, it will come off the switch but I loose control of the axis as it moves in the positive direction. I have to stop the axis using the stop command and once the axis is off the switch it will reset once I reload the int.c file. If you remember you updated the drivers for me to version 430f because we were having limit switch problems running in the dual loop mode. Any idea's.

George

[TomKerekes]

Hi George,

Happy New Year to You.

Yes you will need to get rid of the Z index noise. Do you have Shielded Encoder cables? Shielded Motor Cables? Where is it connected? Any Termination resistance? Maybe add a small ceramic filter cap?

I'm having a bit of trouble following what is happening with the limits. I believe your Axis 0 is a Brushless Servo without any Slave or Dual Loop being involved. Correct?

When you run the Init.c sequence it "Enables and Disables". What do you mean by that? Anything printed on the Console? The Init.c program will rotate the motor to do the phase find. Does that happen properly?

Maybe Post your latest Init.c program.

Regards

[TomKerekes]

Hi George,

I think attaching files to cnczone works similar to the way it did before. Manage Attachments, upload the file, then attach. I think bitmap images must be smaller than 1000x1000 pixels or it will reject them.

Regards

[George Butty]

Hi Tom

Sorry for confusion. I do have the resistors across + and - on the diferential inputs. I will add caps across them as well. I have caps going to ground on the z pulse signal which is connected to one of the opto inputs. I am not using the third differential signal input. Would there be any advantage to connect to the 3rd differential input instead? The shielding is connected very close to the way you suggested and the sheilding is only connected at the control box end to avoid ground loops.

I will play with the scope to see if I get different readings as you explained.

The inductance for the larger motors is .795 mH and I have attached the step data for Ch0. Look at the axis current VS. time plot and see what you think? Is it norrmal to look that ugly? You can see the current is going + and - 10 to 12 amps.

Thanks
George

[TomKerekes]

Hi George,

Regarding the shielding: I'm not sure I understand, but it sounds much different than I described. If you have both the Encoder and Motor Shields tied together at the Control Box then you might be using the motor shield to collect all the motor noise and feed it directly into the encoder shield and into the encoder signals. I think it would be better to dump all the Motor noise into some far away earth ground. Then connect the Encoder shield to a relatively quiet KFLOP DC ground.

Regarding connecting the Z index to a differential input: The opto should work and actually provide some additional filtering as they are relatively slow devices. You would need a differential signal to connect it to a differential input.

I think we want to be careful to keep problems separated. The only purpose of the Z index pulse is to be used one time in phase finding to set the commutation angle. That should be obvious if it didn't work. The motor won't move right and if you command to position zero the shaft angle would be visibly in the wrong position. A sudden jump in the encoder reading later on causing a current fault is something entirely different.

I don't think the currents are that unusual. You can't see the current ripple caused by the low Inductance because KFLOP Servo Samples one point every 90us. The PWM cycles about every 32us. You would need a current probe and an oscilloscope. The large variation is caused by several things. First of all to generate say 10Amps of constant torque while moving the 3 individual phases will all be cycling plus and minus which is perfectly normal. Another issue is that your high D Gain generates spikes in the commanded output for each encoder step. So the commanded current is fluctuating a lot. I don't think you have a low pass filter. If you add something like a 2nd order Low pass filter of 1000Hz Q=1.4 to the 3rd IIR Filter is should smooth out the spikes somewhat. But I don't think this is a big problem as it is.

Regards

[George Butty]

Hi Tom

I have been running my machine for the last few weeks and it is running reasonably well. I still do have starting problems but after two three restarts it work well for the day. I am quit sure that this problem is a noise issue and I will get back to that after I get a few other issues out of the way. At this moment I am working on customizing the Mach screen for my machine. Just wondering if there is a way to get Mach to toggle a button on/off using the NotifyPlugin values. I managed to get a button to set a bit in Kmotion but I can't figure out how to get the same button to toggle so it clears the same bit. Is this possible?

George

[George Butty]

Hi Tom

My machine is still limping away. Unfortunately I am still have staring problems. I put a serious effort into looking for the problem and I did make some very good improvements. I f you recall , the index pulse from the Tecknic motor was a low voltage TTL signal. You were convinced that the noise coming in the line was the problem for not finding the index pulse consistently. So I converted that signal to a differential signal and connected it to your differential input . With a scope connected to the signal , I got a very clean index pulse coming in on two of the axis and for some reason the third axis had a strange random pulse emitting from it. After many hours of searching , I decide to interchange the motor with the other axis to see if it was an encoder or wiring problem. The problem shifted to the other axis so from this I found that the bad encoder turns out to be the discontinued version sold by Tecknic. . I will be changing that motor soon as it comes in. At this point the machine does run but I also ran into another problem. When I changed the index pulse single I thought I would rerun the commutation offset program again to see if I would get different values for the CO. For some reason and I don't now why, the 2 ohm 25 watt load resistor burned out. Somehow I may have got out of the commutation offset program and the power did not shut off. This happened to ch0 and ch2. I lost both resistors. The unit still works so I thought I just fried the resister. Today I replaced both resistors and they both burned out soon as I powered the unit up. Any idea what happened? As I said the drives are still running without those resistors.

George