What type of language would you prefer for writing KiCad scripts?

Software
21

Yeah, 1967. It was “FORTRAN II”. It ran on something about the size of a trash dumpster that IBM called a “Model 1440”, with a whopping 8K words of “core” (i.e., read/write RAM) memory.

Well, I don’t know C or C++ though on a few occasions I looked at C++ source code and could make sense of it, and even simple modifications.

I think it’s fair to assume that circuit design engineers, and even many technicians, have an acquaintance with some kind of programming language, but it may not be “C” or its derivatives. Some dialect of BASIC is probably a better bet.

In my opinion, “scripts” and “macros” for something like KiCAD really should be the same thing. (Except that macros can be automagically recorded from keyboard actions.) The underlying formal language should have a very simple, fairly obvious, and forgiving syntax. If you need terms like “iterator” and “tuple” to explain the syntax, it’s too complicated. In my mind that requirement tips the balance away from C/C++ and towards BASIC. I don’t know where Python falls on that spectrum.

Dale

22

These days people who only have exposure to modern day computers can’t understand how anything could have been accomplished with only 8K of RAM. And if you showed them a “core” they would think it was some king of macrame.

As a programmer I don’t think the choice of scripting language really makes much difference so long as the API is well documented. If I really want to write a KiCad script it wouldn’t take much to pick up the language. Choosing a language to suit non-programmers would be difficult. A simple Basic like language would probably lack capability.

There are C interpreters that could be used to implement a C scripting language but I think Python is probably as good as any other language.

2 Likes
23

Sure, that makes sense. It would take a bit of a re-vamp of the UI I think, and possibly some extensive refactoring.

26

So Andy…
A tuple is just an array by a different name ?
Why not call it an array like most languages do ?

28

Huh? That’s the way I’ve done ‘em all…
Fortran, Pascal, Basic, C, C++, Perl, PHP, HTML, JavaScript…
Gotta jump in and get the feet wet !
Just sayin’ :stuck_out_tongue_winking_eye:

1 Like
29

Did I forget to mention COBOL ??

30

Yeah, a couple incarnations ago I had a lot of fun doing things with assembly language on Microchip PIC uC’s. Part of the satisfaction came from the fact that I could do ALL of the creative design work - circuitry, logic, firmware, PCB’s, etc - myself, without relying on others to do the parts I don’t understand well.

Dale

31

What I think we need is a wrapper library(if that’s the correct terminology?) to ease implementing for us who don’t know python. Like Arduino Serial.begin() we have list_vias() for instance. The python API should have raw access to KiCad and the library functions protects us from misuse that crashes kicad. What do you think about that idea?

32

I think that is essentially the idea of the current scripting, although there doesn’t appear to be a way to get a list of just the vias currently.

My first script lists the module names and values:

import pcbnew

def testfunc():
	my_board = pcbnew.GetBoard()
	for module in my_board.GetModules():
		print "module %s val: %s" % ( module.GetReference(), module.GetValue() )

Does that look simple enough?

33

Obvious to whom?

By “modern day computers” I was referring to typical desktop/laptop type computers, not embedded devices like Arduinos. After all the Model 1440 was a mainframe with only 8K (Although I think the maximum was 16K).

34

The python API afai-understand-it already is a ‘wrapper’ to the C modules.

It would be better to classify the python API into safe and unsafe modules, and the novice should only use the safe ones. This would not add additional work onto the developers.
So instead of

import pcbnew

you’d have (for example)

import pcbnew_safe

and

import pcbnew_unsafe

Question then just becomes - what is considered safe and what isn’t?

PS: python is human readable most of the times, so pretty easy to work with. And with it’s forgiving nature (search google for python try/except) very kind to newbies.
And for testing pieces of code it’s got a live interpreter. You can type code into the command line and test it right there. Very convenient.

2 Likes
35

I was more thinking of a collection of kicad specific functions. The whole point of it is to hide as much of python as possible from non programmers with great ideas for new features. Look at mmccoo’s tutorials, the functions he has written is good examples of what could be in there.

36

I started with KiCad about a year back and i like it. Nevertheless I found many things which added to customize. I use Visual Basic (.net) and work with Kicads files .pro, .sch and .kicad_pcb.
I wish there were a programming interface (.dll) to call internal functions of KiCad. If there is something like that I would be happy to learn about it.

37

Have you had a look at this?

The scripting API is an interface to the internal functions if I understand correctly.

