# Building Sepex Motor Controller From Scratch



## DDDvvv (Apr 2, 2012)

Welcome to the forum.

I just read your ideas and a couple of points jumped out.

Using your longest conductor as a current shunt: 

Its been determined that temperature rise on that conductor will vary its resistance. Not a very accurate method. May I suggest a dedicated current sensor. This guy sells them for dirt cheap; http://www.ebay.com/itm/LEM-300-AMP...586?pt=LH_DefaultDomain_0&hash=item2eb06a085a . This will measure +/- 300 amps and can go upto 900 amps. You get more accuracy, and great isolation.

Uc37322 mosfet drivers:

Looks like you dont plan on any sort of isolation between high voltage and control section. Direct coupling the control microcontroller to the high voltage outputs might zap it, and even take out your debugging computer, incase of a catastrophic event.

May the diy spirit be with you.


----------



## major (Apr 4, 2008)

Hi Mar,

There have been several threads about SepEx motors and controls, some involving hacked type control. Take a search or two on the forum tool and you might find some things of interest. Here are a few suggestions.

Get your system built and running under manual control before spending spending loads of time perfecting your automatic control logic. I imagine it will be different than you envision.

Start with a fixed field excitation. Just use armature voltage control with current limit. Once that is working properly, start manually adjusting the field and measure response. 

If you want regeneration, drop the FWD in the armature chopper and use a half bridge. 

Good luck,

major


----------



## kennybobby (Aug 10, 2012)

Sounds like a fun project, hopefully you can get some school project credits for this also. Have you tried putting low voltage to the motor just to get some motion?


----------



## Qer (May 7, 2008)

Some opinions based on my personal experience:



32 kB flash SOUNDS like much. It isn't. You WILL run out of space.
328 is an old AVR family. Skip it.
Don't use anything that can't handle divisions in hardware, like the AVR...
Really, lose the whole 8-bit MCU world. Go modern, go 32-bit, go ARM.
Write code that is abstracted into well structured layers with many small, readable and well defined/documented software routines.
Comment the code, document everything, even things that seems obvious now. It won't be some months later.
Use meaningful variable names instead of things like "c" for current, "i" for a counter etc, use motor_current, counter, table_index etc.
Really, make sure to write clean, well structured code because over the months you WILL forget what the oldest parts of the software did and how it worked.
You REALLY don't want to have to rediscover your old code to figure it out later! Write good documentation for yourself.
Learn to use unit tests, like gtest. Use it for all critical parts of the software.
Expect several hundred hours development time just to get something that works at all. Expect thousands of hours to get something that's useful.
Expect to blow up hundreds of dollars in blown up hardware because of mistakes in the hardware design.
Expect to blow up some more hundreds of dollars in hardware because of fatal software bugs (guess how I know this...).
Write more unit tests to force yourself to blow up hardware in new, interesting ways in the future instead of repeating old mistakes.
Expect to rewrite all the software at least once before the design is good enough to be let out of the garage.
Don't use TO220 for anything that is supposed to handle high current. Yes, I know what the data sheets say, it's still a bad idea. Especially if you aim at 1kA peak.
Aim for more than 72 Volt. If you're going to put this much time, money and effort into the project, don't you want it to be impressive too?
Don't use a current shunt.
Make the high voltage and the 12 Volt sections completely isolated from each other!
A motor controller is not an amplifier! Expect to have to rethink all component selections when you learn more what it takes. Going for components that are meant for linear usage in a switching construction will end in misery.
Your project will go over budget.
You will break all your time estimations with a factor n, where n is a bigger number than you can imagine right now.
You will run into several unexpected problems a few times which will probably demand partly or complete redesigns of the hardware.
You will experience despair and grief.
You will regret several times that you begun this Quixotic pursuit.
You will learn a lot even if you don't finish the project.
If you actually finish it and get it to work reliable you will have gained a bit of awesomeness.
It will be a very expensive controller when you're done (especially if you value your time). Buying a working controller is cheaper, even if it also means buying a new motor.
You will not believe me now, but you will eventually.
Good luck.


----------



## kennybobby (Aug 10, 2012)

*Valuable Advice*

Thanks for sharing Q, there is much experience and wisdom in your words.


----------



## dauphine (Jun 3, 2013)

I have some questions or comments concerning this. They only pertain if this is going to be an open source or "free" engineering design and build:

1. I am always annoyed with items you buy (everything these days) that have no ability to be troubleshot except basically "replace" or send to the factory. Now that said I understand not every one should "open the hood".

2. How about various levels of trouble shooting designed into the build? Modular layout with self test modes for each module would be nice.

3. Troubleshooting could be : level 1= the dash light is out, call the factory, Level 2= Voltmeter and laptop USB connect to each module and confirm XXX, return module for service. Level 3= After determining module failure, remove module to workbench and refer to service manual for test setup, theory, test indications and individual part numbers. Level 4= Reference part descriptions for parameters to determine new engineering experimentation or substitution. A test could be provided for the user to self take to determine his level before he grabs the screw driver.

