← Back to team overview

kicad-developers team mailing list archive

Kicad scripting progress :-)

 

Hi All,

    I wanted to share our progress on this, and ask a few questions.

    At this moment, we're already able to:

1) run scripts (python) from inside pcbnew,
        pcbnew.GetBoard()  must return our current BOARD* in the editor.

A little example:

   from pcbnew import *

   m = GetBoard().m_Modules

   x,y=54000,54000
   i=1

   while m:
        m.SetPosition(wxPoint(x+i*2000,y))
        m.SetReference("C%d"%i)
  i+=1
m = m.Next()


2) run pcbnew classes and objects from inside a standalone python script.

#!/bin/env python
from pcbnew import *

pcb = LoadBoard("/tmp/my.brd")
m = pcb.m_Modules

x,y=54000,54000
i=1

while m:
     m.SetPosition(wxPoint(x+i*2000,y+i*1000))
     m.SetReference("C%d"%i)
     i+=1
     m = m.Next()

SaveBoard("/tmp/my.brd",pcb)

Same example from commandline:

    For which I added some functions to easily load or save a PCB file via
IO_MGR // KICAD_PLUGIN (as Dick asked, it
was the best way)

    I added typemaps for strings<->wxString, and also wrappers for wxPoint
and wxRect, which let
us to talk to methods depending on this types.

    We have wrappers for most objects (BOARD, COMPONENT, PAD, segments ,
tracks, text, etc... ) and lists (DLIST based),
but we still miss access to std::vector and std::list objects yet.


We already have something quite useful, but testing is very welcome.

https://code.launchpad.net/~miguelangel-r/kicad/scripting

I only tested it on Linux/x86, and will test on Linux/x64, but testing in
other systems is welcome.
To build the branch you should compile with:

KICAD_SCRIPTING                (for embedded scripting support in pcbnew)
KICAD_SCRIPTING_MODULES  (for module scripting support from python)
USE_NEW_PCBNEW_LOAD
USE_NEW_PCBNEW_SAVE


The problems I facing now are:

a) Some pcbnew functionalities are highly coupled with UI, so dependencies
from objects to UI
are in many places (making the .SO/.DLL module approach very hard), I tried
to split in ui and
non ui .cpp files, but I ended always with linking problems, so the
currently built _pcbnew.so links
all the UI items inside, it works prefectly, but most code won't be ever
called.

b) From a), for example, I'm not able to load a MODULE object from library,
without having a
PCB_BASE_FRAME object:

from loadcmp.cpp:

MODULE* PCB_BASE_FRAME::GetModuleLibrary( const wxString&
aLibraryFullFilename,
                                          const wxString& aModuleName,
                                          bool
 aDisplayMessageError )

   This could be fixed by splitting the library functionality in a
different class, and then using it
from those functions (and from scripting).

c) same for DRC, I thought it could be very helpful to run DRC checkings
(automated commandline
scripts for DRC checking) , but it also was highly coupled to the UI.

d) this is minor, but it's there... if you run pcbnew from the same
directory _pcbnew.so is (this is normal
when building), then pcbnew will load _pcbnew.so from it's local directory
(this is some swig feature...),
then GetBoard() won't work (return None) because it's a separeted instance
from our running pcbnew...,
so if you want to test ./pcbnew from your build directory, then move
_pcbnew.so somewhere else ;)


e) other minor, if you make install to /usr/local, then the _pcbnew.so and
pcbnew.py will go to
/usr/local/share/python, which is out of the normal python path, so you
will need to do:

export PYTHONPATH=$PYTHONPATH:/usr/local/share/python

and then run your script.



I will keep working on it, and keep you updated, but any tests/feedback are
really welcome :-)


-- 

Miguel Angel Ajo Pelayo
http://www.nbee.es
+34 636 52 25 69
skype: ajoajoajo

Follow ups