Go Back   EcoModder Forum > EcoModding > Fossil Fuel Free
Register Now
 Register Now
 


Reply  Post New Thread
 
Submit Tools LinkBack Thread Tools
Old 05-10-2018, 11:11 AM   #3241 (permalink)
PaulH
 
MPaulHolmes's Avatar
 
Join Date: Feb 2008
Location: Maricopa, AZ (sort of. Actually outside of town)
Posts: 3,832

Michael's Electric Beetle - '71 Volkswagen Superbeetle 500000
Thanks: 1,368
Thanked 1,119 Times in 734 Posts
The PI ratio was just a variable that was there for when the "auto" PI test was running. It gave a starting point for how to check a bunch of values. So, if you had the PI ratio be 100, the "run-pi-test" would do:
Kp = 100
Ki =1

Kp = 200
Ki = 2
.....

but it doesn't come into play when you are independently setting Kp and Ki. So, let's say you did this:

pi-ratio 50
kp 1000
ki 10

the variable named "pi-ratio" would still be 50, even though now Kp / Ki = 100.

The rotor time constant can vary a lot from one motor to another. The motor will run horribly if you are way off. It will run OK if you are a little off, and it will run the best if it's perfect. The "run-rotor-test" only works on an unloaded motor. I"ve only ever tested it on a bench with no transmission. If a transmission is hooked up, you man need to change the default commanded Id and Iq in the rotor test function "RunRotorTest" from
IdRefRef = 300
IqRefRef = 300
To something bigger. Those numbers just worked OK for me on a bench with a unloaded motor at maybe 60v or whatever it was I was using for the test.

If you can't get the run-rotor-test to work, you can just try guesses from 5 up to 150 (5mS up to 150mS for the rotor time constant):

rotor-time-constant 5
rotor-time-constant 6
...
rotor-time-constant 150


and see what gives the best acceleration.

Arber, does your ABZ encoder have a single index pulse per mechanical revolution, or is it 4 per mechanical revolution? That's the only difference from motor type 2 to motor type 3. One possibility is your encoder doesn't like one of the settings below:
Code:
		case PERMANENT_MAGNET_MOTOR_WITH_ENCODER:
			QEICONbits.QEIM = 0b110; 	// enable QEI x4 mode with position counter reset by INDEX pulse. 
			QEICONbits.PCDOUT = 1; 	 	// Position Counter Direction Status Output Enable (QEI logic controls state of I/O pin)
			QEICONbits.POSRES = 1;		// Position counter is reset by index pulse.	
			QEICONbits.SWPAB = savedValues2.swapAB;		// don't swap QEA and QEB inputs.  
	
			DFLTCONbits.CEID = 1; 		// Interrupts due to position count errors disabled
			DFLTCONbits.QEOUT = 1; 		// Digital filter outputs enabled.  QEA, QEB. 0 means normal pin operation.
			DFLTCONbits.QECK = 0b011; 	// clock prescaler of 16. So, QEA or QEB must be high or low for a time of 16*3 Tcy's. 
										// Fcy = 30MHz.  3*16Tcy is the minimum pulse width required for QEA or QEB to change from high to low or low to high.
										// You can do at most 30,000,000/(3*16) = ??? of those pulses per second.  So, you can have at most
										// ??? * 2 clock counts per second, since resolution has been multiplied by 2 (QEA and QEB up and down transitions all cause a pulse to be seen by the microcontroller..)  
										// 
			DFLTCONbits.IMV = 0b00;  	// INDEX pulse MUST happen when QEA & QEB is low. It didn't work for QEA being low with the Leaf motor.
			MAXCNT = (savedValues2.encoderTicks << 2) - 1; 		// If going backwards, poscnt will go from 0 to maxcnt, ONLY IF it is caused by an index pulse!!!  Multiply by 4 since I"m doing 4* the resolution.
								// Use this for the AC controller.  It's easier to measure speed of rotor with this setting, if there's no INDEX signal on the encoder.
			POSCNT = 15000;  	// It starts in an unknown state before the index pulse happens. Do this so I can know the index pulse hasn't happened yet.  It will vary from 14000 up to 16000 or whatever, and suddenly be forever trapped in [0,MAX_CNT] once the index pulse happens.
			myFirstEncoderIndexPulseTest.startTime = 0;
			myFirstEncoderIndexPulseTest.currentAngleOffset = 0;
			myFirstEncoderIndexPulseTest.testRunning = 1;
