Friday, April 07, 2006

afm11 - working on multirate

back to ts_current_loop = 4e-5

WORKS

back to ts_current_loop = 2e-5

jerky again

back to ts_current_loop = 4e-5

WORKS

turned off "ensure deterministic data transfer" in the rate transition block and changed time back to 2e-5.

DNW - changed back

I had a thought that it may not be the difference, rather the magnitude. Try 2e-5 for both sample times

Wednesday, April 05, 2006

afm11 - introducing a multirate system

I want to speed up the current capture loop so that I can start averaging the output. To do that, I should first make it as efficient as possible. In the first instance, that means removing all the superfuous "to memory" blocks.

WORKS

I just discovered that I never added the DINT and EINT


add DINT and EINT later


changed to a sample time just for that block - currently the same as the global sample time.

WORKS - time to try a rate transition

WORKS - when rate transition block is installed with the rates being the same

try faster sample rate for current sense

DNW - problem with rate transition

Needed to explicitly define sample time of some input and output ports as "ts_current_sense"

DNW - compiled but motor did not turn

Changed all the ports to "ts_current_sense" and tried again with the sample times the same.

WORKS - previous may have not worked as system was on the way to a crash

Tried to change to a different sample time

DNW

discoverd that I had not changed one of the SAMPLE_TIME inputs. I may not have had to change all the -1 s to "ts_current_sense"

Sort of works. Very jerky current output is terrible



try ts_current_sense = 4e-6

DNW

afm12 - back to hystersis control

WORKS but sounds and looks terrible



try band of 50

sounds worse - looks about the same



try a band of 10

not much better - capture all three phases

phase C



phase B



phase A



I need to determine why there is no negative values of current.

I had a problem with my logic - fixed it on phase A - see below



Try for all three phases

WORKS - check different bands again

at band = 50 (setpoint = 100)

goes a bit faster, but still really noisy



I think that I should have a look at the PWM as well.

Here is the gate drive signal (low side, Phase A)



That is terrible - I need to look into that one further!!

time to go for a walk with Aya.

afm13 - pid control with "double" variables

when I implemented hysteresis control with afm12, I needed to change some values to double. This caused problems. I need to see if I can get the PID version working with double variables.

WORKS - back to hystersis control with afm12

Tuesday, April 04, 2006

afm12 - hysteresis control

tried to change to hysteresis control but ran into problems as I needed to make some variables double.

changing the speed of the control loop

with the PI signals looking sort of okay, I need to experiment with how fast the current loop runs.

First I will change the PWM frequency to 25kHz by setting the PWM_period to 3000

PWM_frequency = 75 000 000/ PWM_period

WORKED

try matching the frequency of the PWM to the frequency of the loop

SAMPLE_TIME = 4e-5



it is on 10A per division now instead of the 20A before - looks a little worse.

Time to try hysteresis control

Hardware change

Pulled off cap that was filtering the input to the 15V regulator as it was getting very hot.

afm11 - HE current control

added block previously created in afm8

started with a setpoint of 100 and Kp of 10

turned slowly

tried with Kp = 1

did not turn at all

tried Kp = 0.5

does not turn - efforts are very low

try Kp = 1 again and check the efforts

sometimes just manages to turn: efforts are about 100, add Ki = 1 as well

WORKS pretty well - check current on current clamp.


all current clamp measurements are on phase C


here is the image from the current clamp - 20A divisions drawing a bus voltage of about 5A



it looks like it is going oscillatory - try reducing Kp to 0.5



that may be a little better - try reducing to 0.2



definetly better - try 0.1



better again, however getting a bit weak - try Ki = 2



not really any better - try speeding up the controller loop with Kp = 0.1 and Ki = 1

afm10 - 6 wire voltage control with lookup table

after the total surprise at how smoothly the 6 wire voltage control went, I need to clean it up a bit. First task is to implement a lookup table instead of the case statement.

save afm9 > working 6 wire with case statement to
afm10 > hopefully workign 6 wire with lookup table

first task was to fix the PWM output so that it is all one block with three inputs that corrspond to the efforts required in a -500 to 500 scale.

WORKS but seems to be going backwards (now anticlockwise) - check afm9

afm9 is clockwise - strange

I got some of my ports mixed arount - should work now!!

WORKS

try to implement lookup tables

DNW - just squeals

I am guessing that the problem may lie witht the fact that the commands are now "double" rather than int16.

DNW

I have checked what values I am getting
A B C
HE1: + 0 -
HE2: + - 0
HE3: - + 0
HE4: - 0 +
HE5: 0 + -
HE6: 0 + -


The Direct Lookup Table (n-D) block uses its block inputs as zero-based indices into an n-D table.

WORKS now that I have set up the lookup tables for a zero based system.

Monday, April 03, 2006

afm9 - 6 wire voltage control

save afm7 as afm9 to work on voltage control

added another PWM for module B

WORKS

check that module B works

WORKS!

6 wire block wave control

I was going in circles with the star connected, current controlled, block wave method so I think that I should go directly to the 6 wire method. Below is the diagram that was used to determine the line to line signals.



I think that XYZ = CAB, Check with previously posted sequence:

1: MNP 3: PNM 2: PMN 6: MPN 4: NPM 5: NMP - Matches.

Now I need to figure out the waveform for 6 wire control.

I think that I should look at some back emfs



From these plots, I should be able to change to 6 wire voltage control reasonably easily.

Sunday, April 02, 2006

cleaning up the model

before I can continue implementing HE current control, I need to set up the model a little better and a little more modularly.

first step is to determine which variables are global:

PWM_period = 75000/PWM_freq_kHz;

Most of the time, I will be using 30kHz, so the PWM period = 2500;