Out of curiosity, what is it you are missing and want to add?

1 Like
38

Wow, this sound very interesting and if it can do for me want I am
looking for it will save a lot of time.

If you have a little example, how to call these classes from within VB I
would very much appreciate to receive it. The reason is that I decided
some time ago to write all applications in VB if possible. This includes
use of databases, calling uC via USB, graphs etc.

thanks

39

I have no idea but you could ask the author of the blog in his thread here at the forum.

40

I’ll throw in my $.02 (USD) on this topic.

I’m an “as needed” KiCAD user. I also have a rather long background in CAD and software…and hardware, and electronics…well that list gets long after so many years. :wink: And, the list of coding languages I’ve used is WAY longer than I care to remember…even if I could. :open_mouth:

Having a scripting language for quick lash ups and time saving is a great idea. And having a real programming language to do heavy lifting is better when needed.

Since KiCAD has limited developer resources, I’d recommend having one, rather than diluting resources on two. And ending up with limited, buggy support for two.

Python is not hard to learn. There is a ton of help on the web. In the case of using scripting or programming tools to automate tasks in any CAD package, the CAD portion is typically what people perceive as hard. Mostly because it is an API (Application Programming Interface) added onto the language so the language can access the details of the CAD package. The interaction between GUI, CAD constructs, and the API is where the learning curve is steeper than learning just the programming language on it’s own. (Especially if you attempt to learn both at the same time.) The point here is there maybe 1000 examples of how to use a tuple on the web, but, not how they are used when working with a particular API. Hence, examples and good documentation for the API is essential.

Again…just my $.02 (USD), YMMV. :wink:

8 Likes
41

This!
This is what I meant by “arduino like wrapper library”. Not very obvious maybe.

42

@KiCADsmktec I don’t know how straight forward it’d be to make the python stuff available from VB.

Since the python stuff can be called from standalone python scripts, one possible workaround is to have little scriptlets that you’d call from VB.

I don’t know if the effort would be worth it. To me VB means windows, and my luck with getting non MS languages to work there (python and perl come to mind. stuff within cygwin is an exception but I don’t believe that help us here). So once you’ve got a python scriplet working, you’d then have to get the VB shell call to python to work.

I’d encourage you to look at the examples in my blog (mentioned in one of the earlier posts).

@bobc I’ve thought about developing a wrapper for the python APIs, also in python but more consistent. Each of kicad’s classes does things a little bit different. The wrapper would make things more uniform. For example, to get the name, you call getName. To get the parent, call getParent. To get children call getChildren. They’d all return a python list, not a goofy swig wrapper…

As for the status quo, I’m guessing that there is a desire by users to have easier programming type interfaces. The problem is that there are few people with the skillset, desire, and time to implement them.

@rickb I believe you emailed me about ulp stuff. I replied but I don’t know if you’ve received it.
I still don’t fully understand it, but there is a nice feature that I’ve seen in another CAD tool that could be relevant here.

In that tool, all significant GUI interactions were recorded into a file. (mouse clicks, key bindings, button clicks…) Those could then be read back into the tool. It was developed as a recovery mechanism for debugging and to avoid losing data when the tool crashed (all too frequent)

Over time that recovery mechanism was used for macro type stuff. Folks wrote scripts to write stuff in the recovery syntax.

Either way, it seems there’s a need for several interfaces at varying levels of complexity. Macros, python, c++. My opinion is that a ton of stuff should move from c++ to python. Way more accessible to way more people. I can’t comment on macros, since “real” programming languages feel natural to me.

Kudos (or condolences) to anyone who’s made it to the end of my rambling.

1 Like
43

@Miles: I did get your reply, but had not yet formulated a response. See the links I posted in my first post to understand what I am talking about.

It’s no surprise that Python won this poll, given that the responders are almost certainly programmers. I see no problem with having a language available for low level access to KiCad, but for non-programmers, an application specific command language similar to what is available in Eagle is more accessible.

That command language I am referring to is already in KiCad, in the form of mouse clicks, key modifiers and keyboard data entry, we just need a way to access it programmatically via script files written in a command line editing window that can be called/made visible when needed. Command files can be saved and called by name or bound to a keystroke combination. In Eagle, .scr files can call .ulp files when lower level access is needed. I suspect that Eagle’s command line interface functionality can be written as a Python plugin by the many Python programmers that responded to this poll. :smiley:

Again, take a look at the links in my first post.

Rick