Not simple BLDC controller It RUNS! :)

texaspyro said:
Write it in C... assembler is SOOOO last millennium. You should not have any problems at all with performance.
Click to expand...

I'm a fan of assembler :D something about splitting an algorithm into tiny tiny little
elementary pieces appeals to me. C is so simple with this respect.
C is horrible, you have to think of all those variable names, type all those special
characters, lot's of commands I never heard of, define procedures and functions etc etc.
Assembler only has a few simple instructions. I like simple :D probably 'cause it's reflective
of my character :roll:

C is hell on earth :evil:

if it has to be C I quit :shock:

Seriously though, If you want to convert all my assembler programs to C and post them here, be my guest :D
 
This is as it should be! Each corner of the globe to their own language... now where did I put the dsPIC compiler for Fortran4?
 
How about writing it in COBOL.... :twisted: Or, even better, how about RPG? I know a guy that wrote a Fortran compiler in COBOL. I heard that he has since become a mass murderer.

BTW, my friends definition of hell is... COBOL programmer for Dairy Queen... believe me... he knows!
 
Njay said:
Lebowski said:
C is for little girls
Click to expand...
Click to expand...

If he can't handle C, he is a retarded litle girl... :lol:

C has far less operators than any assembler has instructions. C functions are the same as assembler subroutines (but work a lot better). Named variables are a WHOLE lot better than trying to keep track of what is in what register. Buckle down and spend a couple of weeks learning C... youl'll never look back. There is a reason over 95% of all programming is done in it (or it's demon bastard mutant freak abortion of a love child, C++)

I've been programming for over 40 years and am fluent in hundreds of languages. In the last 10 years, I've only written a few hundred lines of assembly code (almost all was inline assembler in C programs) I wrote a few hundred thousand lines of (bug free!) code in C last year. Try that with any assembly language.
 
Leb, seriously you might consider texas's prodding's if you are starting on this journey. What I love about C is the modularity ease of use, and cross platform capability, say when changing micro's from dsPIC's to Cygnal parts. I still write a bit of assembler, but only when absolutely needed and it can be put in line in C. It took me a while to learn C and I have to admit I still don't get the overloading of operators and all the sophisticated stuff. But I sure like snipping some code I wrote 4 years ago and using it on another platform.
 
Overloading of operators is probably that C++ stuff Texaspyro was talking about.

I don't think we should recommend "C" for Leb. He has clearly indicated his preference and we should respect that. We each have our own experiences, but part of this journey is getting to choose how we do it - be it the micro or the language.

Assembler will take a lot longer to get done, and it will have a lot more nagging bugs that pop up later on, and I would not choose it, aside from the occasional special purpose inline code for C. But I respect Leb's desire to do so.
 
Alan B said:
Overloading of operators is probably that C++ stuff Texaspyro was talking about.

I don't think we should recommend "C" for Leb. He has clearly indicated his preference and we should respect that. We each have our own experiences, but part of this journey is getting to choose how we do it - be it the micro or the language.

Assembler will take a lot longer to get done, and it will have a lot more nagging bugs that pop up later on, and I would not choose it, aside from the occasional special purpose inline code for C. But I respect Leb's desire to do so.
Click to expand...

But we should prod him mecilessly with a pointy stick, all the same. :twisted:

When it comes time to port the code to a new ultra-swoopty processor, you will really kiss yourself all deep-tonguey for the decision to code in a portable high level language.

As far as C++ is concerned, bleh! There was a company that was forced to develop an embedded system in C++ because that was what their dictator of engineering heard was "The Thing to Do". Their code compiled into 300K and their processor supported 256K. They stripped out half the functionality and got it to fit. Then they learned about the pitfalls of C++ garbage collection in time critical systems. I got called in to fix things. Spent a week or so converting the code to plain C, added back in all the stripped out functionality, and every thing fit in less than 64K of space. And no more timing glitches. Besides, C++ syntax just plain offends my highly refined sense of coding beauty :roll:
 
My love of assembler actually comes from the 1980's, as a 13 year old I was writing games in assembler
for the Z80 (in a Sinclair ZX Spectrum). I learned C a few years later when I got a Commodore Amiga
but never liked it, so much typing ! My all time favorite programming language is 'G' (as in Labview)...
with assembly a very close second.
 
Just wondering... How many people interested in this controller are running Ubuntu ? Do you have Labview 6.1 under
Ubuntu (for displaying graphs from real-time data from the 30F) ? Or are you limited to windows ? What graphing program
would you use under windows ? Do you have a PICKIT3 or (older) PICKIT2 for programming the 30F ? Would you be willing to switch
to the 40 pins DIP 30F4011 I'm using ?

