tumanako-devel — Tumanako General Development List

Re: Sourceforge Upgrade

[Tom P. <to...@ca...>]

On 01/04/13 15:02, Tom Parker wrote:
> Some of you may be aware that sourceforge are threatening to turn off
> our hosted mediawiki instance and upgrade the project to their new
> platform.

I got an email saying they're going to start this on active projects on 
the 22nd of April (they've been doing dead projects for a while). They 
don't know how quickly the conversions will go, but it would seem like 
we should at least have an idea of where we want to go before it happens.

Does anyone have an opinion?

Re: Getting closer to tumanako FOC

[Johannes H. <de...@jo...>]

Am 01.04.2013 23:19, schrieb Robin Vobruba:
> i can do that, but i think i need some more info.
>
> the archive contains the lib and the foc folder, but not the sine one.
> where is the latest version of that one?
The sine project is already in the git repo and contains all the files 
in lib. So if it somehow uses the files in lib, they can be deleted from 
the sine project.
https://github.com/tumanako/tumanako-inverter-fw-motorControl/tree/master/src/sine

>
> what do you mean with 'more meaningful renaming'? the folders? (foc &
> lib), or the source file names?
> i guess, you mean the lib folder. but i also think, you would be best to
> choose a more meaningful name.
Yeah, just the lib folder. Still can't think of anything more meaningful 
yet since the contents is very "miscellanious".
>
> do both sine and foc use all the files from lib?
Almost, about 90% share ratio
>
> could it make sense to actually make the stuff in lib a separate
> library, static of dynamic, against which the other two projects link?
>
>
Some files, like the params.c, contain static tables that are build from 
a project-dependend #define. The macro-magic for this is hidden in the 
module.  All others could indeed be built as a static library. I can 
create a list of actually static files if you want.

Re: Convert SVN to git repos

[Robin V. <cz...@su...>]

i applied the patch to the convert script git repo, and i removed the
two repos you mentioned from the github page, and renamed monitor to master.

On 02.04.2013 11:07, Tom Parker wrote:
> On 01/04/13 00:12, Philip Court wrote:
>> Robin, this all looks great to me.  The granularity you have chosen brings
>> every component to the top which is nice.
>>
>> Tom, do you want to comment on the BMS structure before it is 'made so'?  I
>> think it's good, but you should check too...
> 
> Some of the BMS stuff can be left in the svn and not migrated to git. 
> Specifically,
> 
> https://tumanako.svn.sourceforge.net/svnroot/tumanako/trunk/bms/master
> https://tumanako.svn.sourceforge.net/svnroot/tumanako/trunk/bms/slave_backplane
> 
> can be left behind.
> 
> https://tumanako.svn.sourceforge.net/svnroot/tumanako/trunk/bms/monitor_linux 
> should be renamed as master (the original master turned into a dead end).
> 
> This patch appears to do the trick:
> 
> diff --git a/sfNet_svnOrCvs2git.sh b/sfNet_svnOrCvs2git.sh
> index b061948..784b0f8 100755
> --- a/sfNet_svnOrCvs2git.sh
> +++ b/sfNet_svnOrCvs2git.sh
> @@ -44,9 +44,9 @@ DO_SUBREPO_PHASE=1
>   subRepoRoots=""
>   subRepoRoots="${subRepoRoots} bms/web"
>   subRepoRoots="${subRepoRoots} bms/monitor_linux"
> -subRepoRoots="${subRepoRoots} bms/master"
> +#subRepoRoots="${subRepoRoots} bms/master"
>   subRepoRoots="${subRepoRoots} bms/slave"
> -subRepoRoots="${subRepoRoots} bms/slave_backplane"
> +#subRepoRoots="${subRepoRoots} bms/slave_backplane"
>   subRepoRoots="${subRepoRoots} dashboard/TumanakoDash"
>   #subRepoRoots="${subRepoRoots} inverter/fw/qpcpp"
>   subRepoRoots="${subRepoRoots} inverter/fw/motor_control"
> @@ -83,7 +83,7 @@ function createRepoName {
>          subRepoName=tumanako-$(echo "${relRepoPath}" | sed "s#/#-#g" -)
> 
>          # do some cleanup
> -       subRepoName=$(echo "${subRepoName}" | sed 
> "s#monitor_linux#monitor#g" -)
> +       subRepoName=$(echo "${subRepoName}" | sed 
> "s#monitor_linux#master#g" -)
>          subRepoName=$(echo "${subRepoName}" | sed 
> "s#slave_backplane#slaveBackplane#g" -)
>          subRepoName=$(echo "${subRepoName}" | sed "s#-TumanakoDash##g" -)
>          subRepoName=$(echo "${subRepoName}" | sed "s#_control#Control#g" -)
> 
> ------------------------------------------------------------------------------
> Own the Future-Intel(R) Level Up Game Demo Contest 2013
> Rise to greatness in Intel's independent game demo contest. Compete 
> for recognition, cash, and the chance to get your game on Steam. 
> $5K grand prize plus 10 genre and skill prizes. Submit your demo 
> by 6/6/13. http://altfarm.mediaplex.com/ad/ck/12124-176961-30367-2
> _______________________________________________
> Tumanako-devel mailing list
> Tum...@li...
> https://lists.sourceforge.net/lists/listinfo/tumanako-devel
> 

Re: Sourceforge Upgrade

[Tom P. <to...@ca...>]

On 02/04/13 09:56, Robin Vobruba wrote:
> if anyway possible, no matter where you host it, make the wiki available
> under a sub-domain, e.g. wiki.tumanako.net, convert all the links you
> have control over, to that. keep the old links working still, as long as
> possible, if you think that many use them.

Indeed. I moved my own and Phil's wiki from twiki to mediawiki a couple 
of years ago preserving all the history (I really should blog about 
that, I had to write a program to do it which resides in the svn) and 
have a forwarder from the old location to the new one.

I'm not sure how much we can do for the old hosted mediawiki app -- I 
guess we just edit all the pages to say they have moved and link to the 
new location and see how long sourceforge leaves it there.

Thanks for reminding us to remember to put the wiki in a subdomain.

Re: Convert SVN to git repos

[Tom P. <to...@ca...>]

On 01/04/13 00:12, Philip Court wrote:
> Robin, this all looks great to me.  The granularity you have chosen brings
> every component to the top which is nice.
>
> Tom, do you want to comment on the BMS structure before it is 'made so'?  I
> think it's good, but you should check too...

Some of the BMS stuff can be left in the svn and not migrated to git. 
Specifically,

https://tumanako.svn.sourceforge.net/svnroot/tumanako/trunk/bms/master
https://tumanako.svn.sourceforge.net/svnroot/tumanako/trunk/bms/slave_backplane

can be left behind.

https://tumanako.svn.sourceforge.net/svnroot/tumanako/trunk/bms/monitor_linux 
should be renamed as master (the original master turned into a dead end).

This patch appears to do the trick:

diff --git a/sfNet_svnOrCvs2git.sh b/sfNet_svnOrCvs2git.sh
index b061948..784b0f8 100755
--- a/sfNet_svnOrCvs2git.sh
+++ b/sfNet_svnOrCvs2git.sh
@@ -44,9 +44,9 @@ DO_SUBREPO_PHASE=1
  subRepoRoots=""
  subRepoRoots="${subRepoRoots} bms/web"
  subRepoRoots="${subRepoRoots} bms/monitor_linux"
-subRepoRoots="${subRepoRoots} bms/master"
+#subRepoRoots="${subRepoRoots} bms/master"
  subRepoRoots="${subRepoRoots} bms/slave"
-subRepoRoots="${subRepoRoots} bms/slave_backplane"
+#subRepoRoots="${subRepoRoots} bms/slave_backplane"
  subRepoRoots="${subRepoRoots} dashboard/TumanakoDash"
  #subRepoRoots="${subRepoRoots} inverter/fw/qpcpp"
  subRepoRoots="${subRepoRoots} inverter/fw/motor_control"
@@ -83,7 +83,7 @@ function createRepoName {
         subRepoName=tumanako-$(echo "${relRepoPath}" | sed "s#/#-#g" -)

         # do some cleanup
-       subRepoName=$(echo "${subRepoName}" | sed 
"s#monitor_linux#monitor#g" -)
+       subRepoName=$(echo "${subRepoName}" | sed 
"s#monitor_linux#master#g" -)
         subRepoName=$(echo "${subRepoName}" | sed 
"s#slave_backplane#slaveBackplane#g" -)
         subRepoName=$(echo "${subRepoName}" | sed "s#-TumanakoDash##g" -)
         subRepoName=$(echo "${subRepoName}" | sed "s#_control#Control#g" -)

Re: Getting closer to tumanako FOC

[Robin V. <cz...@su...>]

i can do that, but i think i need some more info.

the archive contains the lib and the foc folder, but not the sine one.
where is the latest version of that one?

what do you mean with 'more meaningful renaming'? the folders? (foc &
lib), or the source file names?
i guess, you mean the lib folder. but i also think, you would be best to
choose a more meaningful name.

do both sine and foc use all the files from lib?

could it make sense to actually make the stuff in lib a separate
library, static of dynamic, against which the other two projects link?

On 01.04.2013 22:52, Johannes Hübner wrote:
> Hi!
> 
> sorry for being a bit slow. Currently working a lot on my car. I've 
> uploaded an image of my current development environment at 
> http://johanneshuebner.com/stuff/firmware.tar.bz2
> 
> Theres a folder called lib, the files in it are symlinked to both the 
> sine and the foc project.
> 
> The foc project compiles and I've run a sort of unit test on the 
> foc_step function, but some bits are missing to actually make it run on 
> the controller. Once I figure out git I will update.
> 
> For now, maybe Robin could setup the git structure so that sine and foc 
> use the files in lib? Some more meaningful renaming could also help.
> 
> Thanks,
> Johannes
> 
> On 26.03.2013 00:02, Philip Court wrote:
>> Hi Johannes
>>
>> Sounds great!  More comments below...
>>
>> Cheers
>> Philip
>>
> 
> ------------------------------------------------------------------------------
> Own the Future-Intel® Level Up Game Demo Contest 2013
> Rise to greatness in Intel's independent game demo contest.
> Compete for recognition, cash, and the chance to get your game 
> on Steam. $5K grand prize plus 10 genre and skill prizes. 
> Submit your demo by 6/6/13. http://p.sf.net/sfu/intel_levelupd2d
> _______________________________________________
> Tumanako-devel mailing list
> Tum...@li...
> https://lists.sourceforge.net/lists/listinfo/tumanako-devel
> 

Re: Sourceforge Upgrade

[Robin V. <cz...@su...>]

if anyway possible, no matter where you host it, make the wiki available
under a sub-domain, e.g. wiki.tumanako.net, convert all the links you
have control over, to that. keep the old links working still, as long as
possible, if you think that many use them.
that is the best way to prevent such problems from reoccurring in the
future. it is also better to change to your domain early, then later on
(when you are bigger).

On 01.04.2013 04:02, Tom Parker wrote:
> Some of you may be aware that sourceforge are threatening to turn off 
> our hosted mediawiki instance and upgrade the project to their new 
> platform. It seems like we can migrate to a new mediawiki instance 
> installed on their project webserver but this means a new mediawiki 
> instance to administer. I think even moving to this project web based 
> mediawiki will cause the wiki to move, breaking any links people have on 
> other websites.
> 
> I could move the wiki to my own server, but then we wouldn't have single 
> sign on from sourceforge and we would have to manually administer 
> accounts. Also, my server isn't exactly fast, if we're ever successful 
> it is unlikely to cope with the load. On the plus side it would mean 
> that the http://tumanako.net domain would actually host something 
> instead of redirecting to sourceforge.
> 
> Another alternative is to host it on a VPS somewhere, this is slightly 
> more overhead than the sourceforge project web option but allows the 
> domain name to work and is more likely to cope with increased traffic.
> 
> Does anyone have a better idea?
> 
> ------------------------------------------------------------------------------
> Own the Future-Intel® Level Up Game Demo Contest 2013
> Rise to greatness in Intel's independent game demo contest.
> Compete for recognition, cash, and the chance to get your game 
> on Steam. $5K grand prize plus 10 genre and skill prizes. 
> Submit your demo by 6/6/13. http://p.sf.net/sfu/intel_levelupd2d
> _______________________________________________
> Tumanako-devel mailing list
> Tum...@li...
> https://lists.sourceforge.net/lists/listinfo/tumanako-devel
> 

Re: Getting closer to tumanako FOC

[Johannes H. <de...@jo...>]

Hi!

sorry for being a bit slow. Currently working a lot on my car. I've 
uploaded an image of my current development environment at 
http://johanneshuebner.com/stuff/firmware.tar.bz2

Theres a folder called lib, the files in it are symlinked to both the 
sine and the foc project.

The foc project compiles and I've run a sort of unit test on the 
foc_step function, but some bits are missing to actually make it run on 
the controller. Once I figure out git I will update.

For now, maybe Robin could setup the git structure so that sine and foc 
use the files in lib? Some more meaningful renaming could also help.

Thanks,
Johannes

On 26.03.2013 00:02, Philip Court wrote:
> Hi Johannes
>
> Sounds great!  More comments below...
>
> Cheers
> Philip
>

Sourceforge Upgrade

[Tom P. <to...@ca...>]

Some of you may be aware that sourceforge are threatening to turn off 
our hosted mediawiki instance and upgrade the project to their new 
platform. It seems like we can migrate to a new mediawiki instance 
installed on their project webserver but this means a new mediawiki 
instance to administer. I think even moving to this project web based 
mediawiki will cause the wiki to move, breaking any links people have on 
other websites.

I could move the wiki to my own server, but then we wouldn't have single 
sign on from sourceforge and we would have to manually administer 
accounts. Also, my server isn't exactly fast, if we're ever successful 
it is unlikely to cope with the load. On the plus side it would mean 
that the http://tumanako.net domain would actually host something 
instead of redirecting to sourceforge.

Another alternative is to host it on a VPS somewhere, this is slightly 
more overhead than the sourceforge project web option but allows the 
domain name to work and is more likely to cope with increased traffic.

Does anyone have a better idea?

Re: Convert SVN to git repos

[Philip C. <ph...@gr...>]

Robin, this all looks great to me.  The granularity you have chosen brings
every component to the top which is nice.

Tom, do you want to comment on the BMS structure before it is 'made so'?  I
think it's good, but you should check too...

Also, Johannes, have you committed your new FOC code anywhere yet? I'm keen
to have a look :)

Cheers
Philip


On 29 March 2013 04:25, Robin Vobruba <cz...@su...> wrote:

> so.. is everyone happy with the granularity that i used to split-off the
> repos? for example, that BMS is multiple repos.. should it be a single one?
>
>

Re: Convert SVN to git repos

[Robin V. <cz...@su...>]

so.. is everyone happy with the granularity that i used to split-off the
repos? for example, that BMS is multiple repos.. should it be a single one?

On 17.03.2013 00:24, Edward Cheeseman wrote:
> Could you add my github account to tumanako? I'm evbuilder, just to keep things same as sourceforge
> 
> On 17/03/2013, at 12:18 PM, Edward Cheeseman wrote:
> 
>> And Me!
>>
>> now, onto creating a github user...
>>
>> On 17/03/2013, at 9:21 AM, Bernard Mentink wrote:
>>
>>> Thanks, I can see it now too ..
>>>
>>> Bernie
>>>
>>> On Sun, Mar 17, 2013 at 7:01 AM, Johannes Hübner <j...@jo...>wrote:
>>>
>>>> Yeah, it works now!
>>>>
>>>> Am 16.03.2013 18:50, schrieb Robin Vobruba:
>>>>> https://github.com/organizations/tumanako/ does not work?
>>>>> that's strange... but indeed, it only works when i am logged in! :/
>>>>> that is definitely a bug on github.
>>>>> i now added you as an owner.. i guess you will be able to browse now.
>>>>> i wrote a report to the github team.
>>>>> thanks!
>>>>>
>>>>
>>>>
>>>>
>>>> ------------------------------------------------------------------------------
>>>> Everyone hates slow websites. So do we.
>>>> Make your web apps faster with AppDynamics
>>>> Download AppDynamics Lite for free today:
>>>> http://p.sf.net/sfu/appdyn_d2d_mar
>>>> _______________________________________________
>>>> Tumanako-devel mailing list
>>>> Tum...@li...
>>>> https://lists.sourceforge.net/lists/listinfo/tumanako-devel
>>>>
>>> ------------------------------------------------------------------------------
>>> Everyone hates slow websites. So do we.
>>> Make your web apps faster with AppDynamics
>>> Download AppDynamics Lite for free today:
>>> http://p.sf.net/sfu/appdyn_d2d_mar
>>> _______________________________________________
>>> Tumanako-devel mailing list
>>> Tum...@li...
>>> https://lists.sourceforge.net/lists/listinfo/tumanako-devel
>>
>> Edward Cheeseman
>> Electrical Engineer ME(hons)
>> che...@gm...
>>
> 
> Edward Cheeseman
> Electrical Engineer ME(hons)
> che...@gm...
> 
> 
> ------------------------------------------------------------------------------
> Everyone hates slow websites. So do we.
> Make your web apps faster with AppDynamics
> Download AppDynamics Lite for free today:
> http://p.sf.net/sfu/appdyn_d2d_mar
> _______________________________________________
> Tumanako-devel mailing list
> Tum...@li...
> https://lists.sourceforge.net/lists/listinfo/tumanako-devel
> 

Re: Hello, Everyone

[Philip C. <ph...@gr...>]

Guys, use a dropbox link or similar if you want to attach a file.

On 26 March 2013 23:56, Edward Cheeseman <che...@gm...> wrote:

> Unfortunately Sourceforge strips attachments off.
>
> Grrr...
>
> Edward
>
>

Re: Hello, Everyone

[Edward C. <che...@gm...>]

Unfortunately Sourceforge strips attachments off.

Grrr...

Edward

On 26/03/2013, at 9:13 PM, Edward Pilbrow wrote:

> Hello Paul
> 
> I have a spare second hand but unused Semikron SKiiP 613GD123-3DUW IGBT bridge with bonded NWK 40 water cooled heatsink that may be of interest.  It's one of the biggest they make so definitely won't limit your motor.  I bought 2 originally but don't really need the second one.  I'd be happy to sell for $900.  Data sheets attached.  The DUL datasheet also applies to the DUW version as the only difference is the heatsink.
> 
> Edward
> 
> 
> 
> 
> 
> On 26/03/2013 9:59 a.m., Paul Lackey wrote:
>> Hi, All.  I have been watching this mailing list and reading up on other
>> forums for the past few months, working on trying to get up to speed.  I
>> recently picked up one of those old Ford Siemens motors and am ready to
>> jump in and get my feet wet.  My hope is that I can contribute some good
>> things to this project (and end up with a working controller for my motor
>> too).  Where is the best place to start?  I've browsed through the wiki a
>> fair amount, but it is sometime difficult to tell what is up to date and
>> what is obsolete.
>> Although there is plenty of rust to knock out my ears in terms of
>> programming, I am more concerned in terms of the hardware aspect of things,
>> since most of my power electronics knowledge is theoretical, and I haven't
>> ever done a big project.  Where is the best place to look as far as power
>> stages go?  I certainly do not have anywhere near endless amounts of money,
>> but I also don't really want to skimp on this, as I don't want the motor to
>> be limited by the controller.  Anyway, any advice you guys could give me
>> would be greatly appreciated.  Hopefully I can quickly get up to speed and
>> then be a good contributor to the cause.
>> 
>> Thanks,
>> 
>> Paul Lackey
>> ------------------------------------------------------------------------------
>> Everyone hates slow websites. So do we.
>> Make your web apps faster with AppDynamics
>> Download AppDynamics Lite for free today:
>> http://p.sf.net/sfu/appdyn_d2d_mar
>> _______________________________________________
>> Tumanako-devel mailing list
>> Tum...@li...
>> https://lists.sourceforge.net/lists/listinfo/tumanako-devel
>> 
> ------------------------------------------------------------------------------
> Own the Future-Intel® Level Up Game Demo Contest 2013
> Rise to greatness in Intel's independent game demo contest.
> Compete for recognition, cash, and the chance to get your game 
> on Steam. $5K grand prize plus 10 genre and skill prizes. 
> Submit your demo by 6/6/13. http://p.sf.net/sfu/intel_levelupd2d_______________________________________________
> Tumanako-devel mailing list
> Tum...@li...
> https://lists.sourceforge.net/lists/listinfo/tumanako-devel

Edward Cheeseman
Electrical Engineer ME(hons)
che...@gm...

Re: Hello, Everyone

[Edward C. <che...@gm...>]

Hi Paul,

If you've got a Ford Siemens motor, you'll be looking at a 300V+ battery pack?

Probably best to get a 600V technology module - for a bus that goes no more than say, 450V at peak charge.

The Tumanako SMT32MCU controller has a driver for the SKAi and SKiiP interfaces. Powerex uses a compatible interface too.

Kicad schematics and layouts are in the HW directory (svn or git). Alternately some already made up are available here:
http://shop.greenstage.co.nz/product/kiwiac-stm32mcu
There is also a version with SKAI2 coming.

Other power stages could be something like the following:
http://www.sindopower.com/en/Products-and-Shop/Product-Groups/IPM-SKiiP/SKiiP/SKiiP-613-GD123-3DUL.html
http://www.pwrx.com/pwrx/docs/pp400t060.pdf
You may find GEN1 SKAi's on ebay. Check to see if its the CAN version - if it is, it'll need some reverse engineering to get it to work on an STM32 (it has a TI DSP in it) Dan may keep us abreast of how his experience with the CAN type goes.
Unfortunately we can't confirm whether the newer SKAi's will come in a direct drive input.
I am currently looking into Prius hardware, which seems to be somewhat compatible (nearly all signals voltage compatible) although the power will be limited compared to what the above can do.

Tell us how you get on.

Edward

On 26/03/2013, at 9:59 AM, Paul Lackey wrote:

> Hi, All.  I have been watching this mailing list and reading up on other
> forums for the past few months, working on trying to get up to speed.  I
> recently picked up one of those old Ford Siemens motors and am ready to
> jump in and get my feet wet.  My hope is that I can contribute some good
> things to this project (and end up with a working controller for my motor
> too).  Where is the best place to start?  I've browsed through the wiki a
> fair amount, but it is sometime difficult to tell what is up to date and
> what is obsolete.
> Although there is plenty of rust to knock out my ears in terms of
> programming, I am more concerned in terms of the hardware aspect of things,
> since most of my power electronics knowledge is theoretical, and I haven't
> ever done a big project.  Where is the best place to look as far as power
> stages go?  I certainly do not have anywhere near endless amounts of money,
> but I also don't really want to skimp on this, as I don't want the motor to
> be limited by the controller.  Anyway, any advice you guys could give me
> would be greatly appreciated.  Hopefully I can quickly get up to speed and
> then be a good contributor to the cause.
> 
> Thanks,
> 
> Paul Lackey
> ------------------------------------------------------------------------------
> Everyone hates slow websites. So do we.
> Make your web apps faster with AppDynamics
> Download AppDynamics Lite for free today:
> http://p.sf.net/sfu/appdyn_d2d_mar
> _______________________________________________
> Tumanako-devel mailing list
> Tum...@li...
> https://lists.sourceforge.net/lists/listinfo/tumanako-devel

Edward Cheeseman
Electrical Engineer ME(hons)
che...@gm...

Re: Hello, Everyone

[Edward P. <eat...@gm...>]

Hello Paul

I have a spare second hand but unused Semikron SKiiP 613GD123-3DUW IGBT 
bridge with bonded NWK 40 water cooled heatsink that may be of interest. 
  It's one of the biggest they make so definitely won't limit your 
motor.  I bought 2 originally but don't really need the second one.  I'd 
be happy to sell for $900.  Data sheets attached.  The DUL datasheet 
also applies to the DUW version as the only difference is the heatsink.

Edward





On 26/03/2013 9:59 a.m., Paul Lackey wrote:
> Hi, All.  I have been watching this mailing list and reading up on other
> forums for the past few months, working on trying to get up to speed.  I
> recently picked up one of those old Ford Siemens motors and am ready to
> jump in and get my feet wet.  My hope is that I can contribute some good
> things to this project (and end up with a working controller for my motor
> too).  Where is the best place to start?  I've browsed through the wiki a
> fair amount, but it is sometime difficult to tell what is up to date and
> what is obsolete.
> Although there is plenty of rust to knock out my ears in terms of
> programming, I am more concerned in terms of the hardware aspect of things,
> since most of my power electronics knowledge is theoretical, and I haven't
> ever done a big project.  Where is the best place to look as far as power
> stages go?  I certainly do not have anywhere near endless amounts of money,
> but I also don't really want to skimp on this, as I don't want the motor to
> be limited by the controller.  Anyway, any advice you guys could give me
> would be greatly appreciated.  Hopefully I can quickly get up to speed and
> then be a good contributor to the cause.
>
> Thanks,
>
> Paul Lackey
> ------------------------------------------------------------------------------
> Everyone hates slow websites. So do we.
> Make your web apps faster with AppDynamics
> Download AppDynamics Lite for free today:
> http://p.sf.net/sfu/appdyn_d2d_mar
> _______________________________________________
> Tumanako-devel mailing list
> Tum...@li...
> https://lists.sourceforge.net/lists/listinfo/tumanako-devel
>

Re: Getting closer to tumanako FOC

[Robin V. <cz...@su...>]

how to handle shared files with git:
it depends on the nature of the shared files, and the relation between
the projects. there are 3 possibilities of how to handle them:
1. make the two projects use the same repository, but different branches
2. use git sub-modules
3. make them totally separate

when to use which:
1. (branches) makes sense if the projects are similar, at least in what
they try to solve (like: ... controlling aspect X of an electric motor),
and they have the shared files in the same relative path.
2. (sub-module) makes sense when the shared files have the nature of an
independent library or API-headers or the like. they have to be in a
separate directory, where only files of the sub-project reside, and
where all files are part of the sub-project.
3. (no technical sharing) makes sense if neither of the other two makes
sense.

please ask if something is unclear, or for more practical help.

On 26.03.2013 00:02, Philip Court wrote:
> Hi Johannes
> 
> Sounds great!  More comments below...
> 
> Cheers
> Philip
> 
> On 26 March 2013 09:41, Johannes Hübner <j...@jo...> wrote:
> 
>> Hi guys,
>>
>> I sat down for a few hours to finally integrate the pre-done work into a
>> working firmware.
>>
>> The structure is like the current "sine" versio, only f/u and sine_core
>> have been replaced by foc.
>>
> 
> Great!
> 
> 
>>
>> I encapsulated the encoder reading into a seperate module, that does
>> some clever things:
>>
> 
> Cool
> 
> 
>> I have one question now: The module spits out the mechanical angle. But
>> I assume that the Parke transformation needs the electrical angle?
> 
> 
> Yes
> 
> 
>> So
>> say I have a 6-pole motor, than electrical angle=3 times mechanical angle?
>>
> 
> Yes, that's correct (electrical angle = pole pair count x mechanical angle).
> 
> 
>>
>> I have also not integrated the slip estimater, but for synchronous
>> motors it is not needed anyway. Since I'm personally using an
>> asynchronous motor, I will integrate it soon though. Can anyone tell me
>> what is the order of magnitude of the rotor time constant? What impact
>> does an inaccuracy of 50% have?
>>
> 
> 0.3 to 0.4 seconds are the sorts of rotor time constant values we have
> seen. 50% inaccuracy will likely cause some grief, 10% inaccuracy is fine
> though.  Ed, does this need any further elaboration?
> 
> 
>> That said you might notice that I have not test-run the new firmware
>> yet. I created a simulation environment around the new modules, thats my
>> only test.
>>
>> And finally: where should I place the project in our new git repo and
>> how can I share files between the sine and the foc project?
>>
> 
> Git submodules are the order of the day I believe (
> http://git-scm.com/book/en/Git-Tools-Submodules).  Basically package the
> common files into a submodule that each of the projects (e.g. sine and foc)
> can share. I'm new to git, so no expert on this, maybe Robin can assist
> with the details?
> ------------------------------------------------------------------------------
> Own the Future-Intel&reg; Level Up Game Demo Contest 2013
> Rise to greatness in Intel's independent game demo contest.
> Compete for recognition, cash, and the chance to get your game 
> on Steam. $5K grand prize plus 10 genre and skill prizes. 
> Submit your demo by 6/6/13. http://p.sf.net/sfu/intel_levelupd2d
> _______________________________________________
> Tumanako-devel mailing list
> Tum...@li...
> https://lists.sourceforge.net/lists/listinfo/tumanako-devel
> 

Re: Getting closer to tumanako FOC

[Philip C. <ph...@gr...>]

Hi Johannes

Sounds great!  More comments below...

Cheers
Philip

On 26 March 2013 09:41, Johannes Hübner <j...@jo...> wrote:

> Hi guys,
>
> I sat down for a few hours to finally integrate the pre-done work into a
> working firmware.
>
> The structure is like the current "sine" versio, only f/u and sine_core
> have been replaced by foc.
>

Great!


>
> I encapsulated the encoder reading into a seperate module, that does
> some clever things:
>

Cool


> I have one question now: The module spits out the mechanical angle. But
> I assume that the Parke transformation needs the electrical angle?


Yes


> So
> say I have a 6-pole motor, than electrical angle=3 times mechanical angle?
>

Yes, that's correct (electrical angle = pole pair count x mechanical angle).


>
> I have also not integrated the slip estimater, but for synchronous
> motors it is not needed anyway. Since I'm personally using an
> asynchronous motor, I will integrate it soon though. Can anyone tell me
> what is the order of magnitude of the rotor time constant? What impact
> does an inaccuracy of 50% have?
>

0.3 to 0.4 seconds are the sorts of rotor time constant values we have
seen. 50% inaccuracy will likely cause some grief, 10% inaccuracy is fine
though.  Ed, does this need any further elaboration?


> That said you might notice that I have not test-run the new firmware
> yet. I created a simulation environment around the new modules, thats my
> only test.
>
> And finally: where should I place the project in our new git repo and
> how can I share files between the sine and the foc project?
>

Git submodules are the order of the day I believe (
http://git-scm.com/book/en/Git-Tools-Submodules).  Basically package the
common files into a submodule that each of the projects (e.g. sine and foc)
can share. I'm new to git, so no expert on this, maybe Robin can assist
with the details?

Hello, Everyone

[Paul L. <la...@gm...>]

Hi, All.  I have been watching this mailing list and reading up on other
forums for the past few months, working on trying to get up to speed.  I
recently picked up one of those old Ford Siemens motors and am ready to
jump in and get my feet wet.  My hope is that I can contribute some good
things to this project (and end up with a working controller for my motor
too).  Where is the best place to start?  I've browsed through the wiki a
fair amount, but it is sometime difficult to tell what is up to date and
what is obsolete.
Although there is plenty of rust to knock out my ears in terms of
programming, I am more concerned in terms of the hardware aspect of things,
since most of my power electronics knowledge is theoretical, and I haven't
ever done a big project.  Where is the best place to look as far as power
stages go?  I certainly do not have anywhere near endless amounts of money,
but I also don't really want to skimp on this, as I don't want the motor to
be limited by the controller.  Anyway, any advice you guys could give me
would be greatly appreciated.  Hopefully I can quickly get up to speed and
then be a good contributor to the cause.

Thanks,

Paul Lackey

Getting closer to tumanako FOC

[Johannes H. <j...@jo...>]

Hi guys,

I sat down for a few hours to finally integrate the pre-done work into a 
working firmware.

The structure is like the current "sine" versio, only f/u and sine_core 
have been replaced by foc.

I encapsulated the encoder reading into a seperate module, that does 
some clever things:

When the angle is sampled, it obviously counts the number of pulses 
since the last sample. What it also does is look at the time that passed 
since the last pulse and the time between the last two pulses. With this 
information it can interpolate the angle even when there was no pulse 
since the last sample. This is especially useful for my 60-pulse optical 
encoder, for some fancy 8192 pulse encoder it is redundant.

It sounds more complicated than it is, also, most of it is done by the 
DMA/Timer hardware.

I have one question now: The module spits out the mechanical angle. But 
I assume that the Parke transformation needs the electrical angle? So 
say I have a 6-pole motor, than electrical angle=3 times mechanical angle?

I have also not integrated the slip estimater, but for synchronous 
motors it is not needed anyway. Since I'm personally using an 
asynchronous motor, I will integrate it soon though. Can anyone tell me 
what is the order of magnitude of the rotor time constant? What impact 
does an inaccuracy of 50% have?

That said you might notice that I have not test-run the new firmware 
yet. I created a simulation environment around the new modules, thats my 
only test.

And finally: where should I place the project in our new git repo and 
how can I share files between the sine and the foc project?

Regards,
Johannes

Re: Convert SVN to git repos

[Robin V. <cz...@su...>]

i added Maven support to the Dashboard (in a branch called 'maven'):
https://github.com/tumanako/tumanako-dashboard/commits/maven

btw, you can of course start using the repos, and still decide later to
use sf.net instead of github. moving a git repo is very easy.

On 17.03.2013 00:24, Edward Cheeseman wrote:
> Could you add my github account to tumanako? I'm evbuilder, just to keep things same as sourceforge
> 
> On 17/03/2013, at 12:18 PM, Edward Cheeseman wrote:
> 
>> And Me!
>>
>> now, onto creating a github user...
>>
>> On 17/03/2013, at 9:21 AM, Bernard Mentink wrote:
>>
>>> Thanks, I can see it now too ..
>>>
>>> Bernie
>>>
>>> On Sun, Mar 17, 2013 at 7:01 AM, Johannes Hübner <j...@jo...>wrote:
>>>
>>>> Yeah, it works now!
>>>>
>>>> Am 16.03.2013 18:50, schrieb Robin Vobruba:
>>>>> https://github.com/organizations/tumanako/ does not work?
>>>>> that's strange... but indeed, it only works when i am logged in! :/
>>>>> that is definitely a bug on github.
>>>>> i now added you as an owner.. i guess you will be able to browse now.
>>>>> i wrote a report to the github team.
>>>>> thanks!
>>>>>
>>>>
>>>>
>>>>
>>>> ------------------------------------------------------------------------------
>>>> Everyone hates slow websites. So do we.
>>>> Make your web apps faster with AppDynamics
>>>> Download AppDynamics Lite for free today:
>>>> http://p.sf.net/sfu/appdyn_d2d_mar
>>>> _______________________________________________
>>>> Tumanako-devel mailing list
>>>> Tum...@li...
>>>> https://lists.sourceforge.net/lists/listinfo/tumanako-devel
>>>>
>>> ------------------------------------------------------------------------------
>>> Everyone hates slow websites. So do we.
>>> Make your web apps faster with AppDynamics
>>> Download AppDynamics Lite for free today:
>>> http://p.sf.net/sfu/appdyn_d2d_mar
>>> _______________________________________________
>>> Tumanako-devel mailing list
>>> Tum...@li...
>>> https://lists.sourceforge.net/lists/listinfo/tumanako-devel
>>
>> Edward Cheeseman
>> Electrical Engineer ME(hons)
>> che...@gm...
>>
> 
> Edward Cheeseman
> Electrical Engineer ME(hons)
> che...@gm...
> 
> 
> ------------------------------------------------------------------------------
> Everyone hates slow websites. So do we.
> Make your web apps faster with AppDynamics
> Download AppDynamics Lite for free today:
> http://p.sf.net/sfu/appdyn_d2d_mar
> _______________________________________________
> Tumanako-devel mailing list
> Tum...@li...
> https://lists.sourceforge.net/lists/listinfo/tumanako-devel
> 

Re: STM32 bootloader

[Johannes H. <j...@jo...>]

Yeah thats how I did it before using the ZigBee module. Another problem 
was the pin sharing of TIM1 and USART1.

Writing to the flash is quite easy as you'll see in the loader and also 
in the param_save.cpp in the sine project.

/Johannes

On 17.03.2013 10:20, Edward Cheeseman wrote:
> Thanks Johannes!
>
> I've just copied below into GitHub "README.txt".
>
> Unfortunately I've already taken a different approach, using an RS232 D9 pin to set the BOOT0 pin (the plug has a pushbutton in it).
> This works for me, so I don't need to use a different loader at the moment. I have been using a python script to download to the built in loader.
>
> So I probably won't use this until the other way is inconvenient for some reason.
>
> Are the methods used in this bootloader to write to Flash the same that you would use to store application variables (motor parameters etc) or fault logs to?
> If so I'll look at reusing code for storing motor parameters independent of the motor control.
>
>
> Edward

Re: STM32 bootloader

[Edward C. <che...@gm...>]

On 17/03/2013, at 10:20 PM, Edward Cheeseman wrote:
> I've just copied below into GitHub "README.txt"

Oh, by the way, I used the GitHub.app (for Mac) and it makes git really easy.

In the past I have used TortoiseGit on Windows which was pretty easy, but the GitHub app really makes git trivial.

The main difference to SVN for basic stuff is that you have your own local repository that you commit changes to, and can branch in. Then separate to that you can push changes to whichever server branch you like. (GitHub.app calls this push 'Sync')

So two steps to get it public. But this is what makes git so powerful.

I'd hope the linux and win Github apps should be just as easy to use. Saves learning the terminal commands!

Edward

Re: STM32 bootloader

[Edward C. <che...@gm...>]

Thanks Johannes!

I've just copied below into GitHub "README.txt".

Unfortunately I've already taken a different approach, using an RS232 D9 pin to set the BOOT0 pin (the plug has a pushbutton in it).
This works for me, so I don't need to use a different loader at the moment. I have been using a python script to download to the built in loader.

So I probably won't use this until the other way is inconvenient for some reason.

Are the methods used in this bootloader to write to Flash the same that you would use to store application variables (motor parameters etc) or fault logs to?
If so I'll look at reusing code for storing motor parameters independent of the motor control.


Edward

On 17/03/2013, at 7:23 PM, Johannes Hübner wrote:

> Hi Edward,
> 
> no, the bootloader does not interact with the built-in bootloader. It 
> uses an interface of your choice, right now this is USART3. The 
> interface flexibility and the independence from the BOOT pins where the 
> main reasons for implementing it.
> 
> The protocol is like this:
> - 115200-8-N-2 (2 stop bits necessary when using a ZigBee module)
> 1 Send an 'S' indicating that it is awaiting an update size in pages
> 2 If no reply within about 500ms go to step 5
> 2.1 otherwise send a 'P' indicating that it is awaiting the actual page 
> as a binary image
> 3 When page received send a 'C' indicating that it is awaiting the pages 
> checksum
> 4 When checksum is correct and more pages need to be received, go to 
> step 2.1
> 4.1 if all pages have been received go to step 5
> 4.2 When checksum isn't correct print an 'E' then go to step 2.1
> 5 When done print a 'D' and start main firmware (known bug: the D tends 
> to be erroneous maybe because the usart is shut down right after sending it)
> 
> I guess I should be embarrassed for not having this written up already. 
> I've also written a library that follows this procedure but it seems I 
> haven't committed it yet. Once I figure out git I will.
> Anyone feel free to implement this protocol in a scripting language.
> 
> notes:
> - By CRC I mean the one calculated by the STMs integrated CRC32 unit.
> - The actual firmware has a reset command the cycle through the bootloader
> - The main firmware must be linked to start at address 0x08001000
> - The bootloader starts at address 0x08000000 and can be 4k in size 
> (right now its around 1.5k)
> 
> /Johannes
> 
> 
> On 17.03.2013 00:43, Edward Cheeseman wrote:
>> Hi Johannes,
>> 
>> 
>> I'm looking at setting up a motor test bench. I thought I'd start with tumanako-inverter-fw-bootloader.
>> 
>> Just briefly, does this build on the STM32's built in bootloader, or is it a level up, not requiring the BOOT0/BOOT1 pins to be asserted?
>> 
>> How do you then start into bootloader mode?
>> 
>> 
>> Edward
>> 
>> PS:
>> 
>> Sorry for starting with such simple question - I'm a bit embarrassed, especially since I appear in the authors list of some of the files!
>> 
>> I'll write up a README for the repository explaining things as I go
>> 
> 
> 
> ------------------------------------------------------------------------------
> Everyone hates slow websites. So do we.
> Make your web apps faster with AppDynamics
> Download AppDynamics Lite for free today:
> http://p.sf.net/sfu/appdyn_d2d_mar
> _______________________________________________
> Tumanako-devel mailing list
> Tum...@li...
> https://lists.sourceforge.net/lists/listinfo/tumanako-devel

Edward Cheeseman
Electrical Engineer ME(hons)
che...@gm...

Re: STM32 bootloader

[Johannes H. <de...@jo...>]

Hi Edward,

no, the bootloader does not interact with the built-in bootloader. It 
uses an interface of your choice, right now this is USART3. The 
interface flexibility and the independence from the BOOT pins where the 
main reasons for implementing it.

The protocol is like this:
- 115200-8-N-2 (2 stop bits necessary when using a ZigBee module)
1 Send an 'S' indicating that it is awaiting an update size in pages
2 If no reply within about 500ms go to step 5
2.1 otherwise send a 'P' indicating that it is awaiting the actual page 
as a binary image
3 When page received send a 'C' indicating that it is awaiting the pages 
checksum
4 When checksum is correct and more pages need to be received, go to 
step 2.1
4.1 if all pages have been received go to step 5
4.2 When checksum isn't correct print an 'E' then go to step 2.1
5 When done print a 'D' and start main firmware (known bug: the D tends 
to be erroneous maybe because the usart is shut down right after sending it)

I guess I should be embarrassed for not having this written up already. 
I've also written a library that follows this procedure but it seems I 
haven't committed it yet. Once I figure out git I will.
Anyone feel free to implement this protocol in a scripting language.

notes:
- By CRC I mean the one calculated by the STMs integrated CRC32 unit.
- The actual firmware has a reset command the cycle through the bootloader
- The main firmware must be linked to start at address 0x08001000
- The bootloader starts at address 0x08000000 and can be 4k in size 
(right now its around 1.5k)

/Johannes


On 17.03.2013 00:43, Edward Cheeseman wrote:
> Hi Johannes,
>
>
> I'm looking at setting up a motor test bench. I thought I'd start with tumanako-inverter-fw-bootloader.
>
> Just briefly, does this build on the STM32's built in bootloader, or is it a level up, not requiring the BOOT0/BOOT1 pins to be asserted?
>
> How do you then start into bootloader mode?
>
>
> Edward
>
> PS:
>
> Sorry for starting with such simple question - I'm a bit embarrassed, especially since I appear in the authors list of some of the files!
>
> I'll write up a README for the repository explaining things as I go
>

Re: Convert SVN to git repos

[Robin V. <cz...@su...>]

i added you

On 17.03.2013 00:24, Edward Cheeseman wrote:
> Could you add my github account to tumanako? I'm evbuilder, just to keep things same as sourceforge
> 
> On 17/03/2013, at 12:18 PM, Edward Cheeseman wrote:
> 
>> And Me!
>>
>> now, onto creating a github user...
>>
>> On 17/03/2013, at 9:21 AM, Bernard Mentink wrote:
>>
>>> Thanks, I can see it now too ..
>>>
>>> Bernie
>>>
>>> On Sun, Mar 17, 2013 at 7:01 AM, Johannes Hübner <j...@jo...>wrote:
>>>
>>>> Yeah, it works now!
>>>>
>>>> Am 16.03.2013 18:50, schrieb Robin Vobruba:
>>>>> https://github.com/organizations/tumanako/ does not work?
>>>>> that's strange... but indeed, it only works when i am logged in! :/
>>>>> that is definitely a bug on github.
>>>>> i now added you as an owner.. i guess you will be able to browse now.
>>>>> i wrote a report to the github team.
>>>>> thanks!
>>>>>
>>>>
>>>>
>>>>
>>>> ------------------------------------------------------------------------------
>>>> Everyone hates slow websites. So do we.
>>>> Make your web apps faster with AppDynamics
>>>> Download AppDynamics Lite for free today:
>>>> http://p.sf.net/sfu/appdyn_d2d_mar
>>>> _______________________________________________
>>>> Tumanako-devel mailing list
>>>> Tum...@li...
>>>> https://lists.sourceforge.net/lists/listinfo/tumanako-devel
>>>>
>>> ------------------------------------------------------------------------------
>>> Everyone hates slow websites. So do we.
>>> Make your web apps faster with AppDynamics
>>> Download AppDynamics Lite for free today:
>>> http://p.sf.net/sfu/appdyn_d2d_mar
>>> _______________________________________________
>>> Tumanako-devel mailing list
>>> Tum...@li...
>>> https://lists.sourceforge.net/lists/listinfo/tumanako-devel
>>
>> Edward Cheeseman
>> Electrical Engineer ME(hons)
>> che...@gm...
>>
> 
> Edward Cheeseman
> Electrical Engineer ME(hons)
> che...@gm...
> 
> 
> ------------------------------------------------------------------------------
> Everyone hates slow websites. So do we.
> Make your web apps faster with AppDynamics
> Download AppDynamics Lite for free today:
> http://p.sf.net/sfu/appdyn_d2d_mar
> _______________________________________________
> Tumanako-devel mailing list
> Tum...@li...
> https://lists.sourceforge.net/lists/listinfo/tumanako-devel
>