//			encoderTicksDivPolePairs = __builtin_divsd((long int)savedValues2.encoderTicks,(int)savedValues2.numberOfPolePairs);
		break;
I would try changing "DFLTCONbits.IMV = 0b00;" to
"DFLTCONbits.IMV = 0b01;", or DFLTCONbits.IMV = 0b10;, or DFLTCONbits.IMV = 0b11;
Those are the possible required states of A and B, when the index pulse happens, and I don't know what state A and B are in when the index pulse happens on your encoder, so you would just have to try them all. This is why companies pick a specific motor and specific position sensor and just make a specific controller for it. Everybody has their own standards.

__________________
kits and boards

Last edited by MPaulHolmes; 05-10-2018 at 11:47 AM..
  Reply With Quote
Alt Today
Popular topics

Other popular topics in this forum...

   
Old 05-10-2018, 01:45 PM   #3242 (permalink)
Master EcoModder
 
Join Date: Sep 2010
Location: Saskatoon, canada
Posts: 1,460

ChargE (not yet running) - '92 Mazda MX6 LX
90 day: 33.89 mpg (US)

Ford Prefect - '18 Ford F150 XLT XTR
Thanks: 741
Thanked 538 Times in 433 Posts
Quote:
Originally Posted by MPaulHolmes View Post
The PI ratio was just a variable that was there for when the "auto" PI test was running.
OK - I'll skip changing that one

Quote:
The rotor time constant can vary a lot from one motor to another. The motor will run horribly if you are way off. It will run OK if you are a little off, and it will run the best if it's perfect.
Good - so I don't have to worry about that until I get the motor to turn

Quote:
If a transmission is hooked up, you man need to change the default commanded Id and Iq in the rotor test function "RunRotorTest" from
IdRefRef = 300
IqRefRef = 300
To something bigger. Those numbers just worked OK for me on a bench with a unloaded motor at maybe 60v or whatever it was I was using for the test.
I may get to that, but likely not until the weekend

Quote:
If you can't get the run-rotor-test to work, you can just try guesses from 5 up to 150 (5mS up to 150mS for the rotor time constant):
I suspect I'll just guess, starting with what I used for the Siemens motor ... after all, it did turn with those settings ... except for the motor-type and pole-pairs!

Awesome information, as usual, Paul. Thanks

I always take video and record audio of my tests in case something interesting happens. So far, I've only shown examples of what can go wrong. My motivation for editing the video is pretty low.

When I get something to work, I'll take pictures and video. Maybe I can get motivated to edit video for initial laptop connection to the controller on serial, getting the signals for the encoder connected, get a throttle connected, get the pack connected with a pre-charge circuit, etc etc
__________________
In THEORY there is no difference between Theory and Practice
In PRACTICE there IS!
  Reply With Quote
The Following User Says Thank You to thingstodo For This Useful Post:
MPaulHolmes (05-10-2018)
Old 05-11-2018, 02:35 PM   #3243 (permalink)
Master EcoModder
 
Join Date: Sep 2010
Location: Saskatoon, canada
Posts: 1,460

ChargE (not yet running) - '92 Mazda MX6 LX
90 day: 33.89 mpg (US)

Ford Prefect - '18 Ford F150 XLT XTR
Thanks: 741
Thanked 538 Times in 433 Posts
Update for May 10

See attached log for the morbid details, but here's the summary

Changed motor type to 1 and pole-pairs to 1

Started with kp = 30000 and ki=600

Run-pi-test2 and then cut kp and ki in about half. Rinse and repeat

At the end, turn off the 48V pack, bleed off the capacitor, then re-run the last run-pi-test2

They are not identical but they are very close. I guess I broke the power stage?