I would think a product developed along those lines would sell real good in the diy community. Something that was made to be "hacked" and taken care of by the user so to speak.

Just some random thoughts..


----------



## Marisume (Jun 9, 2013)

kennybobby said:


> Sounds like a fun project, hopefully you can get some school project credits for this also. Have you tried putting low voltage to the motor just to get some motion?


If I don't have this done by the time school starts again, I'll see if I can use this to start an EV club. See below for current testing progress.



DDDvvv said:


> Using your longest conductor as a current shunt:
> Its been determined that temperature rise on that conductor will vary its resistance. Not a very accurate method. May I suggest a dedicated current sensor. This guy sells them for dirt cheap;lremoved. This will measure +/- 300 amps and can go upto 900 amps. You get more accuracy, and great isolation.
> 
> Uc37322 mosfet drivers:
> ...


Thank you! I'll see how I could effectively implement this current transformer in my design. I've considered using a hall effect based current transformer, but decided it was overkill. The reason why I've wanted to use a shunt based current reading is because I've used it in the past, and it's what amplifiers use but on a much smaller scale. If you look, they have a few "loops" of ~10AWG going from the power supply output rail to the fets, and measure voltage drop across those to protect from overcurrent. I'll do some calculations on temperature/resistance under constant load to figure out error percentage, but I have a feeling it won't be as much as the issues I will have with noise and ADC conversion, since it's not a differential ADC measurement. Edit: Calculations say the temp rise in 4/0 wire is insignificant to resistance change.

I'm sorry, I didn't mention that I will use an opto between the uC motor output and the IR2010 or UCC37322/1. Connected through an isolated 12V system from the aux batt.



Qer said:


> Some opinions based on my personal experience:
> 
> 32 kB flash SOUNDS like much. It isn't. You WILL run out of space.
> 328 is an old AVR family. Skip it.
> ...


In order: I thought the same thing, until realized I was almost done with my code and it compiled to be nearly 8kB.
If I find it to not work for me, I will change platform but I have this in hand right now and I'm going to try to make it work. I have much more experience in 8 bit architecture than anything, as I've help make an 8 bit uC architecture on my FPGA board, and am familiar with similar architectures. So far after doing a quick test directly driving the fets with the motor driver chip's output with some success. As far as HW division, I'm using software based division using the AVR200.asm algorithm. I'm not saying I won't keep your suggestion in mind, but I will try my best to make this work out of what I have.


> Write code that is abstracted into well structured layers with many small, readable and well defined/documented software routines.
> Comment the code, document everything, even things that seems obvious now. It won't be some months later.
> Use meaningful variable names instead of things like "c" for current, "i" for a counter etc, use motor_current, counter, table_index etc.
> Really, make sure to write clean, well structured code because over the months you WILL forget what the oldest parts of the software did and how it worked.
> ...


Yeah, I've learned these the hard way. Especially when writing in low level (asm) code. I've blown my fair share of power devices up, and I will probably blow up a good chunk of fets. Until I get everything stable I will test the code on IRFB064s, then I will switch over to the final design fets, IRFB4115s. Almost half of the code is comments, so I'm not worried there... I currently do not have any significant unit testing, but a pseudo-fault protection as far as what the IOs should be upon starting or in certain states.


> Don't use TO220 for anything that is supposed to handle high current. Yes, I know what the data sheets say, it's still a bad idea. Especially if you aim at 1kA peak.
> Aim for more than 72 Volt. If you're going to put this much time, money and effort into the project, don't you want it to be impressive too?
> Don't use a current shunt.
> Make the high voltage and the 12 Volt sections completely isolated from each other!
> *A motor controller is not an amplifier!* Expect to have to rethink all component selections when you learn more what it takes. Going for components that are meant for linear usage in a switching construction will end in misery.


I beg to differ but at the same time, I agree. It's much simpler. I only dealt with Class D amplifiers, meaning switching operation is all I know with much confidence. They are not run in a linear mode at all, but they use negative feedback with comparison to a signal to make an average linear output post filtering, as with any class D amp. I have used the fets in mind in the past for a few other projects, and they're pretty robust all things considered. You may not like the TO-220 package but I have had a lot of experience with them. I do prefer TO-247 or one of the ISOTOP packages, though. Take the IRF1404 for example. I've used (and seen used) 2 half bridges of 2 per leg of these in a 7kW amplifier with great success. It all comes down to thermal conductivity and cooling, which I have lots of as the motor requires it anyway. As far as being only 72V capable, it's only really a matter of what fets are in the power stage. In Oklahoma I can only run a maximum bank voltage of 80V in any condition without having to get a costly certification. I think it's a load of crap, but can understand the safety issues at the same time. 