I'm using all free software (Ubuntu Linux, MplabX for PIC programming, GtkTerm for RS232 communication, Labview 6.1
for plotting real-time measurement data). Maybe dedicate an old PC for this project and install all this software there ?
Would you be willing to switch to my all-Ubuntu setup ?

Trying to determine how usefull it is to keep posting my programs so people can re-create my experiments on their own motor setup.
When you would use the same PC setup as me you can also re-use my graphing programs etc etc.

I'm busy with RS232 interface routines now but will soon switch to hall-sensor / back-EMF measurements (with graphing data
out over RS232, that's why I'm asking about graphing programs available)

P.S. after being shafted with Vista my hate for Windows is even larger than my dislike for C :D especially for this engineering stuff
 
You could put together a vmware image with ubuntu and all the tools preinstalled and configured. People could test it with the free vmplayer. It would be large but you could share is as a torrent. Maybe you would convert someone.

LabView 6.1 is very old and not free software (it free as in free beer, not free as in freedom). If you just want graphing why not try one of the matlab clones like octave or scilab?

Dumping on Vista is kind of old. Windows 7 is eons better and for many of us it is good enough to get the job done. I personally avoid putting emotions or religion into the tools i use. I like Linux and use it for some things but most of the time I dont have the time or patience with the tinkering that it still requires. Windows usually works right out of the box. Not because it is technical better in any way, it is just better supported by vendors and if all you need is something that will run you browser in a snappy and reliable way is is fine.
 
I would choose Python as much as possible, C for realtime and glue, Assembler where absolutely necessary, make it work on Windows 7, Ubuntu and MacOS (Python is incredibly portable with little or no effort).

This project is going to be a lot of work, so you should choose something that you like, and are willing to work hard in. The total effort is pretty nearly proportional to the number of lines of source code, so choosing a language that does a lot with each line saves a lot of work not just writing but re-writing, debugging, documenting, etc.

If you have not done realtime in "C", it is a bit different from "C" on something like windows. Embedded C is a lot more fun, close to the hardware. You can look at the assembler that the compiler generates. In most cases it is better assembler than people write. The GNU compiler is amazing on the AVR.

Python is nice and clean and there are good graphing packages for it. It is gaining foothold in the scientific community in a big way, so there is a lot of good support for it in the graphing area.

If you want others to use your stuff then Python and C will encourage that, but Labview and Assembler will discourage it.

But if you don't choose something you want to work in then the project will likely not finish.

Choose wisely.
 
I do roughly the same as you Alan. But instead of python I use TCL (a bit slower but also more productive). Anyway, a scripting, or very high level language; any.
GCC really does a wonderful job on AVR, and I use the generated assembly ("assembler" is the assembly translator application, "assembly" is the language) to learn how help it do an even better job in space tight projects. Here's an example of what can be done on 99.99% C on 2KB program memory AVR (0.01% is a nop I needed to insert).
 
Hey guys, perhaps I told it in another thread, but I repeat it here:
the good news is that you can download a standard free motor controller developer kit
with C source code for the STM8S chip from the ST website... 8)

It is nothing incredible, but I found some 'infineon like' controllers using that chip
and code around on ebay .... I bought one and it is working fine ... :mrgreen:
Perhaps you can find some good tips and ideas to steal from that code too ... :D
... the good point is they give sensored and sensorless code versions ... and my sensored
controller I play with is working fine even without halls attached ... :shock:

Quite curious about your plans with the power stage :?: :?: :?:
Have you already selected the drivers and power mosfets ? :idea: :idea: :idea:

have fun!
 
zEEz said:
Hey guys, perhaps I told it in another thread, but I repeat it here:
the good news is that you can download a standard free motor controller developer kit
with C source code for the STM8S chip from the ST website... 8)

It is nothing incredible, but I found some 'infineon like' controllers using that chip
and code around on ebay .... I bought one and it is working fine ... :mrgreen:
Perhaps you can find some good tips and ideas to steal from that code too ... :D
... the good point is they give sensored and sensorless code versions ... and my sensored
controller I play with is working fine even without halls attached ... :shock:

Quite curious about your plans with the power stage :?: :?: :?:
Have you already selected the drivers and power mosfets ? :idea: :idea: :idea:

have fun!
Click to expand...
Right now I have ~100 4110 mosfets for ~50 4115 mosfets 1 vmm650-100 100v 680 amp megafet and 7 1200 amp 1200 volt igbts. So the plan is to make it scalable and the power stage built separately! I want to be able to use this controller for everything! My first mission is colossus!
 
Arlo1 said:
Right now I have ~100 4110 mosfets for ~50 4115 mosfets 1 vmm650-100 100v 680 amp megafet and 7 1200 amp 1200 volt igbts. So the plan is to make it scalable and the power stage built separately! I want to be able to use this controller for everything! My first mission is colossus!
Click to expand...

Hi Arlo, great news! perhaps I'll get a Colossus in few months :mrgreen:

