Rickys High Power Flexable motor controller

[Ricky_nz]

Navitas's TSX separately excited controller does that exact method. They have the 200Amp bidirectional Allegro sensor on the PCB and provide a parallel path to shunt a portion of the current around it. http://www.navitastechnologies.com/Navitas/Separately_Excited_Motors.html They have done 600Amp measurement using that method. They do have to calibrate every unit that comes off the assembly line though. The manufacturing tolerances are poor because the soldering affects the parallel resistance too much so no two units have the exact calibration.

Thanks, good confirmation , If they can get 600A, it sounds like I have plenty of headroom for now.
I'm expecting to have to calibrate each controller anyway but that is not hard.
I didn't add parallel copper on the PCB but I should be able to solder a piece of copper on easily enough across the devices legs.

I can see how the manufacturing tolerances creep in when at 600A they need the parallel path to be 1/3 of the 105uR in the device.

 

[texaspyro]

I can see my work bench again!

Take some pics now... it won't last

 

[Arlo1]

Ricky Is this the current sensor you are using? http://www.allegromicro.com/en/Products/Part_Numbers/0758/index.asp 3us responce is pretty good. And I never thought about simply calibrating it... I think I will try this as well. Now to figure out how to run 200amps thorugh it... I guess it wont matter if its 200 amps at 12 volts or 200 amps at 100v so if I can use some auto parts to put a load on the bus bar....

 

[Ricky_nz]

Ricky Is this the current sensor you are using? http://www.allegromicro.com/en/Products/Part_Numbers/0758/index.asp 3us responce is pretty good.

Yes thats the one. I'm using the +/-200A bent leg one.
It is quite a nice sensor and a bit faster than their earlier model too.

And I never thought about simply calibrating it... I think I will try this as well. Now to figure out how to run 200amps thorugh it... I guess it wont matter if its 200 amps at 12 volts or 200 amps at 100v so if I can use some auto parts to put a load on the bus bar....

Yep, just the Amps. the sensor dosen't care about the voltage on the sense side.

I used my controller into an inductor for some current tests early but now its setup for sinewave closed loop its more difficult.
I think for my next calibration I will tweak my software to have an open loop sinewave test mode and externally measure the RMS although a DC calibration would be nice and tidy. DC isn't hard in software so maybe i might do that instead, just needs a high current inductor like i used initially arround the dew bottle!

I was going to use an unmodified sensor in series with a shunted one to provide accurate current readings and run high currents under 200A and look for a difference but until i get round to that I'm using a cheap clamp meter.

I did put one sensor in a box with a battery and voltage regulator and now I have a handy +/-200A current probe for my scope.

 

[Ricky_nz]

I can see my work bench again!

Take some pics now... it won't last

I'm sure you are right but heres a few photos that show a usable amount of desk space.. not totally free but definitly more usable than when i coulden't see more thjan 0.5% of the benches surface :lol:

View attachment 2

plenty of cupboard space but filling rapidly. at least it will start out organised...
Still a small cabinet to move from the center of the room but this is an attempt to keep my hobbies out of the lounge and dining room!

At work we are ment to have a clean desk policy but that is not very compatible with engineering :lol:

 

[incememed]

Ricky, nice to have you back! I'm building my own controller, and I learned a lot from this thread, rock solid advice. No Mountain Dew in Sweden though, but I did manage to find something that works

 

[Ricky_nz]

Ricky, nice to have you back! I'm building my own controller, and I learned a lot from this thread, rock solid advice. No Mountain Dew in Sweden though, but I did manage to find something that works

Thanks, Pleased its been a help.
I'm just starting to get me head back into the software again after the kitchen distraction.
I will probably turn the controller on for the first time in a month or so tomorrow so I can get the PC app talking to it better now I have decided how to fix a threading issue that occurred due to the way I was using QT then I might get back to the embedded code.

It is nice being able to see my work bench again which makes it so much easier to want to work on the project .

 

[Ricky_nz]