> Your project will go over budget.
> You will break all your time estimations with a factor n, where n is a bigger number than you can imagine right now.
> You will run into several unexpected problems a few times which will probably demand partly or complete redesigns of the hardware.
> You will experience despair and grief.
> ...


Oh, I totally understand the potential anguish and grief this will cause me. I want to say I'm prepared for it, but I know there will be points where I will want to throw this thing into the street.

Current progress: I mentioned earlier, I hooked the board up to a few fets to test drive the motor's arm and field at 12V supply, and seems to work so far on a dummy load. I'll breadboard up a few different fet drivers to measure performance of the fets.



dauphine said:


> I have some questions or comments concerning this. They only pertain if this is going to be an open source or "free" engineering design and build:
> 
> 1. I am always annoyed with items you buy (everything these days) that have no ability to be troubleshot except basically "replace" or send to the factory. Now that said I understand not every one should "open the hood".


A lot of these components are either extremely simple(fets), or complex(microcontroller). The fets for example can only be measured for failure indicating characteristics to be replaced. The microcontroller is similar, but if it fails it is something that can't really be fixed without replacement. This is not taking into account programming based logic errors. As far as an open source package, I might develop it into something similar to Re-volt's DIY package, but I would not want to source boards as I'm trying to reduce my overhead for college tuition. 