add that to the model workspace.

DNW

Unfortunatly I have had to add PWM_period to the initialisation commands of the masked block. I will do that for the time being while I work out the true function of that block.

WORKS

I have moved the PWM output block out of the other masked subsystem.

WORKS

I now have to change the PWM output so that the inputs to that block are percentage on times.

I have done that so now the inputs should be a number between 0 and 1. In doing that, i removed the need to have PWM_period in the masked initialisation.

duty_cycle_fraction = duty_cycle/100;
POS_off_time = duty_cycle_fraction;
MID_off_time = duty_cycle_fraction/2;
NEG_off_time = 1;

THE MOTOR NOW GOES BACKWARDS DRAWING A LOT OF CURRENT - SOMETHING WRONG!!

problem was NEG_off_time should have been a 0;

DID NOT SOLVE THE PROBLEM - NOT DRAWING HIGH CURRENT BUT NOT TURNING.

check working_masked_openloop.mdl

WORKS

I think that my problem was trying to pass 0.4, and 0.2 as uint16. I have multiplied by 1000 before the pass and divided by 1000 after the pass.

WORKS

Time to change "to memory" and "from memory" to double data type and change the memory location to something better.

I have changed all the data types to "double" removed the x1000, /1000 bit, change the variable names to POS_duty_fraction etc. Also changed the memory locations.

DNW - bummer

check the x1000 bit back in.

DNW

must be those memory locations - change them back to 40,41 and 42

DNW - why did I make so many changes at the same time?

Changed all the data types back to uint16. That was about the only thing left that I changed, other than changing the inititalisation and termination times from neg_off_time to 0.

DNW - draws lots of current and does not move.

I discovered that I had not changed the "from memory" blocks from double to uint16. Now the motor works in a really uneven way.

Maybe I copied one of the orders down wrong.

Here is the correct order

1: MNP
2: PMN
3: PNM
4: NPM
5: NMP
6: MPN

3 was wrong.

WORKS - time for a coffee while I decide which bit to change back first.

I am really keen to get the addresses back to correct, so I will try that first.

I saved to AFM7.mdl just to be safe and changed the addresses of A, B and C to 3F9020, 3F9021 and 3F9022.

WORKS - GOOD!


I saved to AFM8.mdl and tried to change back to "double" data types but the motor does not run smoothly.

Stuff this - back to afm7 and UINT16.

clened up the variables a bit. duty cycle is now defined as 0-1000.

AFM7 is working now so I saved it over AFM8

he current control

afm4 is working in open loop mode with the currents coming in.

I have saved that as afm5. Now that I am using the adcRegs and the PieRegs to save the high and low times, I can change the name to whatever I want.

I have removed the capture block from inside the masked open loop block and moved the 2812 setup block into the main window. - WORKS

I have moved the custom code generation blocks into the current sense block for simplicity and put the current sense block in the library. - WORKS

For some reason, the changes that I made to the addresses for A, B and C did not stay changed. I have now changed them back to what is below:

address Variable
3F9000
3F9001
3F9002 IaTimeHigh
3F9003 IaTimeLow
3F9004 IaDutyCycle
3F9005 IaPeriod
3F9006 IbTimeHigh
3F9007 IbTimeLow
3F9008 IbDutyCycle
3F9009 IbPeriod
3F900A IcTimeHigh
3F900B IcTimeLow
3F900C IcDutyCycle
3F900D IcPeriod
3F900E
3F900F
3F9010 IaFB
3F9011 IbFB
3F9012 IcFB
3F9013
3F9014
3F9015
3F9016
3F9017
3F9018
3F9019
3F901A
3F901B
3F901C
3F901D
3F901E
3F901F
3F9020 A
3F9021 B
3F9022 C

WORKS.

I have moved the hall effects to their own block that is now in the library and I have moved that block out of the masked open loop.

DID NOT WORK

There was a crash that required a close of CCS and matlab so I have tried a reset emulator and a rebuild before blaming the move of the HE block.

DOES NOT WORK

I have moved the HE block back to check but I cannot see how its movement has caused problems.

STILL DOES NOT WORK

I will try reboot just to make sure.

STILL DOES NOT WORK - WHAT HAVE I DONE.

Try afm4

WORKS - THANK GOODNESS

save afm4 as afm6 and change the current block

WORKS

change the addresses back to the correct ones in the table above.

DOES NOT WORK!! WHAT IS WRONG WITH THOSE ADDRESSES? - THEY WORKED BEFORE!!

go back to the old block in afm6

WORKS

get rid of capture block and make HE a subsystem.

WORKS

remove image and move HE block into main system

WORKS

configuration block into main system

WORKS

PWM into separate block in main system

DNW

problems as the PWM block requires variables set in the other masked block.

Saturday, April 01, 2006

current control background work

Now that I think that i have the current info getting into simulink, it is time to see if I can get other stuff working as well.

When I first dropped in the blocks from working_masked_openloop.mdl I only got a high pitched whine and the motor locking up. Thinking it that may have had something do do with the dodgy memory locations used in working_masked_openloop, I changed them to 390020, 390021, and 390022.

Those memory locations work in working masked openloop.

Try in afm4.mdl

I only added the custom code blocks but it is them that stuffs it up. Maybe the ISRs are using up too much time. I will try to comment out the actions in the ISRs.

That did not solve the problem - still whining

Try without the initialisation function:

Works - try with the ISR code back in.

Works - must be in initialisation fn. Initialise ISRs but to captures.

Works - must be to do with the capture initialisation. Put the timers back in to the capture initialisation fn.

does not work - must be a problem with the timers. Try to use timer 2 for all captures.

Works! - timer 1 must be used for the aPWM - put back in the captures and see if the current sense is working