Its been a while since my last update.
PC App
I have rewritten the comms back end of my PC tool and solved the multi threading issues I had with the original hacked up comms. It seems quite stable now. I'm just tidying up the parameter display but I can now enter parameters from the GUI and now that they get into the board. I have a parameter that can start and stop the motor so i used that as a test and another that sets the maximum speed to ramp to so all looks good. Just need to add the code to undo the per unit values back to real voltages and currents.
The comms is working either over usb or over the serial port through a level converter.
I have also made a few structural changes to the embedded code to work better with some comming changes in my PC app.

Test setup
Just organised to borrow 4 x 12V 55Ah spiral wound Lead acid batteries as a temporary power supply for testing my motor controller. I mentioned I was thinking of buying a second lithium pack to aid in testing and a mate had access to these so it should make testing a bit easier ( I was getting sick of sharing my meanwells between charging my bike and the test setup and they are a bit low on current). It means I can delay the second lithium pack until i have a bike ready.
I am not stupid enough to put the lead anywhere near a bike. They are just as a stationary test supply.
Since these are real beasts of batteries used in ESS/UPS systems they can really dish out the amps I definitely wanted a circuit breaker so have borrowed one for now. Its only rated at 20A but D curve so should allow some significant current before tripping for short periods. Its all that my mate could find for now but it will get me started at zero cost.

Its 3 poll 415VAC rated so using 2 polls in series it is safe for 48V DC with plenty of margin.
I could of course use all 3 polls if I'm paranoid.
Its also got a reasonable high breaking capacity of 15kA.
I might buy a higher current breaker later.

I'm thinking I might buy a small Chinese hydraulic crimper to make up the battery leads for the test setup because I've been meaning to get one for a while as crimping large lugs by squashing in a vice until they won't squash any more works but sometimes creates cracks in the lugs and doesn't always look the best. I could use one at work but the cable assembly part is in a different building down the road from where I work and it would be handy to have one at home. It would also satisfy my need to buy tools :lol:.

I need to come up with some form of load for the motor. I'm not keen on a prop because it isn't a representative load and not very safe either. I found out today that a few months back work had thrown out an old 5KW eddy current brake in a clean out. Bugger, that would have been handy. I guess I'll have to find something else .

 

[amberwolf]

Those are the same manufacturer as the breaker/switch on CrazyBike2, though mine is designed for DC 24V IIRC, at 100A. (are yours made in France, too?)

 

[Ricky_nz]

Those are the same manufacturer as the breaker/switch on CrazyBike2, though mine is designed for DC 24V IIRC, at 100A. (are yours made in France, too?)

Yep, its got made in France printed on the end.

 

[John in CR]

It would also satisfy my need to buy tools :lol:.

Temporarily anyway.

Keep up the good work. You've got a healthy group spread across the globe supporting your efforts. You and others like you working toward better controllers need only only ask if you need anything more than just the moral support we've been providing.

Have a great holiday season!

John

 

[AussieJester]

^^ huge plus one!!! well said John

Keep up the outstanding work Ricky... :: thumbs up::

KiM

 

[Ricky_nz]

It would also satisfy my need to buy tools :lol:.

Temporarily anyway.

Too true :lol:.
you can never have too many tools.

Keep up the good work. You've got a healthy group spread across the globe supporting your efforts. You and others like you working toward better controllers need only only ask if you need anything more than just the moral support we've been providing.

Have a great holiday season!

John

Will do, Hope you have a good holiday season too John.
That reminds me I better book a couple of weeks off work...
The end of the year is approaching way too fast.

 

[Ricky_nz]

^^ huge plus one!!! well said John

Keep up the outstanding work Ricky... :: thumbs up::

KiM

Thanks for the encouragement . its great, it keeps me motivated .
I just need to get on and write some code.

 

[texaspyro]

I've got a set of those Sino-Crushers... they do work, but the crimping dies are not sized correctly... beware of what is printed on them vs what the real world is. Also, they don't tend to make neat hex shaped crimps even when sized correctly. You tend to get lug material extruded into the gap between the dies.

 

[Ricky_nz]

I've got a set of those Sino-Crushers... they do work, but the crimping dies are not sized correctly...