> 2. How about various levels of trouble shooting designed into the build? Modular layout with self test modes for each module would be nice.
> 
> 3. Troubleshooting could be ...(cut for char #)
> 
> I would think a product developed along those lines would sell real good in the diy community. Something that was made to be "hacked" and taken care of by the user so to speak.


I try to make these features for myself, as it makes my developing life easier. The thing is, you run into users that require their hand to be held in debugging. This isn't a problem, but a significantly easier solution would be just to replace the defunct part.

It may not sound like it at times, but I really appreciate everyone's responses!


----------



## Marisume (Jun 9, 2013)

major said:


> Hi Mar,
> 
> There have been several threads about SepEx motors and controls, some involving hacked type control. Take a search or two on the forum tool and you might find some things of interest. Here are a few suggestions.
> 
> ...


I've looked at a few of them, especially the thread taking two standard controllers and controlling them separately, which is what's happens anyways.

I don't quite have the vehicle together. For now I'm basing the rest of the system around the motor. I have access to a handful of machining and fabricating tools such as a CNC Plasma table. I used to have access to a CNC mill but the recent tornadoes took out the center that housed the CNC mill, and is out of commission for the time being, and any near foreseeable amount of time.

Right now I'm planning on maintaining a constant field unless certain conditions arise, but that's the plan.

The "problems" I'm having with regen braking is that I don't know what to expect out of the motor, as it's rated at 30V 300A in the 3k-8k rpm range, and in order to use it as a straight forward (non forward SMPS) regen I'd have to do two things most likely. Drop the gear it's in to get a higher RPM, and overdrive the field by a good bit to get >72V out of it. It's something to be implemented later in my opinion, but will be kept in mind. I'm aware I can just run it as a halfbridge to do regen, it's just I don't know what to expect out of this motor.  It's rather tiny for its handling power. Forced air cooling works wonders. It's about 100lbs, 6" outer housing dia, and is RATED for 12HP continuous, and is military grade.  The shaft reflects this too... ~7/8"-16 involuted spline hollow shaft. I'm looking to get a coupler to work with this. It's unusual.

I got up close and personal with the insides of the motor without disassembly. Everything is oriented and designed to cool with the air ducted through the motor. It should be pretty resilient.


----------



## Qer (May 7, 2008)

Marisume said:


> In order: I thought the same thing, until realized I was almost done with my code and it compiled to be nearly 8kB.


The first version of the Soliton code that was let out in public streets were merely 1500 lines of code. The latest is, well... Let's just say bigger. A lot...

Having "only" 75% left when the first mockup runs sounds tight to me, but, well, there's bigger AVRs and they're reasonably compatible. If I were you I'd worry more about:



Marisume said:


> As far as HW division, I'm using software based division using the AVR200.asm algorithm.


Software division in AVR:


```
0000a458 <__divdi3>:
    a458:       a8 e4           ldi     r26, 0x48       ; 72
    a45a:       b0 e0           ldi     r27, 0x00       ; 0
    a45c:       e2 e3           ldi     r30, 0x32       ; 50
    a45e:       f2 e5           ldi     r31, 0x52       ; 82
    a460:       0c 94 aa 64     jmp     0xc954  ; 0xc954 <__prologue_saves__+0x2>
    a464:       f5 01           movw    r30, r10
    a466:       29 a3           std     Y+33, r18       ; 0x21
    a468:       3a a3           std     Y+34, r19       ; 0x22
    a46a:       4b a3           std     Y+35, r20       ; 0x23
    a46c:       5c a3           std     Y+36, r21       ; 0x24
    a46e:       6d a3           std     Y+37, r22       ; 0x25
[lines and lines of assembler snipped]
    b3be:       30 2f           mov     r19, r16
    b3c0:       41 2f           mov     r20, r17
    b3c2:       5b 2f           mov     r21, r27
    b3c4:       64 2d           mov     r22, r4
    b3c6:       7a 2f           mov     r23, r26
    b3c8:       8f 2f           mov     r24, r31
    b3ca:       9e 1b           sub     r25, r30
    b3cc:       c8 5b           subi    r28, 0xB8       ; 184
    b3ce:       df 4f           sbci    r29, 0xFF       ; 255
    b3d0:       e1 e1           ldi     r30, 0x11       ; 17
    b3d2:       0c 94 c6 64     jmp     0xc98c  ; 0xc98c <__epilogue_restores__+0x2>
```
Divisions on an ARM:


```
14cc:       fbb2 f3f3       udiv    r3, r2, r3
```
Just sayin... 

However, if you're gonna stick with the AVR the biggest problem won't be that it takes flash space but that it chew up execution time! An ARM can do tens or even hundreds of millions of divisions per second without problem, an AVR will be limited to a few thousands, probably less than ten thousands unless that lib is extremely well optimized. This will hurt your performance very quickly if you're not careful where, and when, you divide.

Instead of divide, multiply! Divide a 16 bit unsigned value by one hundred can for example be done by:


```
uint16_t div100 (uint16_t inval)
  {
    return (((uint32_t) inval) << 16) * 655;
  }
```
Well, ok, it's a division by 100.05344, but often that's close enough and it saves a LOT of clock cycles compared to running software divisions. If you want to have CPU time enough to start to do some bouns stuff (control gauges, log data, limit motor current, protect the batteries etc) you'll have to be careful on what you waste CPU cycles on.



Marisume said:


> I'm not saying I won't keep your suggestion in mind, but I will try my best to make this work out of what I have.


Your show, your rules, but it's always harder to switch the scene after the premiere.



Marisume said:


> Yeah, I've learned these the hard way. Especially when writing in low level (asm) code.


I guess I forgot one bullet in the previous post:



Stay away from assembler! It's non-portable, it's untestable, it's unreadable and a world of hurt when things starts to get complicated. Assembler is necessary in a few, rare situations, but not when you code on AVR. Stay C.



Marisume said:


> I try to make these features for myself, as it makes my developing life easier. The thing is, you run into users that require their hand to be held in debugging.


Yep. Support is a huge time consumer. Stay clear of that one.


----------



## Marisume (Jun 9, 2013)

Maybe I'm not properly grasping the complexity of the project. It's a simple chopper(for now) based around various inputs with display outputs. I've got nearly 80% of it coded with the exception of temperature inputs and logic, and the serial display interface. I've yet to figure out where and how to mount the thermistors. I'd ideally want to get a brush temperature and stator temperature to see how far I can overdrive the field for regen.

If I'm not mistaken, I will be waiting longer for the ADC reads than division. They take approx 100uS. Approx 2000 clock cycles worth, but I could be mistaken as far as comparison goes. I just tried the code out with that previous test bank of fets and I could not notice a delay on the throttle to motor response, but I'm not in the vehicle being directly affected by it yet. I'll put the I2C interface code in for the bar gauges to see if they delay.

Oh yes, I'm staying as far far away from assembly as I can. I was just making a reference to it because the FPGA architecture I helped make ended up being designed around a pseudo-assembly language. I was just putting that there to say I've spent countless hours working in assembly. Haha.

As far as an open source project, I'll probably just throw whatever I end with up for documentation and reference leaving them to decide what to do with it.


----------



## Tesseract (Sep 27, 2008)

Marisume said:


> Maybe I'm not properly grasping the complexity of the project. It's a simple chopper(for now) based around various inputs with display outputs. ...


Yes, you are not grasping the complexity of the project. You need an H-bridge (ie - full bridge) for the field in a SepEx motor, and a half-bridge for the armature, which needs to be able to seamlessly switch from buck to boost mode. This requires a rather more sophisticated control loop than a plain old constant current buck (chopper).

The problem is not with the buck, but with the boost. Look up what a "right half plane zero" is and then decide how to tackle it, because tackle it you must if you want to make a proper SepEx armature controller.

I'm not trying to dissuade you or even suggest you aren't up to the task, rather, I'm just warning you to not be so flippant about it.

And yeah, save the TO-200 parts for highly-intermittent applications. Your 7kW amps weren't delivering 7kW continuously, I bet.


----------



## Qer (May 7, 2008)

Marisume said:


> I've got nearly 80% of it coded with the exception of temperature inputs and logic, and the serial display interface.


You know what they say, it's the last 10% that takes 90% of the time in a project, it's a bit like that with code size too... 



Marisume said:


> If I'm not mistaken, I will be waiting longer for the ADC reads than division.


You don't have time to wait on the ADC if you're going to sample at a speed worth anything. You should set up the AVR to handle the ADC with interrupts, so you can use the time executing the rest of the code as usual.

What you do is when you start up the ADC (enabling ADEN etc) you also set Interrupt Enable (ADIE) and, of course, SEI (the general interruptflag for the whole system) and when a conversion is done the CPU will trigger an interrupt and your interrupt vector (called "ISR(ADC_vect)" if you use gcc, other compilers will use other names) will be called.

The advantage of this is that lots of stuff can be set up to be handled "magically" (ADC, UART, PWM, SPI, I2C etc) and the best practice is to write your code so you never ever busy wait for anything.

The disadvantage is code complicity. Handling interrupts is a skill and there's several pit falls. One of the simplest ones is that a compiler usually is very careful to not write to RAM more than necessary but keep data in registers as long as possible. With interrupts this is extremely dangerous since an interrupt will, exactly as it sounds like, interrupt whatever the CPU is doing right now.

If you, for example, have two buffers, receive and send, that stores the traffic from and to a CPU (for example an interrupt driven serial port) you can get data corruption because data that you THOUGHT were written to the buffer actually is still stored in internal CPU-registers and what you read is old, outdated values.

The solution to that is to declare all variables that will be shared between interrupts and the rest of the code (or even between two different interrupts) volatile, for example volatile uint16_t for a storage variable for ADCs. Volatile tells the compiler to never try to optimize those memory accesses since the value is, well, volatile... 

All of the registers in the AVR (like PORTA etc) are usually declared volatile since the hardware might change the values of them without the software being aware of this. The interrupts will do the same; change a register value "behind the back" of the main program. There's no way to detect this in the software, thus you have to use volatile when that might happen.

There's other fun pitfalls with interrupts too, but the benefits outweight the added complexity when you otherwise would run into bottle necks. One huge problem with the AVR 328 is the slow sample speed of the ADC. You pretty much need to continuously sample it as fast as possible to have a chance to catch over currents in time (and it's still a bit too slow for that) so you can't just poll the ADC for a finished sample. If you do the AVR will pretty much do nothing else but polling...



