Multiple sheets at same hierarchy level


#41

[quote=“steveny732, post:33, topic:2632”]
Not sure why you’re vehement insistence that schematic capture not work like every other ECAD package I have used for the past 30+ years.[/quote]

It’s not “vehement insistence.” Its the recognition that “this is how Kicad works” combined with having been bitten by Altium’s handling of this multiple flat sheet net handling. I think my question was, 'is it really so hard to just create a top-level sheet?"

[quote] Flat schematics with common signal names being the same net is the norm. It maps well into the PWB physical implementation.’

If you’re drawing your schematics I’m a way that maps to the board layout, all due respect but your boards must not be very complicated. The last day job board I did is the size of a playing card but it’s packed on both sides with all sorts of stuff, including a big FPGA, and attempting to draw a schematic that looks like the layout would be impossible.

We draw schematics so the human engineer or tech can understand the design.

Yes, and what’s missing from EESchema is the way to generate those sheet references. But what difference does it make if it’s a hierarchical off-sheet symbol or flat design symbol? (Again, I don’t care, I just do what Kicad currently supports.)

Ah, but with channels, hierarchical sheets in EESchema really shine. I did an audio thing (monitor controller) with several identical inputs and outputs, and I made extensive use of hierarchy. I drew a page once and instantiated it several times. Much less schematic clutter, and EESchema easily handles making unique reference designators, local net labels and mapping higher-level signals to the lower-level instances. (Of course this feature exists in Altium and other tools.) So there is no need to copy sheets if you’re making a channel-type design.


#42

I don’t have a problem with Kicad using channels. However I don’t think Kicad should prohibit someone from using a flat paradime. I don’t believe the two paradimes are mutually exclusive, Kicad should be able to support both and would be a much better tool set if it did.


#43

Long ago all my designs were flat, because several package that I was using all had serious,hierarchical bugs


#45

I agree with your wish that Kicad supports the different design paradigms, but since this is a user forum and not a developer forum, the best way to let the developers know that you care about this issue is to file a wishlist bug, or indicate that a previous bug affects you. And I see that someone has already opened an item about this: https://bugs.launchpad.net/kicad/+bug/1688717


#46

I think this is what is being missed.

I wonder if it would be difficult to add a feature where extra sheets could be added to the top level.

Would this fix the OP’s problem?


#47

The problem is that you really shouldn’t have to accept that. Being forced to introduce unnecessary hierarchy simply because you ran out of space on the page is a workaround, not a solution.

It’s more than just lower level sheets. Having to add potentially dozens of hierarchical pins and connections when there is no functional or logical reason for the hierarchy adds extra design time and unnecessary complexity, when a simple “schematic, page 2” would be much cleaner.

Sure, it’s a workaround for people who can’t, or prefer not to, use increasingly larger page sizes, but it’s something that makes larger designs more cumbersome than they need to be and should be addressed at some point.


#48

This approach can be achieved with another sheet at the same level with global labels.
The extra design for “schematic, page 2” is another rectangle.

About “increasingly larger page sizes” I agree: A3 or bigger page sizes is really cumbersome.


#49

There seems to be a major misunderstanding here, there is no need to use hierarchical pins. You can create a flat, multi-sheet schematic, using global labels.The top level sheet can be the container for other sheets.

I think if people are going to request new features, they should at least get to know what can do done currently, instead of jumping to “KiCad is unusable without feature X”. On a practica sidel, it usually takes several years to get major new features so in the meantime you are going to have to get used it.


#50

Yes, you can use global pins, but this is also really just a workaround. This would work fine in a simple case where you have, for example, only one schematic that you want to divide into two or three pages. Where it becomes problematic is if your design is more complex and has desired hierarchy as well. For example, if you have two schematics at the top level of hierarchy because the hierarchy makes sense for them, and each one of those two schematics is itself composed of two schematics that are being used where extra pages would make more sense, then you will have to plan your global signal names very carefully in order to avoid unintended shorts, etc. Again, it’s not impossible, just cumbersome and unnecessary if you could simply enlarge a schematic by adding a “local” second page.

Despite being a new user of KiCad, I have read through the documentation and am aware of global connectors and how they work, but I still view it more as a workaround and not the best ultimate solution. Just my humble opinion, which may well be different than others.

And sure, sometimes new features take a while to implement, or maybe they are lower priority than some other new features. That’s fine, I don’t see anyone insisting that this be done by tomorrow, just that some people feel it is a better long term solution. It would be adding a methodology that works better for some people and designs without taking away any of the existing methodologies.


