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


#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.


#23

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


#24

What should be obvious is that plenty of Real Designs are still done with machines that have only 8k RAM. Little microcontrollers rule!


#25

Python really isn’t all that difficult! and bonus, all of the documentation is online.

Learn about tuples here: https://docs.python.org/3/tutorial/datastructures.html#tuples-and-sequences
and iterators here: https://wiki.python.org/moin/Iterator but note that iterators are a bit trickier. And the thing is, many looping constructs have inherent iterators, so for example you can do things like what are listed here: http://anandology.com/python-practice-book/iterators.html

Python supports modular object-oriented design.

But that’s not to say that it has some daft features, one of which is the ability to re-define a variable’s type on the fly. You can assign a variable:

    x = 100

and further on down redefine it as a tuple

x = [1, 2, 3]
and the interpreter doesn’t care, and will happily use the new type definition for x.


#26

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


#27

Python doesn’t have arrays :slight_smile:

What one might think of as an array is called a list in Python.

What is the difference between a list and a tuple? The former is mutable, meaning it can be changed (elements can be changed, and the size of the list can be changed), while the latter is immutable. There are consequences of the choice.

I suppose the best way to understand the language is to start working through the tutorials and examples at python.org, and don’t just try to jump in and write a Kicad script.


#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:


#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.


#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?


#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: