Reusable hierarchical sheets and simulations

[Mariusz Plucinski]

Hi all,

I'm new here, and to KiCad in general. Trying to come up with a workflow
that'd suit me best, I encountered some limitations. So here I am,
looking for advices on how to lift them, and how to convert my ideas
into contributions suitable for the mainline :)

My troubles revolve mostly around the hierarchical sheets feature. I
want to use them as a kind of reusable components (akin to how I use
libraries when writing software), to avoid copy-pasting parts of
circuits between my projects. So I put the common parts into separate,
"child"-projects (in separate directories) and refer to them as
hierarchical sheets in my "parent" projects. I want the "child" projects
to be self-contained - standalone viewable and testable, and at the same
time, include-able to other, "parent" projects.

It's working in general, but here and there I face a few rough edges.
One of them are simulations, which currently don't work at all in my
"parent" projects. It's not even possible to open the simulator window
there. All I get is the message "Simulation model library not found ...".

I identified as a problem the fact, that relative sim.library paths are
resolved in respect to the current project path only. In my case, it
fails because they've been originally set in a project that's located
elsewhere. So, trying to solve this issue, I've come up with this
(work-in-progress):

https://github.com/mplucinski/kicad-source-mirror/tree/sim

With this change, the search for the library also includes the path of
the sheet. This way, I'm able to use the simulator from a "parent"
project, at least in very basic circuits. However, there's still some
issues I'm not able to solve:


1. It's still not possible to open the "simulation model" window from
the "symbol properties". I don't know, how to access the SCH_SHEET_PATH
from DIALOG_SYMBOL_PROPERTIES (see "FIXME" in the change above).
Logically I'd expect it in SCH_SYMBOL, but I can't see it there (I
probably misunderstand the meaning of this class a bit). Any suggestion?


2. In some projects, I cannot start the simulation from the "parent"
project, regardless of the selected sheet. I get only weird errors like

> Error: Transient op failed, timestep too small

> Error: The operating point could not be simulated successfully.

Which is confusing, because it works fine, if opened from the
"child"-project so all parameters should be accessible. Timestamps are
specified in text labels and "Edit Analysis Tab..." shows that this
value ha been properly imported. Here I'm stuck, because I don't even
know how to analyze this issue (especially since it works fine in some
projects).


3. Is that a good approach in general? Do you see this (and potentially
further fixes in this area) as something useful for the KiCad project?


Thanks,

Mariusz Plucinski

[Wayne Stambaugh]

Hello Mariusz,

On 5/1/24 9:42 AM, Mariusz Plucinski wrote:
> Hi all,
>
> I'm new here, and to KiCad in general. Trying to come up with a workflow
> that'd suit me best, I encountered some limitations. So here I am,
> looking for advices on how to lift them, and how to convert my ideas
> into contributions suitable for the mainline :)

Thank you for interest in contributing to KiCad. Unfortunately, it
sounds like you broke one of the cardinal rules of contributing to an
open source project. You wrote code before checking with the
development team to see if someone is already working on this. In your
case they are.

Shared schematics are going away in version 9 of KiCad and will be
replaced with reusable schematics (part of a larger design blocks
feature set) that get copied into the new project without out making any
changes to the original schematic.

We already have developers planning to work on this. I haven't looked
at your code but I suspect most if it will clash with the changes above.

>
> My troubles revolve mostly around the hierarchical sheets feature. I
> want to use them as a kind of reusable components (akin to how I use
> libraries when writing software), to avoid copy-pasting parts of
> circuits between my projects. So I put the common parts into separate,
> "child"-projects (in separate directories) and refer to them as
> hierarchical sheets in my "parent" projects. I want the "child" projects
> to be self-contained - standalone viewable and testable, and at the same
> time, include-able to other, "parent" projects.
>
> It's working in general, but here and there I face a few rough edges.
> One of them are simulations, which currently don't work at all in my
> "parent" projects. It's not even possible to open the simulator window
> there. All I get is the message "Simulation model library not found ...".
>
> I identified as a problem the fact, that relative sim.library paths are
> resolved in respect to the current project path only. In my case, it
> fails because they've been originally set in a project that's located
> elsewhere. So, trying to solve this issue, I've come up with this
> (work-in-progress):

Using absolute paths should solve this issue.

>
> https://github.com/mplucinski/kicad-source-mirror/tree/sim
>
> With this change, the search for the library also includes the path of
> the sheet. This way, I'm able to use the simulator from a "parent"
> project, at least in very basic circuits. However, there's still some
> issues I'm not able to solve:
>
>
> 1. It's still not possible to open the "simulation model" window from
> the "symbol properties". I don't know, how to access the SCH_SHEET_PATH
> from DIALOG_SYMBOL_PROPERTIES (see "FIXME" in the change above).
> Logically I'd expect it in SCH_SYMBOL, but I can't see it there (I
> probably misunderstand the meaning of this class a bit). Any suggestion?

The SCH_SHEET_PATH object is for handling instance data across shared
schematics in a project. Only symbol references and units are part of
the instance data. You do not need to use them for simulation models.

>
>
> 2. In some projects, I cannot start the simulation from the "parent"
> project, regardless of the selected sheet. I get only weird errors like
>
> > Error: Transient op failed, timestep too small
>
> > Error: The operating point could not be simulated successfully.
>
> Which is confusing, because it works fine, if opened from the
> "child"-project so all parameters should be accessible. Timestamps are
> specified in text labels and "Edit Analysis Tab..." shows that this
> value ha been properly imported. Here I'm stuck, because I don't even
> know how to analyze this issue (especially since it works fine in some
> projects).

Simulations are done at the project level not the sheet level.

>
>
> 3. Is that a good approach in general? Do you see this (and potentially
> further fixes in this area) as something useful for the KiCad project?

