Go Back   EcoModder Forum > EcoModding > Fossil Fuel Free
Register Now
 Register Now
 

Reply  Post New Thread
 
Submit Tools LinkBack Thread Tools
Old 10-05-2015, 03:47 PM   #2131 (permalink)
Permanent Apprentice
 
Join Date: Jul 2010
Location: norcal oosae
Posts: 523
Thanks: 351
Thanked 296 Times in 213 Posts
Yea!

I got my PICkit3 and it talks to my MPLABv8.92 on my not-so-ancient cumpooter!

Now to see about that blinky light...

- E*clipse

  Reply With Quote
The Following User Says Thank You to e*clipse For This Useful Post:
MPaulHolmes (10-05-2015)
Alt Today
Popular topics

Other popular topics in this forum...

   
Old 10-05-2015, 06:16 PM   #2132 (permalink)
Permanent Apprentice
 
Join Date: Jul 2010
Location: norcal oosae
Posts: 523
Thanks: 351
Thanked 296 Times in 213 Posts
Yea!

I have a blinky light!!!

Now we can take over the woRLD! BWAH HAA HAA!!

btw,

I downloaded the MPLAB C30 compiler v3.31 to work with the MPLABv 8.92 I'm running.
Right now it's running the "PRO" version as a demonstration. With the pro version, the code is supposedly a lot more optimized than the free version.

To be honest, I didn't notice any difference with my blinky light... should it be blinking faster??

But seriously, Paul - are you running any better compiler? Have you noticed better - or different - performance with the controller based on the C compiler?

- E*clipse
  Reply With Quote
The Following 2 Users Say Thank You to e*clipse For This Useful Post:
MPaulHolmes (10-05-2015), thingstodo (10-05-2015)
Old 10-05-2015, 06:56 PM   #2133 (permalink)
PaulH
 
MPaulHolmes's Avatar
 
Join Date: Feb 2008
Location: Maricopa, AZ (sort of. Actually outside of town)
Posts: 3,832

Michael's Electric Beetle - '71 Volkswagen Superbeetle 500000
Thanks: 1,368
Thanked 1,119 Times in 734 Posts
I think I have the free version. I tend to do some of the optimization sort of things anyway though (unrolling loops, multiply shift instead of divide, inline functions instead of calling a function and returning) so I don't know how much it would improve.
__________________
kits and boards
  Reply With Quote
The Following 2 Users Say Thank You to MPaulHolmes For This Useful Post:
e*clipse (10-05-2015), thingstodo (10-05-2015)
Old 10-05-2015, 08:27 PM   #2134 (permalink)
Permanent Apprentice
 
Join Date: Jul 2010
Location: norcal oosae
Posts: 523
Thanks: 351
Thanked 296 Times in 213 Posts
Ok, now the blinky light is under control of the throttle.

So, I guess I have a good enough handle on things to do some useful work.

What do think about having a stripped-down "base" code that works with the current hardware. This idea came as I thought about stripping "sensorless.c" down to a "senseless.c" This is to assist my little noggin' in seeing the big picture.

This code would put out a sinusoidal PWM signal and measure current and throttle position. Perhaps other features, like contactor control, and other AtoD measurements could be built into this core.

It would be considered a solid foundation on which to build features like FOC and sensorless control. The base sinusoidal output would use a look-up sin table, with the frequency set in a volts/hz mode.

Hopefully I haven't suggested anything new here - it seems to be operating a little bit like this even under the newest sensorless code.

The new features, like sensorless control could be added as either code within the main or maybe sub-programs in a build.

This might facilitate programming different options, like sensorless code, encoder input, resolver input, FOC for asynchronous motors, FOC for synchronous motors, etc etc...

In fact, if things were done well, a "build" would just have the useful parts for that application. This might save computer time/memory.

Thoughts?

- E*clipse
  Reply With Quote
The Following User Says Thank You to e*clipse For This Useful Post:
MPaulHolmes (10-06-2015)
Old 10-05-2015, 11:55 PM   #2135 (permalink)
Master EcoModder
 
Join Date: Sep 2010
Location: Saskatoon, canada
Posts: 1,478

ChargE (not yet running) - '92 Mazda MX6 LX
90 day: 33.89 mpg (US)

Ford Prefect - '18 Ford F150 XLT XTR
Thanks: 745
Thanked 543 Times in 438 Posts
Quote:
Originally Posted by e*clipse View Post
What do think about having a stripped-down "base" code that works with the current hardware. This idea came as I thought about stripping "sensorless.c" down to a "senseless.c" This is to assist my little noggin' in seeing the big picture.
The FOC control takes care of the voltage output given the requested torque. The signal into a V/Hz controller is, in my experience, a speed reference. The voltage is controlled by an output curve - linear with a starting boost, a curve that approximates a squared curve, a curve that approximates a cubic curve.

Quote:
This might facilitate programming different options, like sensorless code, encoder input, resolver input, FOC for asynchronous motors, FOC for synchronous motors, etc etc...
There are advantages to having 'all' the code the same .. debugging, spare parts ... and there are advantages to 'only loading what you need' ... mostly to do with money and production costs, a simpler setup perhaps ...