Marisume said:


> I'll put the I2C interface code in for the bar gauges to see if they delay.


I2C... Brrr. I2C is a bad design from the beginning to the end. Some personal, very painful, lessons:



Timing is of essence, wrong timing on the bus and it gets hopelessly corrupted but the timing is done in hardware so you have very little to say about it. The timing for I2C on the AVR is sane, but it's a bad habit to use I2C since not all platforms are that fortunate.
I2C uses resistors for pull up, this means the bus has a relatively high impedance (compared to, say, SPI). Add some mad motor current to that and you are likely to get communication errors due to noise.
Some I2C slaves don't handle stop-conditions correctly. The spec says that when there's a stop-condition all devices should reset the communication and be prepared for a new start- and address transmit. Some slaves don't do this correctly and can get locked up, refusing to communicate until power cycled.
I2C code needs to be written as a pretty complicated state machine that correlates to the state machine in the I2C hardware of the CPU. This seems to be the case with all I2C-implementations, at least the ones I've experienced.
I2C generates a huge amount of interrupts since your software state machine must be run in sync with the state machine in hardware. This means that you will get one interrupt for the start condition, for every transferred byte but NOT for the stop condition (by some idiotic reason).
Modern implementations of UARTs and SPI use FIFOs so you get one interrupt per n bytes, usually 8, 16 or so. This allows for much higher transfer speeds and less CPU-load since you don't have to wait for the software to react before sending the next byte.
Since there's a lot that can go wrong with I2C-transfers you must add a lot of error checks which complicates the code even more and makes it even harder to debug.
I2C is next to impossible to debug with JTAG because the state machine can shift states differently depending on the timing, even though they shouldn't...
Because of the complexity and the unpredictable nature of it all debugging I2C is a PITA! Using a lib for I2C will remove that headache from you, provided the lib is bug free. Few I2C-implementations are, there's always one more bug...
It's fairly easy to concentrate the hardware dependant parts of all interface drivers into a small, relatively uncomplicated piece of code that usually has to be tested manually since it's pretty pointless to write test cases for this level of code. That is, it's fairly easy for (almost) anything, except I2C.

Using anything but I2C is a very good rule of thumb, especially in a noisy environment. Trust me on this...



Marisume said:


> As far as an open source project, I'll probably just throw whatever I end with up for documentation and reference leaving them to decide what to do with it.


Which is why it's often almost as much work to get an already done open source project running than reinventing the wheel from the start.

Not blaming you, though. Support is horrible, time consuming and mind numbing and since it's hard to get paid for supporting open projects there isn't much (guaranteed) support available for them as well. Cause and effect...


----------



## Marisume (Jun 9, 2013)

Tesseract said:


> Yes, you are not grasping the complexity of the project. You need an H-bridge (ie - full bridge) for the field in a SepEx motor, and a half-bridge for the armature, which needs to be able to seamlessly switch from buck to boost mode. This requires a rather more sophisticated control loop than a plain old constant current buck (chopper).
> 
> The problem is not with the buck, but with the boost. Look up what a "right half plane zero" is and then decide how to tackle it, because tackle it you must if you want to make a proper SepEx armature controller.
> 
> ...