My guess is your code wont be useful since we are going in a
significantly different direction by eliminating sharing sheets between
projects. I hope this doesn't discourage you from working on KiCad.
You just need to check with the dev team on the mailing list to make
sure your not working on something that someone else is already working on.

Cheers,

Wayne

>
>
> Thanks,
>
> Mariusz Plucinski
>

[Mariusz Plucinski]

Hi,

Am 01.05.24 um 20:50 schrieb Wayne Stambaugh:

> Hello Mariusz,
>
> On 5/1/24 9:42 AM, Mariusz Plucinski wrote:
>> Hi all,
>>
>> I'm new here, and to KiCad in general. Trying to come up with a
>> workflow that'd suit me best, I encountered some limitations. So here
>> I am, looking for advices on how to lift them, and how to convert my
>> ideas into contributions suitable for the mainline :)
>
> Thank you for interest in contributing to KiCad.  Unfortunately, it
> sounds like you broke one of the cardinal rules of contributing to an
> open source project.  You wrote code before checking with the
> development team to see if someone is already working on this.  In
> your case they are.
>
> Shared schematics are going away in version 9 of KiCad and will be
> replaced with reusable schematics (part of a larger design blocks
> feature set) that get copied into the new project without out making
> any changes to the original schematic.
>
> We already have developers planning to work on this.  I haven't looked
> at your code but I suspect most if it will clash with the changes above.

Huh, that's interesting. Any place I can read more about the planned
feature of reusable schematics? I'm wondering whether they'll fit my
preferred workflow better.

Perhaps I should've asked, but I was curious what's wrong, and it was
just some short tinkering - so I don't care... at least I got familiar
with the source code.

> Using absolute paths should solve this issue.

Yes, but it'd introduce others, like inability to open the projects on
another machine. Which I do quite often (I sync the complete tree, but
absolute paths differ).

> My guess is your code wont be useful since we are going in a
> significantly different direction by eliminating sharing sheets
> between projects.  I hope this doesn't discourage you from working on
> KiCad. You just need to check with the dev team on the mailing list to
> make sure your not working on something that someone else is already
> working on.

Sure, I'm stopping my efforts for now then. I actually had some more
ideas for hierarchical sheets, but since you're dropping them soon,
there's probably no point in exploring that. I'll focus on other pain
points, but that's for another thread.


Thanks

Mariusz

[Wayne Stambaugh]

Hi Mariusz,

On 5/2/24 1:50 PM, Mariusz Plucinski wrote:
> Hi,
>
> Am 01.05.24 um 20:50 schrieb Wayne Stambaugh:
>> Hello Mariusz,
>>
>> On 5/1/24 9:42 AM, Mariusz Plucinski wrote:
>>> Hi all,
>>>
>>> I'm new here, and to KiCad in general. Trying to come up with a
>>> workflow that'd suit me best, I encountered some limitations. So here
>>> I am, looking for advices on how to lift them, and how to convert my
>>> ideas into contributions suitable for the mainline :)
>>
>> Thank you for interest in contributing to KiCad.  Unfortunately, it
>> sounds like you broke one of the cardinal rules of contributing to an
>> open source project.  You wrote code before checking with the
>> development team to see if someone is already working on this.  In
>> your case they are.
>>
>> Shared schematics are going away in version 9 of KiCad and will be
>> replaced with reusable schematics (part of a larger design blocks
>> feature set) that get copied into the new project without out making
>> any changes to the original schematic.
>>
>> We already have developers planning to work on this.  I haven't looked
>> at your code but I suspect most if it will clash with the changes above.
>
> Huh, that's interesting. Any place I can read more about the planned
> feature of reusable schematics? I'm wondering whether they'll fit my
> preferred workflow better.

There is not a design document for preventing shared schematics. That
one is in my head. There is one for schematic design blocks. If you
would like I can send you a link to it for you to view. We don't make
design docs publicly available to cut down on the noise so you can
either provide an email address or send me an email directly. My email
address is easy to find in the KiCad source code.

>
> Perhaps I should've asked, but I was curious what's wrong, and it was
> just some short tinkering - so I don't care... at least I got familiar
> with the source code.

I was under the impression that you were considering contributing you
code to the KiCad project. I wanted to make sure you understood that
this particular feature already has owners that are actively working on
them. I apologize for any confusion. The KiCad project encourages you
to tinker to your heart's delight. It is the best way to learn the
KiCad code base.

>
>
>> Using absolute paths should solve this issue.
>
> Yes, but it'd introduce others, like inability to open the projects on
> another machine. Which I do quite often (I sync the complete tree, but
> absolute paths differ).

Unfortunately, I don't see an easy way around this. Child sheets do not
have any concept of a parent sheet when edited outside projects they are
used. We might be able to walk up and down the schematic file paths to
find simulation models with relative paths rather than assume the
correct path is the current project path. There are several other
options such as embedding them in the schematic or creating library
table access. This needs some thought and careful planning.

>
>
>> My guess is your code wont be useful since we are going in a
>> significantly different direction by eliminating sharing sheets
>> between projects.  I hope this doesn't discourage you from working on
>> KiCad. You just need to check with the dev team on the mailing list to
>> make sure your not working on something that someone else is already
>> working on.
>
> Sure, I'm stopping my efforts for now then. I actually had some more
> ideas for hierarchical sheets, but since you're dropping them soon,
> there's probably no point in exploring that. I'll focus on other pain
> points, but that's for another thread.

We are not dropping hierarchical sheets. We are preventing schematic
files from being directly shared by multiple projects. These are very
different concepts even though they are closely related.

Kind Regards,

Wayne

>
>
> Thanks
>
> Mariusz
>
>