Pbnew Python API: Cannot to set board design settings

added priorityundecided statusnew labels

In general, the answer is that you need to copy the design settings from the source project to the target project, rather than from the source board to target board as you used to. Now this isn't a complete answer because I haven't checked if this is possible via SWIG-exposed APIs yet.

added pcbnew python labels

changed milestone to %6.0.0-rc1

Thank you for your prompt answer!

I thought boards were (in v5) standalone files with no (direct) relation to the project. Therefore, it makes sense to take a board and produce a board for the panel. Similarly, for assembly, it makes sense to take original schematics (which carries BOM) and (possibly) panelized board to produce assembly data.

Do I get correctly, that v6 is "project-oriented", therefore the main "unit" is a project (carrying design settings), with a single schematics (having one or more sheets) and a single board? Thus I should switch the workflow and all the produced panels should also have an associated project? Is it possible for a project to have multiple boards? Or multiple schematics? The use case for that would a multi-board panel (where I require the schematics for all the boards in the panel).

Also, again not sure if is it the right channel but as you touched SWIG-exposed API I will ask; I read a lot of rumors about the Python API changes for v6 (API for eeschema, stable API which is not tightly coupled to KiCAD internals). Is it happening for v6? Is there a place I can read the proposal and possibly express my opinions? I rely quite heavily on KiCAD's Python API in my projects and currently, there are many changes with v6 I need to adapt to. Currently, I reverse-engineer them from sources and I often find out that some functionality is drastically changed/removed (just like in this case).

Do I get correctly, that v6 is "project-oriented", therefore the main "unit" is a project (carrying design settings), with a single schematics (having one or more sheets) and a single board? Thus I should switch the workflow and all the produced panels should also have an associated project? Is it possible for a project to have multiple boards? Or multiple schematics? The use case for that would a multi-board panel (where I require the schematics for all the boards in the panel).

In KiCad 6, this is basically true. A project can have one board and one schematic with multiple sheets (we plan to support more than one board per project in a future version, as well as supporting "flat" non-hierarchical multi-sheet schematics).

The board file is still standalone in terms of being able to open and view it, but some settings that are only needed for editing or checking the board (such as the design rules) are moved to the project.

I think there should not be any major workflow change for your plugin for V6 (assuming we fix the APIs so you can access the design rules again somehow). Since there is not yet any support for multiple boards per project, you will still have to construct a new board from source boards like you do today.

Regarding your Python API question, @sethhillbrand is probably the guy to answer. I know a lot more about the design rules and project stuff than the Python API status.

added prioritymedium statusconfirmed labels and removed priorityundecided statusnew labels

assigned to @sethhillbrand

added statusin-progress label and removed statusconfirmed label

@sethhillbrand has this been fixed by the new Python bindings?

Assigned to me, so I don't forget to get these bindings in place

mentioned in issue #8836 (closed)

marked this issue as related to #8836 (closed)

added regression label

marked #8836 (closed) as a duplicate of this issue

Specific case to test in duplicate #8836 (closed)

assigned to @craftyjon

closed with commit 0234ae30

import pcbnew
b1 = pcbnew.GetBoard()
d1 = b1.GetDesignSettings()
b2 = pcbnew.LoadBoard('myboard.kicad_pcb')
d2 = b2.GetDesignSettings()
d1.CloneFrom(d2)

I just tried the code. Using CloneFrom causes a SIGSEGV later in my script when I try to refill zones. I managed to track the problem to the following:

ZONE_FILLER uses m_DRCEngine from board design settings (zone_filler.cpp:686), however, it is null.
CloneFrom does no clones m_DRCEngine as the assignment operator for BOARD_DESIGN_SETTINGS doesn't do it.
Therefore, the null pointer deference happens.

I am not sure whether to open a new issue for this; you closed the issue in my opinion too early before anyone could test it. So I commented here as there is the context for the problem. If you wish to have a new issue, please, let me know.

you closed the issue in my opinion too early before anyone could test it

It is standard practice for the KiCad project to close issues as soon as a fix is committed. If testing reveals issues, issues may always be reopened.

Can you please post your full script? It is not clear to me which board you are trying to run a DRC check on. I am not sure if we can support running a DRC check on the board that isn't open in the editor.

Ok, thank you for clarifying the workflow.

I am not checking DRC rules, I am refilling a zone using ZONE_FILLER. I attach a Python script that reproduces the result: zone_example.py. I added a tracing function to the SWIG interface board_design_settings.i:

 DRC_ENGINE* GetDrc() {
        return $self->m_DRCEngine.get();
    }

The problem is twofold:

pcbnew.BOARD() does not correctly initialize m_DRCEngine of design settings of the board. Therefore, no Python script can fill zones on a board created via API. On the other hand, pcbnew.LoadBoard correctly initializes m_DRCEngine.
BOARD_DESIGN_SETTINGS::CloneFrom does create a clone of m_DRCEngine, thus if the first problem is fixed, I expect that zone filling will be still driven by the original rules, not the cloned ones.

pcbnew.BOARD() does not correctly initialize m_DRCEngine of design settings of the board

