Sheets in sheets in sheets in sheets

Schematic
1

Howdy peeps, the hierarchy logic is kinda making my head hurt and I think I’m going down the wrong path here. This is the most complex project I have undertaken so far.

This is my hierarchy as it stands.

SheetsInSheetsInSheetsInSheetsInSheets

Control logic contains my uC, a bunch of I/O expanders, LAN/WLAN modules, all the digital realm signalling. The other sheets are all real world interface stuff; PWM drivers, current monitoring, MOSFETs, SSRs, relays, all that guff.

I have 9 DC motors to control (Direct DC or PWM via a TLC5947, direction control via DPDT relays hanging off an MCP23017), I have to monitor them (8x hall effect sensors going to GPIOs on a RasPi and a bunch of end point switches on another MCP23017). My intention was to throw all the silicone in the control logic sheet and bus all my IOs out via hierarchical labels.

If I put all my motor drivers on one sheet, its going to wind up looking like 10 pounds of MOSFETs on a 5 pound PCB, I’d have four identical motor controllers and 5 that are unique in terms of current load and positional signalling. So then I think “ok, one sheet per type of motor driver under root?” which will blow my hierarchy list way out. But then I think “Right, pull the 5947/23017 into a new sheet under root with 6 sub sheets of motor drivers within that subsheet?”. At that point, that old feeling that I am walking a path to madness kicks in and I stop. I’m going to have the same problem with lighting section as well, because I have a wide variety of lights to drive, most with different current and control requirements. And again, some PWM driven, some direct DC.

I can’t find a single tutorial that covers something this complex, and I am too new to this level of complexity to be able to see a way out of the weeds. Can anyone suggest a style guide or tutorial or something that will get me out of the forest here? Thanks for reading :metal:

2

Well, it depends…
We can’t see the complexity of your project, many people are working on all sorts of projects, from very simple blinking led’s to big 10+ layer boards with a 20 page schematic. For any sort of decent advice we’d have to see your schematic.

Are you aware that you can use the schematic hierarchy to use multiple instances of the same sheet? For example, you draw a single motor controller on a sheet, and then you insert a reference to that sheet for as many motor controllers as you have. This cleans up the schematic considerably, also because you know all motor controllers wil always have the exact same schematic. Even if you change the schematic, you change them all at the same time, because it is just one schematic page. This also enables the use of the Replicate Layout plugin, which can replicate the layout for such sheets.

3

Hi Paul, sorry for the late reply, work, kids etc.

I wasn’t sure if it was in any sort of state to be usable as a demonstration and I suppose it is a general question about best practices when dealing with complexity, but schematic is attached. Lots of placeholder sheets and interconnects, likely incorrect values for components that I am yet to bench test and correct, and I’m still getting my head around buses, so please ignore the madness. I’m trying to get the skeleton right before I fully apply the meat.

As you’ll see the “outrigger controller” (one of the four that I was referring to in my OP) is currently nested under “Motor drivers”, the sheet I was intending to move the control logic to. But again, working in a relative void, I was not sure if this was considered a “best practice” or if there was a better way of doing it. As each chip controls various functions across multiple sub sheets (U4 on page 2 for example manages functions on pages 5, 6, 7, and 8) moving the logic to the sheet it is controlling is not really possible anyway. Which really only leaves me with the option to have subsheets in subsheets like where I was going on page 4. Bus everything in, pull the busses out to individual wires, then use hierarchical labels to go from that bus to each sub-sheet.

And yes, I am aware I can use the hierarchy to use multiple instances, as I was going to do with the outrigger controller. I just felt that now was a good time to pause and seek advice before I go too far down a wrong path. It does not appear to be easy to rename/number sheets if needed, so yeah, time to take a review before I need to rebuild the whole thing.

I hope this makes sense, because even in typing it out, it barely does to me :sweat_smile:

[Edit] I should note, a lot of these sheets will end up as daughter boards, the motor controllers, AC/DC management and others, which is another reason I am reluctant to move controllers away from a central motherboard.

Appreciate your insights Paul/all.

Redacted.zip (77.1 KB)

4

First a little sidenote: On outriggerController you are switching the relay between GND and GND. That does not work well. 1N4007 is also a very slow diode, I’d rather use a 1N4148 (or whatever) over the relay (Depending on how big it is)

If you want to control motor speed with PWM, you have to switch your MOSfet (Q4) fast. That does not work with a 180k gate resistor. This is a serious issue. Do some research into proper gate drivers.