#51

Hi @berkakinci
when I need a quite big page, but without hierarchy and printable, I use this workaround:

  1. make a User page like i.e. 2xA4 (594mmx210)
  2. put a delimiter inside the page to highlight the portion of printing page#1 and printing page#2
  3. put all your design in it
  4. plot your big page to a pdf
  5. split the pdf with i.e. Briss or pdfplotter or with just a python script to split the pdf
  6. print your splitted page to multiple i.e. A4 pages
    testpdf.sch (491 Bytes)
    double-page.pdf (8.6 KB)
    double-page-splitted.pdf (8.6 KB)

I know it is a workaround, but it works quite easy… zooming is also an easy feature…

you only need to post processing the pdf before printing

Maybe adding a tiled option when printing/pdf-plotting to the wishlist could be achieved faster than the flat level sheets

Maurice


#52

2 x A4 = A3 which is the size I use for everything but the most trivial schematics but then I also have an A3 color printer.

I think this would be handy regardless.


#53

my 2 x A4 is 2 A4 page horizontally aligned… for me it is much easier to manage when designing
(2x A4 horizontal -> h=210, w=2x297; 2x A4 vertical -> A3 -> h=297, w=420)
I don’t like A4 vertical (I don’t use the monitor rotated vertically, though I could) … :slight_smile:


#54

Ah, I follow you now.

I use mostly A3 unless it’s a simple schematic. A3 printed on A4 is still quite readable but it’s nicer in color on A3. But I can also use A2 and print to A3.

But being able to print A3 to two A4 pages etc. would be a nice feature.


#55

This is even worse than needing careful planning and having accidental shorts. I’ll go back to my server motherboard schematic example again. Consider 4 channels of DDR memory w/ 2DIMM/channel. If you have gone down the path of using global signals, you are left with a single choice: make 4 different hierarchical blocks just so you can rename each net not to short to the other channels. It completely negates the use of hierarchical blocks in the first place.

I’ve suggested a version of this approach in the feature request. I would like to have multiple title blocks and automated handling of this “workaround,” though. I think this is the fastest path to implementing the intent of this feature without ripping up the underlying architecture.

I am getting the sense the developers are not interested in this feature. May be someone with key developers’ ears can respond. I suspect this proposal doesn’t match the developers’ vision of how this application should work. I find that odd; this is a very basic need for a schematic capture application. Again, I accept that I’ve been tainted by the 15 years of using commercial ECAD applications. However, after over a year of discussing this topic, nobody has been able to propose an acceptable and scalable way to use KiCad with a big design. The current implementation can barely capture an RPi hat; it just doesn’t scale well.


#56

If the dead horse won’t get up and walk, flog it some more!

KiCad works well enough for 99.9% of people, there is little incentive to satisfy the other 0.1%, especially if it means a whole lot of new code.

You really only have 3 options:

  1. write some code
  2. sponsor someone else to write code
  3. use a different tool

#57

Sorry; I’m contributing as an experienced user, not a developer. About option #2: who is taking requests? CERN is understandably not interested in matching donations to projects.


#58

There are many places you can hire coders.


#59

I think your 0.1% estimate is low by at least one, perhaps two orders of magnitude. I do, however, agree with the comment about new code.

Dale


#60

Yes, I find using unsourced numbers always makes me uneasy, even if only used for rhetorical purposes. I don’t know how many KiCad users there are, I think recently the devs started count downloads, I don’t know if those figures have been published anywhere. I guess the number runs into several thousands, let’s say 10,000.

Judging the number of users interested in a particular feature can be gauged from the bug tracker, the number of users saying “this affects me” for this particular feature is 6.

Therefore that would give 0.06%, which is where 0.1% came from. Of course, that is only a rough estimate, it could be quite low/high in either direction.

It’s only possible to guess how many users have looked at KiCad and rejected it as unsuitable, some sort of survey would be needed to get reliable numbers. Anecdotally, I guess the number of posts I have seen by people saying such things is quite low, maybe 10.


#61

I still have not created a GITHUB account; means, the bugs affect me, they just don’t know it yet.

Just to be clear, I don’t think any of the current bugs I know about are important enough for me to say, “Me too!!!”

And, I DID download a version of KiCad to help developers chase down a bug; which screwed up my install.

Just my opinion.