This is by design, the board isn't responsible for creating the DRC engine. Can I see more of your script to see what you are trying to do?

Edit to clarify: In your example script you just construct an empty board. It is true that you won't be able to fill the zones on this board. Is this what you need to do in your actual plugin? I thought your actual plugin was working with the board loaded from the editor frame, and a board loaded from a file. Neither of these are the same case as creating a blank BOARD object from inside Python.

"DRCEngine" is a bit of a misnomer: it's actually the "RuleEvaluator" and you therefore can't do a lot of board editing without it.

@jeffyoung my point was, you can't just construct one out of thin air or copy it around. Right now, the supported ways of getting a fully-working board are to use LoadBoard or GetBoard. Constructing a new one using BOARD() won't work.

KiKit creates panels. Therefore, it creates a new board and appends existing boards to it. If possible, it inherits the design rules of the source boards.

In the ideal world, the user should be able to specify/override design rules for the panel, however, currently, there is no API for that (and I am fine with that).

Yeah, just didn't want the name to confuse anyone. LoadBoard does correctly initialize it. Does GetBoard?

(Maybe we need a NewBoard?)

(I guess GetBoard doesn't have to as it relies on PCB_EDIT_FRAME to do that.)

Does KiKit run inside KiCad as an action plugin?

Jeff: Yes, those APIs work fine. There is no NewBoard API right now but it could be added.

No, it is a standalone tool invoked from CLI.

OK, that is the problem then. Currently we don't support creating a new board from scratch, so we have to add that API. Let's take this to a new issue.

Having a NewBoard API and adding the possibility to properly inherit all design rules from an existing board would be nice! Should I create the issue or is it something you will take care of?

#9687 (closed)

Note: while we should add this API, it might be simpler for you to just load the existing board then do a Save As to your new board filename, then make whatever modifications you want to the new board. that should work today and seems easier.

Thank you! I will test it properly once it gets into a nightly build.

However, if I understand correctly, this does not include all design settings; e.g., custom DRC rules. Therefore, it is still a regression in my opinion. I lost the ability from API to make a 1:1 copy of all board settings (and to possibly change it). My aim is to ensure that whatever I do with the board in KiKit, I can still ensure that the DRC is passing on the resulting panel.

These rules are now bonded to the project - how can we create a new project with a new board and transfer (or alter) the custom rules?

Custom design rules is a new feature, so it is not a regression that they are not accessible from Python.

You can copy the actual file contents of the project2.kicad_dru into project1.kicad_dru (i.e. overwrite one with the other) and it should work.

@craftyjon First, thanks for your work on Kicad, we all appreciate it.

Custom design rules is a new feature, so it is not a regression that they are not accessible from Python.

Well, it's a regression in the sense that previously a 3rd party program could access all the user's design rules, and now it can't. So that program can no longer provide the same level of confidence that all is well, or take mitigating action if not.

I see that copying the kicad_dru file may be an OK workaround for some cases. However, that presumably just allows applying all the rules and seeing pass-fail. But a program like kikit is going to need to know more detail about the violated rule(s).

For example, if kikit adds mouse-bites, did these chew into the board in such as way as to violate a trace-to-edge rule? (Or better yet, can kikit proactively find out about the rule and position the mouse-bites better.) Or if Kikit panelizes using V-cuts, did the panel violate a large (high-voltage) trace-to-trace rule from one board to the adjacent one, which is irrelevant. (And custom high-voltage rules may well be the kind of thing users would put in a custom rule set, I suspect.)

Maybe it turns out to be easy to parse the kicad_dru file and learn that info. But it would be better to access it through an official API.

Anyhow, I know these things take time, and that the Python 3 and MSVC transition has been an ordeal. I just didn't want Jan to be the only one upvoting the significance of this particular area.

@gwideman I understand your viewpoint but don't agree with it.

previously a 3rd party program could access all the user's design rules, and now it can't.

That isn't true. Custom design rules, unlike standard design rules, are stored in a text file that may be present in a project. Nothing stops a third-party program from reading, copying, etc this text file.

But a program like kikit is going to need to know more detail about the violated rule(s).

If you or others actually have this need, then please open a feature request with more details about it. It is not a regression that there is no Python API for a newly-added feature: unfortunately, the current SWIG Python API setup does not make it easy for us to keep up with new features, especially ones like this where there is not a straightforward technical mapping between how the thing actually works and how it would need to be exposed to Python.

I just didn't want Jan to be the only one upvoting the significance of this particular area.

I don't want to discount the idea that plugins could make use of some info from custom design rules. All I am saying is, this is a separate issue, despite the functional area being similar, to the regression that caused problems with board design settings.

reopened

closed

AttributeError: module 'pcbnew' has no attribute 'TEXTE_PCB'

kicad 6.0.9 python 3.914

Pbnew Python API: Cannot to set board design settings

Description

Steps to reproduce

KiCad Version

Designs

Child items ...

Activity

Pbnew Python API: Cannot to set board design settings

Description

Steps to reproduce

KiCad Version

Relates to

Activity