Is there a test I can run to drive the IGBTs without having pack power on? Is it faster or easier to load in the firmware to run it as a house inverter? I am trying to figure out if I somehow damaged the electronics, or the high power section, or perhaps the firmware is assuming a hardware mod I don't have ...
Attached Files
File Type: zip 18may10_1.zip (3.1 KB, 18 views)
__________________
In THEORY there is no difference between Theory and Practice
In PRACTICE there IS!
  Reply With Quote
Old 05-12-2018, 11:49 AM   #3244 (permalink)
Somewhat crazed
 
Piotrsko's Avatar
 
Join Date: Sep 2013
Location: 1826 miles WSW of Normal
Posts: 1,565
Thanks: 153
Thanked 425 Times in 361 Posts
Based on what I observe over on some of the other power forums I stalk, you have probably fried the power transistors and probably also the drivers.

Isn't there some snubber diode across the igbt to sink the back emf?

From what I recall igbt failure mode is generally shorted on. Theory says the gate becomes damaged.

My experience is that it doesn't take long to crispy the weakest part reverse biased.

I believe if you powered up the controls with 12v, and spun the encoder/ motor by hand, an ohmmeter could be used accross the phases and battery ground to show a decrease in resistance when the thing switch on. I am guessing you already checked that you were getting switched voltages on any pair of motor leads. This is where a scope would be handy, but I have done it with a analog simpson set to whatever the battery pack max is.
  Reply With Quote
Old 05-14-2018, 12:40 PM   #3245 (permalink)
PaulH
 
MPaulHolmes's Avatar
 
Join Date: Feb 2008
Location: Maricopa, AZ (sort of. Actually outside of town)
Posts: 3,832

Michael's Electric Beetle - '71 Volkswagen Superbeetle 500000
Thanks: 1,368
Thanked 1,119 Times in 734 Posts
These IGBTs have the diodes inside from emitter to collector for each IGBT. There was not a continuous massive amount of current when B+ and B- were reversed, so that makes me think maybe they gracefully failed opened? There are several little thin wires (like 28 awg or something) inside the IGBTs that are floating in a gel, which connect to the collector and to the emitter tabs. I think they are designed to act as fuses. I would be interested in seeing the inside of the IGBTs. They have tiny screws in them, and then the little plastic top can pop right off, or you might need to bend the metal tabs first for the plastic top to be removed. My guess is that some of those little thin wires have failed opened, but I don't know for sure.
__________________
kits and boards
  Reply With Quote
Old 05-14-2018, 02:59 PM   #3246 (permalink)
Master EcoModder
 
Join Date: Sep 2010
Location: Saskatoon, canada
Posts: 1,460

ChargE (not yet running) - '92 Mazda MX6 LX
90 day: 33.89 mpg (US)

Ford Prefect - '18 Ford F150 XLT XTR
Thanks: 741
Thanked 538 Times in 433 Posts
Quote:
Originally Posted by MPaulHolmes View Post
These IGBTs have the diodes inside from emitter to collector for each IGBT. There was not a continuous massive amount of current when B+ and B- were reversed, so that makes me think maybe they gracefully failed opened? There are several little thin wires (like 28 awg or something) inside the IGBTs that are floating in a gel, which connect to the collector and to the emitter tabs. I think they are designed to act as fuses. I would be interested in seeing the inside of the IGBTs. They have tiny screws in them, and then the little plastic top can pop right off, or you might need to bend the metal tabs first for the plastic top to be removed. My guess is that some of those little thin wires have failed opened, but I don't know for sure.
The weather is nice, and projects are calling ... this post-mortem may not get done until it's cold outside.

Even though I *REALLY* want to know what failed!
__________________
In THEORY there is no difference between Theory and Practice
In PRACTICE there IS!
  Reply With Quote
Old 05-14-2018, 03:25 PM   #3247 (permalink)
EcoModding Lurker
 