I am also having some doubts about D5 & D6 (1N47xxA) I would probably rather add a freewheeling diode on the other side of the relay. That way it does not see polarity changes. Maybe add some more protection to the Fet too Although both 100V and avalanche rated is enough.

You are also using global labels. Use hierarchical labels instead, and then import those labels to the sheet level above it.

For the rest, I have not seen all sheets, have forgotten what this thread is about and have not woken up yet, so I’ll probably post a followup.

5

And again on the power supply sheet:

image
image825×451 9.07 KB

I don’t know what R2 is for, but U8 is switching the relay coil between GND and GND. Optocouplers are also useless when you connect both sides to GND. I have seen this copied a lot over the last few years, but that does not make the idea any better.

Also global labels used here. They are OK for when you want to use connections on a lot of different sheets (such as power distribution) but use hierarchical labels for the signals.

This is also bad practice:
image

The main goal of a schematic is not for data entry to make the PCB, but for humans to read. Think about that for a while. When a human can’t read / verify the schematic, then your PCB will be GIGO and a waste of time.

For easily readable schematics, use signal flow from left to right, and voltage flow from top to bottom. So don’t draw the LM7812 and it’s capacitors upside down. Adhering to such rules makes schematics easier to read, and they prevent mistakes.

6

On your power supply you are using 12V_REG 5V_REG, GND while on the Control.logic_sch.kicad_sch (One of the weirdest file names of the year) you are using VDD and VSS.

I also see hierarchical labels popping up now, but the names are all wrong. First, do not put both a hierarchical label and a local label on a bus. It’s just more maintenance and it introduces more opportunity for mistakes.

Bus labels are also not just names. They define the signals names in the bus.
With the bus names you define:

U6
OUT0
OUT1
OUT2
…
OUT24

(That OUT24 is probably one too many).

as signal names, while the actual signal names are:

FR_PWM
FL_PWM
RL_PWM
…

Overall, I can see you are struggling here. You are making beginners mistakes while at the same time making a big and complex project. That is a bad combination. Mistakes are easily hidden among all the other stuff, and correcting mistakes becomes time consuming on such a big project (such as fixing those over 60 bus labels, which probably all connect to somewhere else (after you’ve drawn the bus in a level higher), so that alone is 120 faulty names.

It also does not make sense to me to have a sheet with I2C going into an IC, then a bunch of other signals coming out and buggering off to some other sheet though a bus. Just put the I2C lines in the bus and put the whole IC on that other sheet. Most of the other stuff has been redacted, so I can’t tell what’s going on there. Too much has been erased and I can’t get an overview of what the whole thing is doing.

7

Thanks for the comprehensive critique, I do appreciate the time taken. I have done a lot of smaller scale stuff but nothing this complex which as you say, is showing. Part of learning is knowing when to ask for help, so here I am. I don’t want to eat up more of your time so you can read more about where I’m at with everything or just skip it.

Wall of text.txt
There are indeed a tonne of errors here, the 180K resistor should be in the ohms range, not kilo ohms, and still needs to be tuned to the Vgs etc values for the MOSFET, Pin 2 on U8 has to go to VSS as it is being driven by the RasPi. I will throw my hand up on the PSU layout though. You are right, it looked clear to me but someone (else) is going to need to review this at some point, I will revert to convention there. FWIW, putting the voltage flow "down to up" on those electrocaps did feel off.

As to the VDD/VSS - 12V_REG/5V_REG situation, the idea was to have all logic running from the 5V/GND pins of the Pi (VDD/VSS) with all “noisy” devices (relays, motors, contactors/SSR’s for control of AC/DC switching) being powered by the regulated circuit with optoisolators bridging the gap between logic level and power level. Primarily to keep power lines clean, but also to build in some fail-to-safe fallbacks if either the uC or one of the regulators fails for whatever reason (which is also why I’m using an external WDT). There is potential for user injury if the motors continue to operate without functional feedback mechanisms to keep them in check. Again, there’s going to be errors here, as I mention below, this is a concept schematic at this time.

That file/sheetname? I got nothing. As you can see I use CamelCase for everything, though one of the earliest iterations of this was created under the assumption I could have a PCB per sheet in the project manager, and that was the first sheets I started on. I may have munched something trying to rename it to fit the new scheme. That has been corrected, it itches my OCD knowing it’s there.

Bus labels are also not just names. They define the signals names in the bus.

The bus labels are a symptom of the cause, and again, it was at that point (and especially when I added J3 at the root and thought “wait, should these have signal names or function names?”) I thought I am doing something wrong here, which is why the i2c lines are plumbed into a bus at the root level but still have global labels on all other sheets. That was the point where I stopped. I mention an example schematic you posted o the forum below, based on that I have realised I need to split out my buses into sub-buses, {U3 GPA[0…3]} bussed to the direction relays for the outriggers, {U3 GPA[4…5]} to the relevant relays, {U3 GPA[6…7]} to their end points etc. That has not been done yet as I am still trying to work out if my hierarchy is correct or not.

The only thing that has been redacted is the name of the project and my company name, for obvious reasons. Nothing was removed apart from those names before upload, if it’s blank on your side it’s blank on mine, again because I got to this point and realised that yes, I’m not sure how but I’m doing this wrong.

At this time I am simply trying to work out how to lay this all out in the application so I have some sort of structured guide I can use as I further develop subsections of the circuit; a mind map using a schematic editor instead of butchers paper as it were. While I am doing my best to be correct as I go, there is a lot of placeholder stuff that needs to be breadboarded and tested before I come back and finalise values, component specs etc. Once that is established I will fine tooth comb everything on the way back through. Like I said. Lots of placeholder sheets and interconnects, likely incorrect values for components that I am yet to bench test and correct, and I’m still getting my head around buses, so please ignore the madness. :wink:

TL;DR of that block is that yes, to someone who knows this game inside out the schematic is a load of hot nonsense right now, which is why I was hesitant to post it. I recognise and acknowledge that it my approach may not be optimal, but this is how I as an individual operate and learn in this early stage of knowledge expansion I suppose. It is at least giving me an opportunity to error check before I get it 90% filled out then realise I need to redo great swaths of it.

You have already helped on bus labels in this thread however. I had figured based on the formatting requirements that they defined the signal names on the bus, but I am not clear on how I am supposed to know on the other end that U4 GPA3 is the signal line to trigger the tamper alarm?

I did find your excellent example here which has already helped me greatly, but it also seems to imply that you can arbitrarily create label names. What I failed to get from it was how to to tie the name “FR_PWM” to {U6 OUT0} so when you’re unfolding wires on the receiving end you would have something that allowed you to go “yup, this motor, I need to plumb it in over here”. For example, I’m not clear on where the additional 5 labels (Re, Fa, mohammad etc) came from in this bus, which is likely half my issue.

DoReMiFa
DoReMiFa767×426 90.7 KB

I feel like I am getting away from the point of the thread though. Have I at least got my sheet hierarchy set up correctly for what I’m trying to achieve? Everyone seems to have their own style (if YouTube and a lot of threads here are anything to go by), but I can’t seem to make the the Complex Hierarchy and Electrical Connections > Buses pages gel nicely in my head. Knowing I at least have the former dialled in will make me less fearful that errors will undermine my exploration of the later.

Thanks again for your time man.

8

Bus unfolding works with all names defined in either the label on the bus, or if you have a long list, you can move that list into the bus alias list. Bus aliases are part of buses :slight_smile: and described in the manual (Schematic Editor / Help and then search for whatever you want).

I noticed that you did not draw any buses on the top level to connect your hierarchical sheets. Did you forget about them, or did they got included in your redacting diligence?

9

Ok, this feature I somehow completely missed, Thanks for the nudge!

Nope, have not drawn them yet, I’ll patch them in once I work out the exact [redacted] of my hierarchical labels.

Shall I take it from you laser-like focus on everything but my sheet hierarchy that it is fine, I’m on the right track, and I should really stop procrastinating over rectangles and get focused on working out how to properly set up buses then? :stuck_out_tongue:

10

I can’t comment much on your sheet hierarchy because I see no direction in the sheet hierarchy. As long as the sheets are not connected, there is no hierarchy.

I think you are approaching it form the wrong side here. I would start with a few sheets, and then connect them and make that work, inclusive inter sheet connections with hierarchical labels and such. Then add another sheet, and make that work. It’s less overwhelming when you do it that way.

1 Like
11

All the points paulvdh has raised are valid and make sense.
And the “local” vs. “global” vs. “hierachical” labels can make your head spin.
“Local” apply to the current sheet and are just an anchored text on a wire or a bus. I tend to avoid using those for connections alone. A drawn wire or bus (with labels if needed) can be followed easily and fulfils the same function much better. But that’s an aside.

Talking hierachical sheets, there are two ways of of getting signals in and out of them: “global” and “hierachical” labels.
“Global” is not nice, because it forces you to scan all sheets visually to find every instance of the label. Unneceassary work and mistake-prone.
“Hierachical” is nice, beacuse it brings the label to the edge of the sheet, allowing you to place wires and buses between sheets and thus make a nice functional block diagram as top sheet.

I attach an example (I’ve shown it before as mixed-signal hierachical design).
Note that there are no global labels, and that the power supplies are available in all sheets.
Also that it goes down two levels sheet-wise.

AVS.pdf (610.2 KB)

It ERC checks with 0 warnings or errors, BTW.

12

Hello ML, thanks for chiming in and for the example schematic. Tidy work that will be very useful as a guide to better living.

Local and global I get, the names are consistent with their dictionary meanings. Local is confined to the sheet you’re playing with. Easy. Global is available across all of the workspace, but messy on complex schematics due to the potential for dozens of repeating instances. Similar to components and groups in some of the other CAD apps I use.

Hierarchical, being a system in which members of a group are ranked according to relative status or authority, doesn’t seem to apply quite so nicely. It implies that sheets/connections/buses must be ranked or placed in some sort of order of importance, weighted based on what they do (which may in fact be the case, I’m yet to deep dive into some of the info Paul provided last night). I almost feel like it should be local (to sheet), regional (applies to all [local]ities withing the area) and global (applies to all localities and regions on planet schematic). I’m sure once I have my head around it all this will prove to be woefully incorrect analogy though. KiCad is not a new toy and many, many smarter people than me have built it this way for a reason. There is no conceptual analogy for it in any of the other software I use is all.

I understand on an intuitive level that hierarchical labels are much better for sheet interconnects because as you say, you can see your wires without having to go diving in and out of sheets, which is why I started laying out placeholder labels. I have an I/O map in a document here that I was cross checking against to make sure I had all I/O routed and accounted for. But again, I have a lot to digest here. First task is going to be slashing this back per Paul’s advice and adding things back as I get to them. Will spend some time on it and come back for some more ear bashing once I have something to show. Thank you!

13

Yes, this is why it’s called a hierarchical design. On the “top level” KiCad has a single sheet of paper, and on that paper you put hierarchical sheets, which then form the next layer in the hierarchy. And this is recursive. On each sheet you can place hierarchical sheets, and each hierarchical sheet links to a paper canvas to draw schematics on. Hierarchical labels form a connection between a drawing sheet, to the hierarchical sheet (block), which is always one level higher into the hierarchy.

You can doubt whether the “top level” in the hierarchy is the “most important”. It is quite possible there is no electronic stuff on the “top level” at all, but just interconnecting wiring. But i’d think everyone can agree a hierarchical design adds layers. Sometimes this is an aid in organizing the schematic of a project. other times it’s horribly abused and results in a spaghetti monster.

14

ATSystems, the problem is that using hierachical labels is not really intuitive. You can’t start top-down from the top sheet.
You need to start by placing hierachical labels inside the sub-sheets. Intuitively think of the as IC pins on a custom IC.
Then you move one level up, select the sheet and choose the tool “Import hierachical labels”. This will allow you to place the labels along the subsheet edges.

15

And just like that, it all clicks into place. Magnificent, and again, wildly different from a lot of typical CAD workflows, which in my experience and observation is basically start with a cube of roughly correct proportions, bash some edges off, extrude some bits out, bolt some components on, hit it with texture or two and voila, hydraulic lifting platform. Here, we’re starting with a ram and a pump and working our way out. Neat.

I’ll hit this again during the week and see how I go with this new understanding, thank you both for your persistence. Greatly [redacted]!

16

Magnificent, and again, wildly different from a lot of typical CAD workflows, which in my experience and observation is basically start with a cube of roughly correct proportions, bash some edges off, extrude some bits out, bolt some components on, hit it with texture or two and voila

Your describing box modelling*, which is what you should avoid. Its a really inefficient way to approach things in the long run. In fact you should probably approach mechanical cads and DCC applications same way as described here, features represent functions.

* or one of the related but same idea approaches. Its usually the easiest way to direct model but is really bad once your complexity increases and you need to account for changes.