I don't see any reason to reverse field current. I don't need the motor to go in reverse as I plan on using a transmission. The motor I have has angled brushes and are advanced, so driving the motor in reverse would be slightly harmful. For a proper motor controller, I'd use a fullbridge for the field... But I do not need it. I will just use a chopper for the field. By all means correct me if I'm wrong, though.

I did some more testing today and I seem to have the regenerative braking figured out on the small scale. I used a IRFP064LC halfbridge driven with an IR2010 with the motor connected across the high side fet. I drove the low side fet directly with the pwm signal, and the high side fet with the inverted signal. Measuring voltage across the motor upon quickly changing duty cycle shows regeneration attributes. I will see if I can use the uC to measure the voltage in the boost switching stage and control the inverted duty cycle to get a target current. This process is the only thing that is really new to me...

Ah! I've heard about RHPZ in a theory class I've taken. I'll do some research and I'll ask my professor to see how/in what condition it applies and will go from there.

I agree with the TO-220 package being subpar. I will be contacting my supplier to see what they have in stock with the specs I'm looking for. Earlier I was just going by Newark's availability. Though, I'll stand by my reference to TO-220s being used in a 7kW(and 14kW, scaled) amplifier as forward SMPS current sinks.

Thank you for your input!

@Qer:
Yeah. Debugging time is what gets me, as it usually comes down to figuring out what exactly the uC is doing vs what I thought/assumed it was doing in a certain segment of code...

I have two-three ways of handling ADC. The simplest being to just tell it to go read it and return the result in a linear fashion. What it does is starts the conversion, waits for a result, gets a result, adds to a var, loops this 20 times, and returns the average of the set of results. The whole process takes 2300 cycles according to the debugger. Now, whether or not this is "fast" enough with respect to reaction or switching times is a different and entirely relevant subject. For the sake of code simplicity I will probably leave it as it is unless it causes a problem with throttle response or overcurrent detection, which is only to protect the semiconductors as the motor can take an absurd amount of current for a short period of time. The other way(without using interrupts) is by starting the conversion early, and when I need it if it isn't done I wait on it. This shaves off some cycles at the cost of minimal additional complexity. Either way I'm doing 4-5 conversions per main loop using the most linear way of thinking and not using delayed or intermittent sampling for less relevant information, so to speak.

I agree with I2C being non-ideal. I'll take your word of advice and switch to a progressive serial based controller that I'm much more familiar with. The uC does have libraries to handle I2C, but I still don't like it very much even if I have the I2C led controller.

As I go, I try to document every part of my code and circuit design because I know it at least helps me keep things straight. I really like to see it in open source projects too, as it helps me understand their thinking. Keeping everyone on the same page, etc. As far as supporting this project beyond it's initial use, I might have a few extra boards made and will sell them after proving everything works well enough. I will probably make the boards in house at the university, so board cost comes down to the price of the copper clad board. It won't have through hole plating without installing them manually, but I am able to get it silk screened.


----------



## major (Apr 4, 2008)

Marisume said:


> The motor I have has angled brushes and are advanced, so driving the motor in reverse would be slightly harmful.





Marisume said:


> 30V 300A Aircraft Pump Generator, which end up being a shunt field wound separated excitation motor. Off of a 1970s prop plane.



Something doesn't sound right here. Got a picture of the machine?


----------



## Marisume (Jun 9, 2013)

Sure! I'll take some pictures during lunch and add them to this post. Done. They may not be advanced, but they look like they might be. Manually rotating the shaft opposite to the direction I wired it(B arm+, E arm-, A field+, D field-) causes the bushings to squeak. I'm rather certain it's a shunt wound sepex motor, as I can ONLY get it to turn when I apply voltage to the armature AND the field. I tried up to 36V on the armature to test if it had a high impedance series wound field with the armature. I just get a bunch of current draw and no rotation without powering the field terminals.

I put links instead of attaching pictures. They're 5MP if I'm not mistaken, taken from my cell phone with a high powered LED flashlight without a lens for lighting. Enjoy!

4 brush picture: This is under the duct inlet cap seen in the overview pic. It seems like nearly all of the braces are bladed like this. Including the internal ones linking the shaft to the armature. I couldn't really get a picture of those, though.

Close up single brush picture: Kinda blurry. The macro lens setting helped, but not enough.

Brush Top: Probably one of the best macro pics I've taken with my phone.

Terminals picture: (Note the old condenser, in the process of being replaced, I'd assume it's for arc(and noise) suppression as it is connected across the armature through the case to what would normally be connected to battery common)

Front inside picture,field and arm windings: (Note the size and orientation of the arm windings, field wire size)

