There are a few drawbacks:
1). The controller is physically large. It weighs 25 lbs and is 1 ft wide.
2). It is difficult to turn on. More on this later.
3). There's no great way to interface with it - there's really only an analog input that has lots of filter and is difficult to adjust, so there's no way to update the torque setpoint very quickly.
4). It requires a lot of things to be plugged in for the controller to work.
5). It only can drive induction motors, no brushless permanent magnet motors
6). The controller needs to be tuned to each motor used with it, which is a difficult and involved process
7). It takes forever to set up. Peter, Bayley, Dane, and I worked on this terrible thing for a whole week from 7 pm to 3 am each night to get it to an acceptable state.
8). The software has lots of weird bugs. This is probably because ours says 'engineering prototype: do not operate' on the label.
Dane took apart one of the controllers to see what was inside:
The heatsink is a nice aluminum extrusion that's connected to the board with all the FETs. There are a TON of FETs in this device, each with their own BJT gate drive. The FETs are relatively high resistance (19 mohms I believe).
The logic board on this controller is equally impressive/bizarre:
Bayley, who enjoys searching the internet for interesting motors from cars, found the first car part for this project: a nice 'eAssist' induction motor from a Buick LaCrosse for around $100 that was roughly sized to work on this controller. It claimed to be a 15kW motor, but it can do much more for a short period of time. It's also nicely sealed and comes with a resolver and is water cooled.
We started by building a test load for the motor: a supercharger from a Buick ????.
In the end, we were able to put around 10 kW into the supercharger.
Dane ordered a collection of connectors and pins to plug into the Sevcon. Over the course of roughly a week, Peter, Dane, Bayley, and I managed to trick the controller into spinning the induction motor.
Debugging the controller was a massively annoying process that included:
- Reading and writing x86 assembly
- Programming a nucleo to scale down a high resolution encoder
- Cross compiling code for STM32's on linux because mbed compiler website was down
- Fiddling with linux usb interrupts
- Hooking up a large water cooling loop from the MITERS sink to the electronics bench
- and many other strange activities
We don't fully understand everything there is to understand about these controllers, but the some of the knowledge we gained in the process might be useful to others. This next section is formatted more as a list of helpful information. The debugging process is too boring to blog fully.
POWERING ON THE CONTROLLER
The startup sequences is initialized by providing low current fused (5A I think) power to the logic board. If it decides to enter the 'operational state', it will precharge the bus capacitors then turn on a contactor to provide power to the DC bus. The controller will try to enter 'operational state' unless it was manually transitioned to 'preoperational (preop)' before being turned off. If there is an error, the controller will go into preop automatically, but it will still attempt to go into operational the next time it is turned on. Going into operational state when the controller is not properly configured can dump a huge amount of current into the motor without the motor spinning or applied throttle, so be prepared! We used an 80V 25A power supply, which often current limited and browned out the controller during testing. It doesn't take long for 2 kW to heat up even a large motor, so external cooling is recommended during testing.
It's very important that you don't use a 'smart' contactor that goes and lowers the coil voltage once powered on. The sevcon contactor driver will go into an overcurrent state and prevent the controller from entering operational mode. We also encountered a strange issue where our 80V power supply wasn't quite isolated properly and floated a few volts above ground, causing random overcurrent faults on the contactor. Properly grounding the controller fixed this issue. The sevcon also has adjustable settings for contactor voltage, as well as the ability to lower the contactor voltage after a few seconds if you don't want to burn out your contactor coils.
It's very important that you don't use a 'smart' contactor that goes and lowers the coil voltage once powered on. The sevcon contactor driver will go into an overcurrent state and prevent the controller from entering operational mode. We also encountered a strange issue where our 80V power supply wasn't quite isolated properly and floated a few volts above ground, causing random overcurrent faults on the contactor. Properly grounding the controller fixed this issue. The sevcon also has adjustable settings for contactor voltage, as well as the ability to lower the contactor voltage after a few seconds if you don't want to burn out your contactor coils.
 |
