Quote:
Originally Posted by MPaulHolmes
I have learned 1000 ways how not to make a light bulb. haha. Trying a couple more things out. I think my "filtering" idea and assuming that current and voltages and derivatives are perfect sine waves is sufficiently wrong as to make it not work stably.
With respect to code organization, Maybe we could have it both ways. The code does need to be broken up into separate files that are organized according to what they do, just to make things easier to follow. The "main" file is over 2000 lines long at the moment. Maybe there could be a file designated "encoder induction FOC" that has a bunch of functions. Then, another file that has "sensorless induction", and another file that is "encoder permanent magnet", and one that is "resolver permanent magnet", etc... or something to that affect, and you could link all the files if you want, or leave off a file or 2 if you want and it wouldn't affect compilation?
|
Paul - exactly what I was trying to get at.
danibjor - back when I was first learning to program, (Attempting games like Astroids on a Commodore "CBM") I made code that, um, worked with all sorts of "If" and "goto" type statements that jumped all over the place. Fortunately, it was only me who used that code, and I could barely follow it after a while. Another way to make unreadable code is to rely completely on interrupts. That can even confuse the computer if you're not careful.
Also, we don't have all the MIPs we want. Paul is doing some amazing programming to reduce the amount of CPU cycles used in critical functions. This philosophy of respecting the limited resources is very wise, IMHO. This is where jumping around with multiple "IF" statements can squander criticle CPU cycles that were carefully saved in another part of the program.
The program does not have to be broken into different programs - that's just one way of accomplishing this. Another option would be to break the jobs into separate functions ( Like Paul is saying ). If you don't need to deal with slip because you're running a synchronous motor, the program can simply ignore the rotor flux speed and rotor flux angle functions. If you have an encoder and you need the rotor position, there's a function for that - different, but with similar output from the resolver position function.
If a person wants to add some custom capability to their code, it would be relatively do-able because it could be added as a function.
All that is really required is organizational: How variables are shared; what variables are used, timing priorities, etc.
- E*clipse