Shaft Plate: Weird shaft. .85-.865" OD 16 involuted splines, hollow shaft... Ugh.

Overall: Pretty compact. I'm pretty sure it's relying on the forced air cooling. As a result, push more air through to allow more current through!


----------



## piotrsko (Dec 9, 2007)

Weird shaft actually kinda looks like a standard aircraft engine accessory drive fitting from anything made since WW2. If so parts are available everywhere. Especially if you don't require airworthy.


----------



## Marisume (Jun 9, 2013)

piotrsko said:


> Weird shaft actually kinda looks like a standard aircraft engine accessory drive fitting from anything made since WW2. If so parts are available everywhere. Especially if you don't require airworthy.


I'll look into it! Thanks!

Edit:
It might be following MS14169...
MS14169 Size I 16T .800 PD 20/30DP INVOL
This lines up with what Gearotic says I should have. .858" gear diameter, .75" root
+1 rep to you


----------



## Marisume (Jun 9, 2013)

I was digging through parts in the shed, and I happened to find a nice 4 digit 16 segmet VFD with a 3 wire serial driver attached. I think I'll use it as a RPM display. I might have another one sitting around and use as a speedometer display... All I can say, is "Ooooh, it's glowy."

Unfortunately, as an executive decision based around funding and simplicity, the prototype of this driver will use simple chopper for both the field and armature control. The cost of added parts vs gain is too high to consider viable from what I've researched. I might have a form of electronic braking by dumping generated energy into a resistor bank, since I have 16 225W 1 ohm wire wound resistors at my disposal. My plan is to make the switching board "modular", so I can expand on it if I feel it's necessary. I don't know. I'll see what happens when I order the parts.


----------



## major (Apr 4, 2008)

major said:


> Marisume said:
> 
> 
> > The motor I have has angled brushes and are advanced, so driving the motor in reverse would be slightly harmful.
> ...





Marisume said:


> Sure! I'll take some pictures during lunch and add them to this post. Done. They may not be advanced, but they look like they might be.


I'm not 100% sure but the machine appears to be a starter generator similar to the J&H, Westinghouse and GE brands. I don't know why you used "pump" in your original description. Assuming it is the starter generator like the others it would be a compensated shunt wound machine possibly having interpoles and compensating windings. Because these were used for both motoring (engine starting) and generation, and because of interpoles and compensation, the brushes were probably neutral.

Quite a few DIYers have used these surplus machines for builds with varying degrees of success. They are robust machines. 

Good luck,

major


----------



## Marisume (Jun 9, 2013)

I agree, it's identified as a starter generator. Though, the label(that I forgot to include a picture of) says "Pump Generator". I'll attach a picture later today.

What are the implications of it being compensated? If I'm not mistaken it has a similar effect to advancing the brushes, being that under high armature current the field coil's field is contorted, and a compensated field coil is displaced by the amount a normal field coil's field is shifted under a certain armature current... Does that mean the low speed torque is lower than a motor without compensated field windings? During a low speed high current condition, the normal field might be shifted so...? I don't know, so I have to ask. 

After close inspection using a mic, and a precision compass, the brushes are indeed neutral. Good to know it might have interpoles.

Good to hear! I think so too. I'm going to try to put it on the lightest thing I can find, but I may end up with a heavier frame and I hope this motor will be able to push it. :x More cooling! The brushes and commutators look barely used, so I think it'll have a good life to it too.


----------



## DavidDymaxion (Dec 1, 2008)

Total Joe Amateur here, amongst controller giants, but I do have a little bit of sepex experience.


A reed switch on a field lead can control a main contactor. That way if the field dies for some reason the motor won't get ruined. Consider it cheap insurance against a programming bug.
Likewise, you could put a resistor into the field lead for the minimum current case, and short it with a transistor. That way, if the transistor fails open you don't go to zero current in the field.
Have you run the motor on 12V, 24V, etc. and measured RPM? If you have enough rpm overhead, you don't need to buck up the voltage to regen, but that limits you to regen only at higher RPM -- but that might be a reasonable compromise.
My 180 lb sepex motor could handle about 1500 W continuous on the fields with the motor spinning for cooling air (it would get warm), and my little one 60 lbs handles 80 W on the fields and barely gets warmer than ambient with just field current or at idle.
Be sure to put a diode across the field. It has a lot of inductance, and will turn your contactor into a spark plug otherwise.
Thanks for posting about your work, I'll looking forward to hearing your progress.


----------



## Marisume (Jun 9, 2013)

Quite frankly, as fail safes, those are great suggestions! I was already planning on doing the reed switch protection, but hadn't thought of using a resistor to ensure a minimum field current. Though, if I'm blowing out my field transistors, I've got a problem already and it'll be shut down through the reed switch. I'll consider it in the design.

No, I have not measured the RPMs at various voltages. Quite frankly, I'm going to have to borrow or make an optical RPM gauge. I might try to work something else up, though...