The memory and MIPS are cheap. Without further information, I'd stick with 'one program does all'.
  Reply With Quote
Old 10-06-2015, 02:17 PM   #2136 (permalink)
Permanent Apprentice
 
Join Date: Jul 2010
Location: norcal oosae
Posts: 523
Thanks: 351
Thanked 296 Times in 213 Posts
Quote:
Originally Posted by thingstodo View Post
The FOC control takes care of the voltage output given the requested torque. The signal into a V/Hz controller is, in my experience, a speed reference. The voltage is controlled by an output curve - linear with a starting boost, a curve that approximates a squared curve, a curve that approximates a cubic curve.



There are advantages to having 'all' the code the same .. debugging, spare parts ... and there are advantages to 'only loading what you need' ... mostly to do with money and production costs, a simpler setup perhaps ...

The memory and MIPS are cheap. Without further information, I'd stick with 'one program does all'.
I talking about a method of doing collaborative programming. Really, the details of the code don't matter from that perspective. Once the code is compiled, it is "all one code." The background of how that code came together is not available or important to the end user. The end user only loads one piece of ready to run software.

As an example, the previous version of "sensorless.c" had 48 pages of code. I printed out pages 16-37 to get an understanding of how this specific core control works. I have a pretty good understanding of how FOC works in general, and V/Hz as well. In that code, there were 11 pages specifically for dealing with asynchronous motor issues. A lot of that was comments (thanks Paul! ) , so it will be much more compact as compiled code.

Right now, Paul is working hard on getting sensorless algorithm working for an induction motor. That's great, but my interests are quite different - I have an excellent analog sensor on an synchronous motor. So, I was hoping I could contribute by doing a bit more than cheering from the sidelines. I mean, maybe Paul needs some "blinky light" code!

- E*clipse
  Reply With Quote
The Following User Says Thank You to e*clipse For This Useful Post:
thingstodo (10-06-2015)
Old 10-06-2015, 02:37 PM   #2137 (permalink)
EcoModding Lurker
 
Join Date: Sep 2015
Location: Norway
Posts: 11
Thanks: 10
Thanked 12 Times in 7 Posts
As for the microcontroller. The size of the file you upload does not matter (as long as it fits in the space you have).

If you have an IF statement around the asynchronous code - the code does not run on non-asynchronous motors, if you say have config params that define the motor type your are controlling.

Thus, code inside the IF(asynchronous-motor) statements, never run, and thus never use CPU cycles and resources. (other than a single clock-cycle to check motortype in the IF-statement and some minimal amount of ram to store the motor-parameters.

Having an all-in-one solution, like Paul is doing, is the most flexible for the end-user

Edit: got some toys today


Last edited by danibjor; 10-06-2015 at 02:48 PM..
  Reply With Quote
Old 10-06-2015, 03:38 PM   #2138 (permalink)
PaulH
 
MPaulHolmes's Avatar
 
Join Date: Feb 2008
Location: Maricopa, AZ (sort of. Actually outside of town)
Posts: 3,832

Michael's Electric Beetle - '71 Volkswagen Superbeetle 500000
Thanks: 1,368
Thanked 1,119 Times in 734 Posts
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?
__________________
kits and boards
  Reply With Quote
The Following 2 Users Say Thank You to MPaulHolmes For This Useful Post:
danibjor (10-06-2015), e*clipse (10-06-2015)
Old 10-06-2015, 04:17 PM   #2139 (permalink)
EcoModding Lurker
 
Join Date: Sep 2015
Location: Norway
Posts: 11
Thanks: 10
Thanked 12 Times in 7 Posts
Could be a good idea to break things up to make it easier to maintain.

Helper functions and such in apropriate files. Main in one and motor type spesific code in as many as it supports. Just include the correct header file for your motor type, and you are all set to go if you want to compile your own code.
  Reply With Quote
The Following User Says Thank You to danibjor For This Useful Post:
e*clipse (10-06-2015)
Old 10-06-2015, 04:41 PM   #2140 (permalink)
Permanent Apprentice
 
Join Date: Jul 2010
Location: norcal oosae
Posts: 523
Thanks: 351
Thanked 296 Times in 213 Posts
Quote:
Originally Posted by MPaulHolmes View Post
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


Last edited by e*clipse; 10-06-2015 at 05:17 PM.. Reason: spelling
  Reply With Quote
The Following 2 Users Say Thank You to e*clipse For This Useful Post:
danibjor (10-06-2015), thingstodo (10-06-2015)
Reply  Post New Thread


Thread Tools


Similar Threads
Thread Thread Starter Forum Replies Last Post
Paul & Sabrina's cheap DIY 144v motor controller MPaulHolmes Open ReVolt: open source DC motor controller 7350 07-28-2021 05:32 AM
Paul & Sabrina's Cheap EV Conversion MPaulHolmes Fossil Fuel Free 542 11-12-2016 09:09 PM
Contest! Name Paul & Sabrina's controller MetroMPG Forum News & Feedback 120 10-22-2011 01:59 PM



Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2021, vBulletin Solutions Inc.
Content Relevant URLs by vBSEO 3.5.2
All content copyright EcoModder.com