Join Date: Mar 2018
Location: Sacramento, CA
Posts: 17
Thanks: 9
Thanked 4 Times in 4 Posts
I was able to get everything wired and powered up, so I got some testing done yesterday evening for results to analyze this morning. I started with kp=5000 ki=100, then moved on to kp=10,000 ki=200 and went back to kp=3000 ki=50. I collected the data and tried the different K values before plotting it, so at the time I wasn't aware I should try higher values. I'll try kp=15000, 20000, 25000, etc later today

I did notice that 'run-pi-test2' would take a few tries to get usable data; often it would only return slight dips or a near-constant flat line. These plots are made from an average (6-9 runs out of ~20 for each setting) of the usable data for its respectable setting
Attached Thumbnails
Click image for larger version

Name:	Overview.jpg
Views:	32
Size:	22.3 KB
ID:	24183  
  Reply With Quote
The Following User Says Thank You to wootwootman For This Useful Post:
MPaulHolmes (05-14-2018)
Old 05-14-2018, 09:19 PM   #3248 (permalink)
PaulH
 
MPaulHolmes's Avatar
 
Join Date: Feb 2008
Location: Maricopa, AZ (sort of. Actually outside of town)
Posts: 3,832

Michael's Electric Beetle - '71 Volkswagen Superbeetle 500000
Thanks: 1,368
Thanked 1,119 Times in 734 Posts
what motor do you have again wootwootman? And what voltage are you running this test at?
__________________
kits and boards
  Reply With Quote
Old 05-15-2018, 12:09 AM   #3249 (permalink)
EcoModding Lurker
 
Join Date: Mar 2018
Location: Sacramento, CA
Posts: 17
Thanks: 9
Thanked 4 Times in 4 Posts
Quote:
Originally Posted by MPaulHolmes View Post
what motor do you have again wootwootman? And what voltage are you running this test at?
It's a 2013 Leaf motor with a 13S Lipo (48V nominal, 54.6V peak) pack made from C-Max cells. I'm planning on eventually using the rest of the cells in my pack to bring the total to 38S (140.6V nominal, 159.6V peak)

Along with changing kp, I've also noticed a difference in changing the kp/ki ratio. In the attached pic, four usable results were averaged for ki=400 and six for ki=322. It seems going from the suggested ~60 (ki=322) to 50 (ki=400) works faster. I'll stick with this ratio and keep raising kp

EDIT: Added some kp=30,000 results. Wondering what the deal is with the occasional undershoot, it might've effected my previous average plots. Or are those undershoot-ing results the ones I'm supposed to be looking for?
Attached Thumbnails
Click image for larger version

Name:	Capture.jpg
Views:	17
Size:	24.0 KB
ID:	24190   Click image for larger version

Name:	Capture2.jpg
Views:	22
Size:	59.4 KB
ID:	24193  

Last edited by wootwootman; 05-15-2018 at 01:02 AM..
  Reply With Quote
The Following User Says Thank You to wootwootman For This Useful Post:
MPaulHolmes (05-15-2018)
Old 05-15-2018, 01:52 AM   #3250 (permalink)
PaulH
 
MPaulHolmes's Avatar
 
Join Date: Feb 2008
Location: Maricopa, AZ (sort of. Actually outside of town)
Posts: 3,832

Michael's Electric Beetle - '71 Volkswagen Superbeetle 500000
Thanks: 1,368
Thanked 1,119 Times in 734 Posts
It's OK to err on the side of gentler convergence rather than most harsh convergence. Any undershoot means that it's too aggressive, and the Kp and Ki should be reduced some.

__________________
kits and boards
  Reply With Quote
Reply  Post New Thread


Thread Tools


Similar Threads
Thread Thread Starter Forum Replies Last Post
Paul & Sabrina's cheap DIY 144v motor controller MPaulHolmes Open ReVolt: open source DC motor controller 7342 02-21-2021 10:03 PM
Paul & Sabrina's Cheap EV Conversion MPaulHolmes Fossil Fuel Free 542 11-12-2016 10:09 PM
Contest! Name Paul & Sabrina's controller MetroMPG Forum News & Feedback 120 10-22-2011 02:59 PM



Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2021, vBulletin Solutions Inc.
Content Relevant URLs by vBSEO 3.5.2
All content copyright EcoModder.com