Thanks. I'm still looking at the options but i guess anything has got to be better than squashing in the vice :lol:.
Usual story at the end of the year. Too much to do and not enough time.
Made worse by urgent stuff at work. Why is it the damn salesmen always line up deliveries of new stuff around Christmas?

I've had a fairly productive week though .
I have got enumerated parameters and scaling of parameters based on other parameters working so now.
This means I can set things like DC bus max voltage in volts rather than 0.65 etc. This makes the rest of the embedded development much more comfortable to debug and setup etc. I still need to scale the limits from per unit to the correct units but thats easy now the hard parts done.
It seems simple but getting parameter lists from the embedded code and using them to change real parameters takse a lot of behind the scenes code

I have also written a basic driver to support an incremental encoder as an optional angle source and also have some preliminary code to estimating the rotor angle from standard digital halls but these are all optional as the main goal is sensor less. I haven't had time to set things up to test these yet other than that they compile and that their parameters show up and are adjustable from the config app.

I think having an angle reference available will be handy for testing the sensor less operation.

Heres a short video demoing the app so far. No sound... I should have had a mic so you could hear the motor start and stop based on gui commands. oh well next time .
[youtube]C1Ua7_CuESg[/youtube]

 

[amberwolf]

If you decide to do future revisions to the controller, would you consider adding analog SIN/COS encoder input, so that it can be run on motors that use that rather than the typical 3-hall configuration, but that don't run well sensorless (or don't start up under load properly/in the right direction when sensorless). (I only did a quick search of each page in the thread but didnt' find any info on SIN/COS input encoding in previous posts).

As two examples currently being used, Liveforphysics' current commuter bike uses SIN/COS position sensing, with an external encoder added to his motor to keep the sensors out of the hot motor. My powerchair motor (testing in progress) is designed with SIN/COS position sensing (I've added standard halls so that I can use it with a typical 12FET ebike controller for now).

According to Liveforphysics, the position sensing would be much more accurate with the SIN/COS vs typical halls, though I don't know if that matters for our purposes.

It's possible that your controller is smart enough in sensorless operation that it doesn't need to worry about it, but just as a potential thought....


It would take two analog inputs (or one muxed really fast between the signals) to monitor the SIN and COS encoder outputs from the motor, and I don't know what additional processing or setup.

 

[Ricky_nz]

If you decide to do future revisions to the controller, would you consider adding analog SIN/COS encoder input, so that it can be run on motors that use that rather than the typical 3-hall configuration, but that don't run well sensor-less (or don't start up under load properly/in the right direction when sensorless). (I only did a quick search of each page in the thread but didn't' find any info on SIN/COS input encoding in previous posts).

I haden't thought too much about sensor types previously, I imagine it wouldn't be too hard to add sin/cos support. I have a few spare ADC inputs that can be used.
A small hardware hack (confined to the power board) to move the DC bus voltage sensing to a slow speed ADC input which wouldn't cause too many issues would free up 2 high speed ADCs that are guaranteed to be sampled at the same time which would be ideal for the SIN/COS inputs. I would need to be careful as to when the conversion was triggered relative to everything else going on and make small corrections based on RPM and sample time for maximum accuracy.

I wonder how expensive the SIN/COS sensors are compared to decent incremental encoders. The sin/cos inputs would be nice in that you don't have to look for an index pulse after a cold start. I know the incremental encoders seem to get really expensive at higher pulse counts. I have got a 512 pulse one here to play with but ideally more pulse counts would be useful for better accuracy of the angle.

Sensor-less is definitely the final goal but at the same time I want to get it running on a bike.
Having sensors available for comparison with the performance of sensor-less algorithms is also a good way to check their performance.
I can look at internal signals within the software to compare calculated angle with the real angle from a sensor etc.

edit: just found a useful link
http://www.avtronencoders.com/encoder_vs_resolvers.htm
The link mentions resolvers that have sin/cos outputs but there also appears to be sin/cos sensors based on 2 axis hall effect sensors and a magnet which sounds cheaper than a resolver.

 