Regarding the power stage a modular one is obviously the right option, :lol:
but I see you face the same problem I got ...
even a 3xHiperFET is only equivalent to a 18 mosfet 4110 controller ... :roll:
...the igbt has absurd resistive losses when used at low voltages ... :roll:
... so if you stay between 100 and 150v you are set back to to220 and to264 ... :evil:
SAD STORY!!!!

have fun!
 
Yup this is part of the reason i want fets for 200v. If i run collossus at 150 v and wind it for 50rpm/volt it will have 2x the inducrance which is alot easier on a controller and will still rev to 7500rpm so it will get into its peak efficiency @~6000rpm under load!
 
If I understand Arlo's Goal Just getting a controller that does not blow up is the useful thing gained, but it seems cooling this controller might be a task.

Arlo good luck with this project.

Stephen
 
I understand the 200v fet story and rewinding to achieve human behaviour of the Colossus :mrgreen:

But I cannot get why you want to develop your own controller software instead of profiting to
use a well established 'infineon' controller pcb with modified driver part to extract the logic
level signals deemed to operate the drivers and mosfets on your custom heavy duty power board .... :p

I think an 'infineon' software is more than ok for an average controller to test your power stage :oops:

Have fun!
 
Alan B said:
So we have:

E = L x di/dt

We double E, and double L so di/dt is the same.

Plus the FETs have increased R.

Have we gained anything useful there?
Click to expand...
I dont have 200 volt fets i asked you to find a awesome fet rated to 200v with the same specs you posted for the fets with 75v limit! (this was on another thread for those who are wondering what im talking about).
I have blown up 3 24 mostfet infinieons and 1 18 fet as well as replaced all the blown fets on all these controllers and blew them up a couple more times. I can get this motor to run with external Inductors on a 24 fet at about 5hp with out blowing up but whats the point when lighter motors and controllers can do way better. The chip in the infinion is not the problem its just not a good controller for this, i want power levels at 60kw and beond! Besides i also want to be able to swap a power stage in a minute or two not hours of soldering when it blows or when i want to run a different motor!
 
So if you have a motor with a kv and rewind it for 1/2 the kv then the inductance is 4x. The gains here are controller efficiency and reliablility because inductance is what slows the raise of current flow over time! Meaning less switching losses with more inductance and the motor efficiency stays the same! This 4x slower rise of amps lets the controller have a better shot at limiting the amps with out over shoot as well!
 
Arlo1 said:
So if you have a motor with a kv and rewind it for 1/2 the kv then the inductance is 4x. The gains here are controller efficiency and reliablility because inductance is what slows the raise of current flow over time! Meaning less switching losses with more inductance and the motor efficiency stays the same! This 4x slower rise of amps lets the controller have a better shot at limiting the amps with out over shoot as well!
Click to expand...

OK so there is some gain. But not 4x. You are going to double the voltage and 4x the inductance, so your current rise won't slow by 4x but only by 2x. Still an improvement. But the high voltage has many problems that come along with it including potential death. Of electronics, insulation, and the technician.

Problem is, 200V FETs are not so good. Physics is the problem. Not easy to overcome. The have to add layers, or make things thicker to handle the higher voltage and these things hurt the on resistance and speed of the FET. Not good at all.

Probably better to split the windings and use two controllers. Stay in the sweet spot for the 4110's or whichever great FET you choose. Or split windings even more and use three, four or five controllers. Really one controller with multiple power sections. That is likely a better approach. Parallelism works, just like modern computers. Not many engines made with only 3 cylinders.
 
I have already sugested that in this thread, and it might happen! But..... I realy dont think 4110 fets are right for the job and this motor needs 6000-7000 rpm to get to its efficiency peak!!!! If you are afraid of voltage over 100v then this is proly not a motor for you. Look at what the oem auto companies are doing with voltage levels! There is a reason for the higher voltages!
 
Sure there is a reason for high voltage, we used 12KV feed on our bigger motors. They idled at 200 amps. There is significant engineering in high voltage systems.

Make sure you are aware of and adhere to all electrical safety regulations for your high voltage ebike. If someone touches it and dies you will have significant problems.

Many issues with high voltage are proportional to the square of the voltage, so it is possible to get into a lot of trouble very quickly by raising the voltage. Get used to blowing parts, and working with much higher values of on-resistance, special parts, significant heat dissipation, big heatsinks, fans, low conductivity water or oil cooling, etc that come with the territory.

Electric propulsion for a car is a problem of a completely different scale than an ebike.

We recently had a 2 megawatt power supply manufactured and installed at our facility by a vendor with years of experience with this technology. During testing they blew up a set of IGBTs worth many thousands of dollars. Even experts have trouble with these designs. Expensive trouble.

Good luck with your project.
 
You must log in or register to reply here.
Back
Top