My sitting field resistance reads about 4 ohms. I have not quite measured it's current vs rpm and arm current, yet. That being said, I have no idea how much power I can get through mine. I'll just have to try and see. I will be running essentially an electric leaf blower through the air inlet, as it is designed to be air cooled. With that I should be able to keep the temperature down even under considerable overdriven conditions.

The field and armature drivers will have some beefy flyback diodes across them. 

Yeah, I have not worked on the controller side of things much since I've started posting, but I have worked on the mechanical side of things. I found a stripped down 1986 Pontiac Fiero SE (V6) for an awesome price and picked it up. There's going to be a lot of work before it'll look nice again, but it's almost perfect for this conversion as they were nearly half way done converting it into a dune buggy. As it sits now, with a full (working) cast iron V6 motor in it, it weighs 2000lbs. (!) I figure by the time I'm done ripping out the ICE parts and some non-frame sheetmetal(one fender is already removed), it will be much more manageable.


----------



## toyolla2 (Jun 21, 2010)

Date circa 1982

The motor is an Aircraft Starter Generator or ASG.

Spec voltage 28.5Vdc @400A generating, 1000A starting
Specified field 7 amps

Since we could set field electronically we traded slightly more iron loss
by moving to 36Vdc on armature and a 9 amp field.

2250 rpm @ 9 amps field on 28.5Vdc
2650 rpm @ 9 amps field on 36.0Vdc


The VW gearbox was uncoupled for this test.

Armature control provided by a Willey 400amp controller running on 72Volts.
It used an SGS3524 chip with its push pull outputs wire-orred to give 95% max modulation.
It was essentially an open voltage controller with current limiting provided by saturation voltage sensing.
A 10 microsec monostable delay timer to mask switch noise would truncate the ON pulse
whenever the 20 - transistor bank was detected as being pulled out of saturation.

It was an aircooled design using 30 amp Darlingtons from a time when we didn't know better.
Had it been watercooled it might have been successful.

A 10 amp field controller of my design using a MC34060 driving a TIP147 pnp T220 darlington from a 40V supply.
The PNP output allows the use of ground referencing for field current feedback. 

The motorola PWM chip has two input op amps. I use one to limit the max field current. The other is used (but not in these tests)
to compare the armature current with the 0 - 5 accel pedal voltage and modify the PWM output and hence the field current accordingly to get the desired armature current. This is for operation in the Armature Controller Bypass Mode.

IRON LOSS TEST AT CONSTANT SPEED
Test conducted at No load @ 4500rpm 
Armature volts,armature current power and field current resp.

Ea ......Ia ...Watts ....If
57.6 ..26.0..1500 ..7.2
50.0 ..22.5 .1125 ..4.8
45.0 ..21.0 ...945 ..3.9
40.0 ..20.5 ...820 ..3.2
35.0 ..20.0 ...700 ..2.8
30.0 ..19.5 ...585 ..2.3
25.0 ..21.0 ...525 ..1.8
20.0 ..23.5 ...470 ..1.4
15.0 ..29.0 ...435 ..0.95
10.0 ..44.0 ...446 ..0.4

Tektronix 2213 scope to measure 4500rpm
Trace 1 -------- digital divider fed by a XTAL reference frequency
Trace 2 --------- optical pulse sensor
　
Here's an even earlier test where field current wasn't measured.
as we probably didn't have a suitable meter available.

The motor was coupled to the VW gearbox (in neutral).

Ea ...Ia Watts
59.5 ..39 .2320 .....No reading taken
35.0 ..26 ..910 ........6.8v on field
20.6 ..35 ..721 .......3v on field

First, you don't want any transmission that turns power through 90 deg
There is a 30% torque loss just for that.
Note that the VW gearbox really whines going above 6800rpm.


----------



## toyolla2 (Jun 21, 2010)

There could be a problem that one end of the shunt field may be wired internally to the -ve side of the armature. This is not a serious problem it just means you cannot current stabilise the field against temperature although a voltage regulator on the field would be nearly as good.

The drive experience will be similar to a diesel with reduced torque towards 3000rpm, however I know that with the 400Amp ASG you can lower the field voltage to 7amps, sacrificing a little torque to get more rpm.


Personally I would drop DC designs. Only legacy machines in industry still use DC motors and most of them are slowly converting to AC induction motor drives. For that reason if you have time on your hands you want to consider investing it in AC. 


QERs post #5 on here, deserves a read before anyone should start thinking of laying out serious money. 


On AEVA I started a thread _14000 rpm machines _take a look.


HPEVS AC-9 motor for use on 48Vdc. 50Vac on 100Hz. V/Hz=0.5 looks interesting. There is a HPEVs thread here on DIY where I asked for a go-ahead for running this motor on 96Vdc with a Curtis 1238R-7601 [email protected] 650A no response yet. This would be for 200+ HZ operation although Curtis goes to 300Hz (9000rpm) also has a cold plate option which is mandatory for a road vehicle.


----------

