A request. Is there a way of requesting that new features here?
I think the way hierarchical sheets is implemented is ridiculous and not fit for purpose for the average user! Why can’t we just have the option of extra sheets which by default pick up the labels and net lists from others. I just don’t see why we have to go through the pain of ‘joining’ sheet’s inputs and outputs. The vast majority of use just want to have extra space for sub-circuits not sub-assemblies so that they can easily be printed out (probably) on A4.
Therefore I request a new feature - able to add extra basic ‘sheets’ to Eeschema and not the full blown hierarchical nonsense.
Use global labels. Then you do not need to use hierarchical pins.
Hierarchical pins have their benefits. They allow you to have different layers of abstraction. (Top sheet is the system level, next level down goes into more detail and so on.)
Using only local labels and hierarchical pins allows multiple instantiation of the same schematic. This can already be useful if you have a common ESD/EMI protection circuitry that you want to use on a large number of pins. But mostly for when it gets a bit more complex.
Thanks for the reply, I didn’t know about Global Labels.
However, I still feel my original point has some merit, have ‘Sheets’ a well as Hierarchical Sheets. Clearly there are reasons why the developers opted for HS, but to me I just want to quickly organise my sub-circuits to match my hand drawn paper based schematics and get them printed out neatly.
Being able to just click on an icon and have another blank sheet appear ready to go is preferable and similar to other packages.
Multiple pages on the same hierarchical level can indeed be useful. However as there is an easy to use workaround for most use-case i would guess that it simply has a very low priority.
If you got a really good idea you might want to register at launchpad and file a bugreport with feature request.
If you’re also a programmer you might want to join the mailing list and get your hands dirty.
PS: you might want to change your attitude a bit though, before you go on either endeavor, as wordings like “not the full blown hierarchical nonsense” will not win you any friends around there.
I already linked a feature request above. So please do not make a duplication of that report, add your voice to the existing one. (By clicking the “affects me as well” button and possibly by contributing to the discussion)
A lot of the recent feature requests are pretty trivial stuff, I guess that shows that KiCad has matured to the point where people can find only tiny details they don’t like.
There’s over 400 wishlist requests, it think a lot of them will never be implemented.
On the other hand, if you sort them by “bug heat” (ie: how often they’ve been requested), you’ll find that this one is #11. So its chances are pretty good.
I haven’t seen any correlation between bug heat and how likely a feature is to be implemented. Wayne has stated "I am not interested in making kicad popular. I am interested in making kicad better " and other similar statements so I think that represents his approach. So popularity of a feature request may not mean much.
The chances of implementation seem to depend on :
how simple the change is
how well it fits to KiCad “style” (including coding, architecture and UX)
but mainly whether a developer takes a personal interest
Now, if you said that you were interested in implementing this feature then I think it would be much more likely to get implemented
It’s a style preference thing. I don’t think hierarchical sheets are a “waste of time”- I love them and use them extensively. I dislike “flat files” where to find where a signal originates or is consumed you have to flip through all the sheets.
Schematic style standards are changing- the idea of “wiring” a schematic where the net goes from source to destination as a continuous line seems to be going out of favor. Each pin now has a short wire with a global label, and you make sure the labels agree. I assume you can “ctrl F” and search through of course.
But please keep hierarchy!
Perhaps the only fix we need is to call them “subsheets”, because “hierarchical” seems to be a sticking point for some people.
I do plenty of multi-sheet schematics with global labels, never had a problem with that.
It would be nice to have a list of sheets in a window (like Eagle ), and the ability to just do “Add sheet” without having to draw a sheet and do the dialog - that could be streamlined a lot. Just add a sheet object to current page with default size and names, e.g. “sheet2.sch” “Sheet 2”), and the user edit the properties if they need to.
That’s simple GUI stuff and doesn’t need any big changes, but I guess when eeschema is written with a new format the architecture might change a lot.
What I’d like is a dynamic element to put in the schematic that gets updated when sheets are added and removed. On a deep tree hierarchical project I’d put the navigator object on the first page as a sort of “table of contents” type of documentation for prints. Currently I simply screen capture the hierarchical navigator and import the image to the top level. But that has a couple issues. Inflates the schematic file size, resolution isn’t necessarily good for printing, and has to be manually updated as sheets are added, removed, or otherwise shuffled.
In my Racal days, using Zuken Visula, the company standard was to manually add balloons on each wire, next to the label, listing each sheet number the net went to ( a laborious and error prone process).
KiCad can find net instances in a project, but an easier and automated way of showing just which sheet used a net would be very nice.
One of my most frequent schematic errors is to accidentally split a net into two islands by some subtle name typo.
Multi-page schematics that are all at the same level, just broken up into multiple pages for readability
Hierarchical schematics that instantiate one page multiple times
Both have their place, and while you can force a multi-page schematic into a hierarchical scheme, the ability to create a multi-page schematic without having to instantiate the subsheets on a master sheet would be nice.
I have used tools in the past that have automatically added and maintained the off-page references on nets or global labels; this would be a nice addition,
/mike
Having multiple pages in any level can be helpful even in hierarchical design.
This is the usecase that can not be achieved with KiCad right now. Adding this feature is the topic of the linked feature request. (Every other usecase described so far can be achieved with the feature set of KiCad version 5 and even version 4.)
Case in point: A flat multi page design is possible by using the root page as an index page and using only global labels (And power symbols) inside subpages.
You still have to create the sheets somewhere… creating the sheets in a “master” sheet (all sheets are equal ) is hardly onerous. I guess the alternative is that the sheets are stored in the project file, that makes little difference to the user. It also requires file changes, which would need to wait for a major release.
The eeschema file format is due to be rewritten, I don’t recall if it has support for various types of sheet architecture. I suspect that unless someone makes a case for it, it will reflect the current paradigm.
As @Rene_Poschl says, it would be better to address the missing use case rather than tinker with what can already be done.
The reason you want Heirarchical sheets the way they are implemented is simple.
It makes that part of the circuit a black box you can just drag over into another project. I do this with an IRDA cirucit… there are only 5 labels outside of the hierarchical sheet. TX RX GND Vcc and Enable But I can use it in 5-6 different projects nearly unmodified and I just copy the sheet between them.
If it weren’t implemented this way reusable black box schematics would be harder to move between projects as you could have conflicting names.
I think a simple way to implement it would be to hide the root sheet, and the “create hierarchical sheet” would add a sheet with the current default naming convention that already happens, but requiring no user input unless the user wanted to edit them. The “view>hierarchical navigator” would be renamed the “sheet navigator” again hiding the root sheet.
Global nets would link the sheets.
So as I see it all the Eeschema file format would stay the same. When you loaded Kicad it would look at its own setup files, and see the user has the option “HierarchicalSheets = false” and Eeschema would change its menus/behavior to suit.
Now thats my 2c worth. I’m still attempting to get Kicad to compile and run on win10…so I’m a way off helping yet.
Nope, user preferences should never change file interpretation, or we risk generating files that cannot be opened properly by people with different preferences.
), and the ability to just do “Add sheet” without having to draw a sheet and do the dialog - that could be streamlined a lot. Just add a sheet object to current page with default size and names, e.g. “sheet2.sch” “Sheet 2”), and the user edit the properties if they need to.