I"m going to integrate it into the controller code (again grrrrr), so the PI test is just another one of the serial commands. It was done, but hadn't been tested yet when the laptop was stolen. So, it will sort of be something like this:
kp-id 2000 // set proportional gain for Id PI loop.
ki-id 10 // set integral gain for Id PI loop.
run-pi-test
run-pi-test will then run the motor for like 1/50 second, assuming a locked rotor. Then it will display the array of results showing
IdReference - IdFeedback
The goal is for that quantity to converge to 0. So, if it doesn't converge to zero with no oscillations, you enter a new value for kp-id and ki-id, and then run the test again.
This morning is looking little optimistic for getting it done. I hereby revise "this morning" to "this evening" (or sunday morning). small children are already impeding progress. haha. I guess 5am wasn't early enough to finish it!
I"m going to integrate it into the controller code (again grrrrr), so the PI test is just another one of the serial commands.
Great! Looking forward to it!
Quote:
So, it will sort of be something like this:
kp-id 2000 // set proportional gain for Id PI loop.
ki-id 10 // set integral gain for Id PI loop.
run-pi-test
run-pi-test will then run the motor for like 1/50 second, assuming a locked rotor. Then it will display the array of results showing
IdReference - IdFeedback
The goal is for that quantity to converge to 0. So, if it doesn't converge to zero with no oscillations, you enter a new value for kp-id and ki-id, and then run the test again.
Excellent
Quote:
This morning is looking little optimistic for getting it done. I hereby revise "this morning" to "this evening" (or sunday morning). small children are already impeding progress. haha. I guess 5am wasn't early enough to finish it!
No pressure - I'm out of town for the weekend, returning Monday so if you send the code, I can confirm that it compiles OK for me, but there will be no progress until Monday night.
I will be running it first 'unlocked' so that I see some current on the battery pack and some sort of wiggle on the rotor.
I've coupled the encoder to the motor and watched the scope traces .. they don't seem quite right when I spin (my scope's differential mode seems to be iffy .. I need to play with it a bit)
Then I can lock the rotor and continue. Not sure how far I will go with the 5 HP motor tuning.
At some point I'll move it all to the garage, where the Siemens AC motor and the Warp 9 DC motor are coupled
I don't think you will need to even lock the rotor. The motor won't have time to even try to turn in 0.02 seconds. And you won't need the encoder for the PI loop tuning. It won't hurt anything though. But don't expect it to turn at all. You may just hear an instantaneous bump or something each time you type run-pi-test. You should be able to tell from the streaming data if it is converging to zero without graphing it, but you could just cut and paste it into excel if you want.
By the way, I got my shop set up with the original AC motor that I had been using for testing, and I also got the controller that's identical to yours hooked up. I tested all the basic stuff, and I'll test out the PI loop tuning on it, and once I verified that it works, I'll send it to you. So, expect it this weekend. I'm sorry for all the delays.
Reply moved to the AC controller thread ..
No problem on the delays - we do this for FUN!
Are you posting to Github, updating the instructable, or PMing the code? I guess I could just check all of them
Loaded it tonight via PICkit 3. Power up with 12V, connected to the ACController with hyperterminal (on an XP computer)
Capture file copies text from the terminal to a text file. You open that up with notepad and copy the numbers to column A of an excel sheet. Insert a chart using column A as the source and line graph. You are hoping to see the numbers drop to 0 as quickly as possible and perhaps bounce around a bit.
You set the numbers for kp-id and ki-id each test and capture the new data. You are not looking for the numbers to wander up and down on their way down to 0. When that works, you increase ki-id from 0 to get it to converge to 0.
Capture file 1. Paul sent me some numbers that worked for him.
kp-id 4668
ki-id 0
run-pi-test
Numbers start at 259 and bounce from 243 to 274 .... oops! no high voltage turned on!
Let's try that again
Capture file 2
Starts at 290 and rings but it responds so I'll start at 2000 like the instructable says. By the way, 4668 takes a long time to get to 0 (about 200) compared to the 11 that Paul's instructable graphs show.
Capture file 3
kp-id 2000
ki-id 0
run-pi-test
2000 takes until about 184 to hit 0, WAY slower than it should. It still looks like it is ringing
Capture file 4
kp-id 1000
ki-id 0
run-pi-test
1000 takes until about 180 and still rings. Not much change halving the KP
Capture file 5
kp-id 500
ki-id 0
run-pi-test
500 takes a bit less, like maybe 174 and still rings
Capture file 6
kp-id 100
ki-id 0
run-pi-test
100 takes about 180 to get to 0
Capture file 7
kp-id 10
ki-id 0
run-pi-test
10 takes about 170 to get to 0
There is not a huge difference between the responses varying KP = 10 and KP = 4668. That is weird!
Capture file 8
kp-id 10000
ki-id 0
run-pi-test
Go the other way. 10000! This is set 8 by the way. It takes until 470 to reach 0 and still rings badly. 10000 is the worst response so far.
I can hear the short whine from the motor as the pi-test runs. And the numbers DO change, so I know something is happening. But it's almost like my current sensor is not plugged in well?
My battery pack is 36V (40.1V Open circuit) since I put the boat battery back into the boat
I'm going to get the capture files attached.
BTW - the instructable shows setting kp-iq and kd-iq instead of kp-id and ki-id. I'll try that after re-seating the current sensor plugs!
Last edited by thingstodo; 05-25-2015 at 01:10 AM..
The Following User Says Thank You to thingstodo For This Useful Post:
The current sensor cables appear to be plugged into the control board right. I removed the mounting screws for the control board, lifted the board and re-seated the 3 current sensor cables.
That does not appear to have helped.
The instructable showed setting kp-iq and kd-iq instead of kp-id and ki-id
I tried that for test 10. The results were similar to the battery pack turned off. They are also similar to kp-id 0 and ki-id 0. There was no whine from the motor.
I tried the minimum kp-id 1. test 11. There was no result and no whine. So I cycled power and tried again.
Log 12. kp-id 1 ki-id 0. There was a whine this time. 0 at about 182.
Log 13. kp-id 5 ki-id 0. 0 was reached around 158. This is the best so far but there is still *SERIOUS* ringing.
Files are attached - I don't understand!
Last edited by thingstodo; 05-25-2015 at 09:20 AM..
Reason: Made the current sensor check clearer
The Following User Says Thank You to thingstodo For This Useful Post:
OK this is good! There are a few differences between your test and the instructables test. First, you are using a LEM Hass 300-s, and are commanding 20 amps. I was commanding 5 amps I think, so the response instructables response would be a lot faster, since the current wouldn't take as long to get to 5 and it would to get to 20. Also, if you are running it at 36v, maybe the resistance of the phases are high enough so that 20 amps is barely achieveable using the 36v battery pack? What is the HP rating of your motor? I did a test on a 6.6kW (I think) motor. My guess is a higher power motor would have lower resistances, and faster convergence times.
Also, you haven't tried increasing ki-id yet. kp-id just gets you close to converging, and ki-id really drives it to zero fast. Here's what I would do next: Start at kp-id = 2000, and gradually increase ki-id (not kp-id). Start at maybe 2, and go up by 2 at a time.
Also, the oscillations you are seeing aren't really oscillations, but just noise (your noise level is perfectly acceptable). Oscillations will be clearly defined damped sine waves with a much lower frequency than the jaggedy spikes you are seeing.
OK this is good! There are a few differences between your test and the instructables test. First, you are using a LEM Hass 300-s, and are commanding 20 amps. I was commanding 5 amps I think, so the response instructables response would be a lot faster, since the current wouldn't take as long to get to 5 and it would to get to 20.
I follow so far. I guess I didn't know the parameters of the instructable test.
Quote:
Also, if you are running it at 36v, maybe the resistance of the phases are high enough so that 20 amps is barely achieveable using the 36v battery pack? What is the HP rating of your motor?
It's a 5 HP, 230V 3 phase. Full load amps is 17.5 (internet lookup but it should be close) ... so I will boost the voltage. I have a crappy little 48V pack that I can put in series to get 84V.
Quote:
I did a test on a 6.6kW (I think) motor. My guess is a higher power motor would have lower resistances, and faster convergence times.
Lower resistance and inductance - check. Obvious now that you pointed it out!
Quote:
Also, you haven't tried increasing ki-id yet.
I was looking for the drop to 0 quickly, so I did not progress to kp-id
Quote:
kp-id just gets you close to converging, and ki-id really drives it to zero fast. Here's what I would do next: Start at kp-id = 2000, and gradually increase ki-id (not kp-id). Start at maybe 2, and go up by 2 at a time.
OK - I can do that.
Quote:
Also, the oscillations you are seeing aren't really oscillations, but just noise (your noise level is perfectly acceptable). Oscillations will be clearly defined damped sine waves with a much lower frequency than the jaggedy spikes you are seeing.
OK. I guess I should capture some data to document what is acceptable and what is weird.
Last edited by thingstodo; 05-26-2015 at 03:49 PM..
Reason: correct 64V to 84V
The Following User Says Thank You to thingstodo For This Useful Post:
Ya, I changed a few things. During the instructables test, it was using a LEM Hass 50-s, with like 5 wraps around it, so it was behaving like a LEM Hass 10-s. That is 30 times more sensitive than the LEM Hass 300-s you are using. So, I figured it would be good to up the amps a bit for the test, since 1 amp is barely resolvable on a lem 300. It's probably fine to just use the 36v. It will just mean slower convergence, but that's not a big deal. Convergence is convergence. Then later, when you increase the voltage, the kp and ki you found will have to change accordingly. For example, if you tune the PI loop at 36v, and later up the voltage to 360, you will have to divide the kp and ki you found by 10 (since the voltage is now 10 times more).
I had moved some things around in the basement (disturbed my test setup), and after getting things moved back ... run-pi-test gave me the same results that I get when I forget to turn on the battery pack. Same log data as 10 and 11 from the past logs.
for reference, power up the controller, start logging on hyperterm, and type in
kp-id 2000
ki-id 0
run-pi-test
I shut everything down, started back up (contactors, breakers, controller). No change.
I shut down my laptop and restarted. No change.
I reseated the current sensor plugs, and all the rest of the plugs on the controller, just in case. No change.
I disconnected the PICkit 3 (since it's not being used anyway), disconnected the throttle and the encoder. cycled power and did
kp-id 2000
ki-id 0
run-pi-test
No change.
I plugged the throttle back in. And the encoder.
No change.
I checked the voltages on the battery pack and the 12V battery. The pack voltage is down to 38.8V Not a big deal, but a difference. The 12V battery is down to 12.5V. It's a 10 A-h lithium so I was surprised that it was that low.
I turned everything off. I added a charger to the lowest of the 12V lead cells in my pack (12.7V). I lifted the ring cap to look at the hall effect sensors. The battery connectors are pretty close to the hall effect sensors. It should not matter .. but one of them may be resting on the hall effect (not quite). I added a piece of lumber between the ring cap assembly and the three phase output terminals. Just because.
Power everything back up. The lithium 12V cell is up to 12.8V. Hmm. The battery pack is now up to 40.1V. I guess the charger added a bit to the lowest pack battery. turn on logging on hypterterm. Type in run-pi-test (forgot to set kp-id and ki-id first) ... and it WORKED! I heard the motor hum, the numbers trail down to 0 ...
So I need to isolate what changed it to working ... lifting the cap and putting in a piece of lumber seems like it would not affect the 12V battery terminal voltage. But the 12V battery voltage under load is the only thing that I measure that appears to have changed ... unless you count the battery pack raising above 40V.
BUT - it's working! So I need to get Paul's suggestions tested!
The Following User Says Thank You to thingstodo For This Useful Post: