Board Stackup Access

[monahans]

Hi,

I’m trying to access the board stackup from a Python script. So I can do

stackup = board.GetDesignSettings().GetStackupDescriptor()

But where do I go from there? Is this just not exposed properly in the SWIG files?

Thanks
-m

[Rene_Poschl]

When asking for help with the python API always include your version info.

[monahans]

This is with a version build from master about a two months ago. It’s using Python 3 on CentOS.

It reports 5.99.0.
wxWidgets 3.0.5 Unicode and Boost 1.70.0

Thanks!
-m

[HiGreg]

What I usually have to do is liberal use of dir(stackup) and review of the Python Documentation. Unfortunately, the Python documentation doesn’t seem to mention the specific version for which the documentation applies. I don’t have 5.99 installed and the current version of KiCAD I do have installed doesn’t have .GetStackupDescriptor(). Can you supply maybe the dir(stackup) output? I might be able to help.

Edit: you might have to resort to browsing the KiCAD source code to get more information.

[monahans]

dir() only shows the builtin __symbol__s plus acquire, append, disown, next, own.

I did look at the source code, but I don’t really no anything about SWIG. It looks to me like there is no explicit definition of BOARD_STACKUP in the SWIG files and therefore none of its member is accessible. But that’s just guessing really.

I’d be happy to try and change the code if you have some pointers.

Thanks
-m

[HiGreg]

@monahans

dir() only shows the builtin __symbol__ s plus acquire , append , disown , next , own .

That may indicate an iterator. Try using stackup=[bs for bs in stack] if it lets you and explore the members of the stackup list created there.

Edit: you may be right, google reveals " While acquire , disown , append , own , next , this , and thisown are remnants of the SWIGObject base class"

Edit2: Here is the C source code to class_board_stackup.cpp where more is defined. It might lead in the right direction.

[monahans]

That just tells me SwigPyObject is not iterable.

I would suspect it needs a interface definition for BOARD_STACKUP (and I guess BOARD_STACKUP_ITEM to be useful), for SWIG to expose the functionality.

[HiGreg]

I’m fairly certain the stackup mechanism is being worked on currently. The developer may not have gotten to this area of development. It might be worth submitting a GitLab issue to communicate the need/desire for Python access just in case they aren’t aware of the issue.

[craftyjon]

The python access you are seeing right now is automatically generated by SWIG.

In general, the direction we’d like to go in is explicitly-defined APIs rather than SWIG automatically generating them from the C++ code. We just have not had time to make much progress on this yet.

[HiGreg]

Do you anticipate that the APIs would be much different than the current SWiG definitions? I continue to develop KiCommand’s access to pcbnew objects and it is a great example of converting the Python SWiG APIs into a decently usable fairly generic API.

[craftyjon]

There aren’t any specific changes in the works that I know of, but in general, we want the flexibility to refactor the C++ code without breaking people’s plugins. Because the current Python API is directly generated from C++, this probably means at least some amount of breakage is necessary to move to a more stable API.

We already have a few things that are wrapped in a way that presents a stable Python API (for example, everything in pcbnew_scripting_helpers.cpp. There isn’t a firm plan of how or when to do this, but there is general thinking that it would be nice if we could make this change sometime.

This would still involve SWIG, the idea would be to wrap SWIG around stable C++ code that then accesses “unstable” (i.e. API can change) C++ +code.

This stackup code is a perfect example: The feature is there, but not quite done. So, SWIG has automatically wrapped parts of it, but it doesn’t have a good interface, and that interface may change, which makes it tricky to use by people who want to write Python code that interacts with the stackup.

The better model would be to have an intentionally-developed Python API for new features like the stackup, so that the API is not available until it is fully usable.