[Alan B]

Luke's sin/cos encoder involved putting a magnet into a machined pocket on the motor shaft, so it sounds like hall type.

 

[Ricky_nz]

Ahh good to know, certainly worked well for Luke. Sounds similar to the one mentioned in this link http://www.sensorsmag.com/sensors/position-presence-proximity/angular-position-sensing-with-2-axis-hall-ics-785.

I wonder where I can get a hold of a hall based one fairly cheaply to play with...
If they are cheap enough it would be a great way to make the Turnigy 80-100 or bigger motors bulletproof to drive especially if its easy to mount on the unused end of the shaft.

The correct alignment to start with shouldn't be too bad either as I think running the motor open loop and unloaded should give a pretty good indication of phasing. The software could automatically calculate an offset so you could just mount the sensor, run the calibration mode and then from then on you would be all set.

 

[Alan B]

They timed it with a scope.

The magnet might be large for the small Turnigy shaft, but could be fixed with a shaft collar perhaps.

 

[amberwolf]

I wonder how expensive the SIN/COS sensors are compared to decent incremental encoders. The sin/cos inputs would be nice in that you don't have to look for an index pulse after a cold start. I know the incremental encoders seem to get really expensive at higher pulse counts. I have got a 512 pulse one here to play with but ideally more pulse counts would be useful for better accuracy of the angle.

The ones in my powerchair motor are just plain linear halls, Honeywell SS495A. They're about two bucks at Mouser.
http://www.mouser.com/Search/ProductDetail.aspx?qs=%2Ffq2y7sSKcKEzWT94S3drA%3D%3D

http://www.endless-sphere.com/forums/viewtopic.php?p=486263#p486263
They're triggered by a magnetic ring inside the central bolt-plate for the rotor, just outside the rotor end of the shaft. I presume this is where the pulse count comes from, by the number of "poles" in the magnetic ring?

Since PC case fans and often floppy drive motors, etc., also usually use a magnetic ring for position sensing, you could probably take one of those rings off of them and install it on your test motor, then just mount some linear halls in whatever experimentally-determined positions give you a SIN and COS output from that ring. I don't know how many "poles" each ring has; probably a lot less than you'd really want, but possibly enough to at least work with the feature idea.

There is also an EEPROM on there, which has a data and a clock line running out to the external connector, but I have no idea what it does yet; I needed to first find a way to spin the motor under easy control (which meant adding my own halls to it for an ebike controller) and then I can analyze the output of the SIN/COS halls plus the EEPROM lines, to figure out what it is supposed to do.

I can't read the p/n on the EEPROM itself; I only know that it is one becuase that's what the datasheet on the motor calls two of the pins on the motor connector, and they lead to that board.

So far I have only gotten to test that the SIN/COS halls do work and do output analog signals, and are correct relative to each other.
[youtube]xlEFwQAygYM[/youtube]

Adding my own halls gets me this timing:

between the phase (top) and the hall for that phase (bottom); I havent' yet tested the SIN/COS relative to either of those; perhaps tonite or tomorrow I might be able to.


I like the idea of just setting the offset in the controller firmware, vs having to physically align the sensor with the motor's phases, especially if it is possible for the controller to "auto learn" where it should offset to.

 

[Ricky_nz]

The ones in my powerchair motor are just plain linear halls, Honeywell SS495A. They're about two bucks at Mouser.
http://www.mouser.com/Search/ProductDetail.aspx?qs=%2Ffq2y7sSKcKEzWT94S3drA%3D%3D

http://www.endless-sphere.com/forums/viewtopic.php?p=486263#p486263
They're triggered by a magnetic ring inside the central bolt-plate for the rotor, just outside the rotor end of the shaft. I presume this is where the pulse count comes from, by the number of "poles" in the magnetic ring?

Interesting, I think I see how yours motors sensor works. I'm guessing that that magnetic ring has pairs of N and S poles spaced around its perimeter that exactly match the spacing of the poles on your motor. That way you would get the sin/cos from the 2 sensors 90deg apart that tracks the electrical rotation of your motor rather than the shaft rotation. Ideally you would always use a ring that matches the number of poles in the motor but since once its in software the choice is probably less of an issue as a simple multiply can fix things.

The data I was looking at shows a disc magnet with half of its end N and the other half south and with that on the end of the shaft and sensing with a 2 axis device you can get 2 sinewave outputs. so kind of the same thing. The single N/S pair of the end mounted version would be good in that although it would output 360deg for one physical rotation of the motor shaft that can especially be multiplied up in software to account for the number of poles to give the angle of the electrical rotation.

It looks like the sensor ICs for this are available from digikey too (MLX90316EDC-BCGCT-ND etc ) but more expensive than the ones used in your motor. They do however appear to offer digital outputs (spi etc) which could be interesting too.
A nice integrated unit would be good but mounting a small chip on a PCB with a voltage regulator and arranging that to be mounted spaced a small distance from the end of the motor shaft with attached magnett doesn't seem too hard either.

At least its not looking outrageously expensive although I have no doubt that to buy a robust industrial grade packaged sensor would be pricey they are probably way overkill for what we need anyway.


Edit: The MLX90316 appears to be too slow but I haven't looked into it too much.

 

[Arlo1]

I'm guessing that that magnetic ring has pairs of N and S poles spaced around its perimeter that exactly match the spacing of the poles on your motor. That way you would get the sin/cos from the 2 sensors 90deg apart that tracks the electrical rotation of your motor rather than the shaft rotation. Ideally you would always use a ring that matches the number of poles in the motor but since once its in software the choice is probably less of an issue as a simple multiply can fix things.

The data I was looking at shows a disc magnet with half of its end N and the other half south and with that on the end of the shaft and sensing with a 2 axis device you can get 2 sinewave outputs. so kind of the same thing. The single N/S pair of the end mounted version would be good in that although it would output 360deg for one physical rotation of the motor shaft that can especially be multiplied up in software to account for the number of poles to give the angle of the electrical rotation.

It looks like the sensor ICs for this are available from digikey too (MLX90316EDC-BCGCT-ND etc ) but more expensive than the ones used in your motor. They do however appear to offer digital outputs (spi etc) which could be interesting too.
A nice integrated unit would be good but mounting a small chip on a PCB with a voltage regulator and arranging that to be mounted spaced a small distance from the end of the motor shaft with attached magnett doesn't seem too hard either.

At least its not looking outrageously expensive although I have no doubt that to buy a robust industrial grade packaged sensor would be pricey they are probably way overkill for what we need anyway.


Edit: The MLX90316 appears to be too slow but I haven't looked into it too much.

I think there is a few good advantages here. For one with less magnet polls for it to sense (lower e-rpm) It will work great at high speeds. For two its out of the heat of the motor. And for 3 your timing will be 100% the same for all three phases. With shoving hall sensors in between stator teeth its easy to get them off a bit for instance when I did colossus I found there was a chance someone could place them off by 1 deg each way so in that motor it would be 10 e-deg which means big problems if you get one off 10 deg + and one 10 deg - that will lead to a pass though event on a not so smart controller. And on any controller that's going to be rough timing!

 

[fechter]

Once the motor gets going above a certain speed, sensorless seems to work fine, but I don't think you will ever get it to work as well as sensored at startup and low speeds.

All the high end motors that work well seem to have some kind of shaft encoder.

A self-calibration mode would be really great. Something that constantly calibrates (if that's possible) might even be better.

It would be nice if there was a way to use the motor magnets to drive the sensors. With linear hall sensors, there would be a tendency to saturate the sensor so some kind of pole piece (iron) may be needed to reduce the flux at the sensor. Also, I'd think the sensors (or end of the iron piece) would need to be relatively far from the magnets in order to get something that resembles a sine wave. If the sensor is too close, it will look more like a trapezoid or even a square wave. If the sensor distance is roughly the same as the magnet width, it may look sine-ish. I guess if you hooked up a sensor to a scope and held it close to a running motor, you could experiment with placement and get an idea of the waveforms.