| 3 switches, contactor, and enable switch |
You also need to provide an additional three switches - forward, seat switch, and throttle switch, to get the controller to drive the motor. The I/O section of the configuration tool must be used to map these switches.
We also encountered strange behavior where we were able to read an analog channel, but the throttle position in 'driveline' wouldn't update. I currently don't remember what the fix was, but I hope to update this section once I have a chance.
We also encountered strange behavior where we were able to read an analog channel, but the throttle position in 'driveline' wouldn't update. I currently don't remember what the fix was, but I hope to update this section once I have a chance.
The sevcon connects to the computer through an IXAAT USB to CAN adapter and is programmed with DVT. The DVT installer can be found on the internet if you look hard enough (it's a little tricky - the download link appears in an image of a PDF document) and can also be acquired from SEVCON customer support if you ask nicely. Their engineering department is super awesome and gave us software called MOTOR-WIZARD, which installs firmware on a device to allow it to characterize a motor and generate configuration data for the specific motor. Unfortunately, MOTOR-WIZARD goes and flashes some new firmware onto your motor controller that replaces the default firmware. We didn't have a copy of the original firmware for our controller, so installing MOTOR-WIZARD permanently turns the controller into a motor characterization device. If you only have one controller, this will be a problem - you can't use a MOTOR-WIZARD flashed controller as a normal controller. It might be that sevcon engineering will give out firmware to restore your controller, but you should definitely check before you flash your controller with DRIVE-WIZARD firmware. If you are interested in getting the configuration file we created with drive wizard or have questions, leave a comment with your email address and I will send it to you.
DVT comes in many different flavors - there's a generic customer version DVTC, several versions customized for specific customers with specific device support and customized window titles, and DVT engineering, which has the most settings. It doesn't look like license codes are different between software versions, but your license code is tied to a single computer. License codes can be obtained from sevcon technical support for a single computer in some cases, but are only valid for lower 'customer' access level. The CAN packets are built/decoded in a single dll that also implements their licensing and 'access level' code, which can be fiddled with to make work if you are desperate, but it's much more pleasant dealing with helpful sevcon engineers than x86 assembly... Even if you manage to "validate" your license (either with a license key or with some clever fiddling), the license reading code in the dll needs to do additional checking to determine your access level. Again, some amount of clever "fiddling" can adjust your access level to let you modify certain "advanced" settings, but again, dealing with Sevcon engineers is better than trying to outsmart the software. The highest possible license is 5, which is the SEVCON engineering level. This lets you change every setting of the controller, including ones that are stored in device configuration files (.dcf's) that might go and blow up your controller if they are incorrect. We found that having access level 5 gives you very few new settings - I believe we only changed a level 5 setting once, which turned out to be not needed.
Unfortunately, the DVT GUI doesn't expose all the settings necessary to program the controller to work with a motor. .dcf's are stored as plain text and contain lots of useful settings, though you will need to decode the hex values and scale by the appropriate amount and deal with endless 'param dyn range' errors. This error means that you have entered some value in the .dcf that doesn't make sense or is out of range. I highly recommend changing one setting at a time, power cycling, and checking for param dyn range errors to avoid having to remember the last 20 changes you made trying to figure out how you broke the incredibly fragile configuraiton data. DRIVE-WIZARD will spit out a .tcl script that can be loaded with "File->Source" to go and change the settings to work with the motor. This is the best way that we found to configure the Sevcon.
 |
| The workbench |
 |
| Peter's soda can/hot glue coupling worked great! |
Unfortunately, this encoder was high resolution and generated quadrature signals in the 100's of kHz range, which was too fast for the slow TI brand DSP on the Sevcon logic board. Using some of the encoder code created by Ben, we tricked an STM32 nucleo board into becoming an encoder divider. My implementation of the encoder-divider is available here: LINK
The nucleo's 3.3V outputs weren't enough to drive the Sevcon inputs, so we added some transistors
 |
| The board is taped to the table so it doesn't fall off. |
Amazingly, all this nonsense worked, and the motor spun up. Here it's spinning at around 2000 rpm, out of a maximum of around 8000.
At full speed it sounds like this:
which is absolutely terrifying. We had to hook up water cooling from the sink to keep the motor at a comfortable temperature.
The next stage of the project was completed extremely quickly and with few pictures taken, so documentation is brief. The "outboard" uses an alternator belt from a Kia that runs in the water to drive the propeller. This actually worked, but only with extreme tension on the belt. Dane performed a small miracle, and somehow determined the spline on the propeller was the same as the spline on a Fiat 500 steering wheel, so we used steering parts from a Fiat as the propeller shaft. Rob Reeve created a beautiful copper coil for the cooling loop, which was driven by the amazing brushless Toyota Prius water pump.
Peter and I mounted the sevcon and created some more legitimate wiring:
 |
| Sevcon in boat |
 |
| Box of Switches |
 |
| battery |
 |
| Motor on boat |
 |
| 4 of these packs should be enough... |
 |
| Loaded boat |
The boat worked moderately well. Unfortunately, our pulley ratio was off by a factor of two. Our motor could only spin at a very low speed, in a range where it can give us only around 9 kW, instead of the 30 we designed for. The boat did not plane, which also might have been because it was a small aluminum fishing boat, not a speedboat. We were unable to increase the motor velocity because the controller was operating at the 600 amp phase current limit. At this low speed, we were only at around 20% DC bus utilization, but we could not safely put any more volts across our motor. The mechanical disadvantage from the incorrect pulley ratio would have caused the phase current to exceed the limit. At full speed we could only put 9.6 kW into the motor, which was enough to get to 8 mph.
See a video of the boat in action here:
