Re-use of layouts (multiple times or on another board).

Registered by Martin Errenst

Motivation:
The current implementation in KiCad doesn't allow the easy re-use of layouts. (You can append boards, but this is only for fast creation of panelized boards - this can be improved to [0]).
Lets use the following examples for the blueprint:
I: You've got an nice power supply circuit for your board, now you want to re-use it in different projects.
II: A project needs multiple input channels for sampling data. Those channels are all the same.

How would one handle this situation with the current implementation in KiCad?
I: Route the power supply once, save it as it's own layout and schematic, each time you start an project and want to use this power supply, you'll use it as template for your project.
Downsides of this approach:
* If you want to move the already routed power supply, you'll quite likely run into problems due to limitations of the selection tool (given the that your layout doesn't fit in a oblong, or you've got tracks passing below).
* If there is an bug in the layout, you cannot easy fix it in all projects because it has become an individual part of the circuit (it's closely embedded into the boards file). Also re-annotation might cause some problems (it'll be quite a hassle to figure out the sub circuit that reassembles the initial power supply if the re-annotation changed references on the parts).

II: Route the channel once, use some scripts[1] to copy the parts.
Downsides:
* Same as above, you'll have individual circuits in the board file, if you made an mistake, you either have to fix it by hand in all channels, or re-run the script and deal with side effects...
* Like above, moving a channel might not be trivial due to tracks and other parts being beneath or close to the channel.

Proposal:
Both examples should use hierarchic sheets. Each sub-sheet that represents it's own board layout, needs it's own, stable, annotation to keep the schematic and layout in sync -> option needed to disable automatic (re-)annotation for given sub-sheets.
Given the sub-sheets. got an stable annotation, CvPcb should allow the user to select a board layout for the complete sub-sheet [2]. The schematics need some special elements before one will add the hierarchic labels (maybe a two pin compentent, if it's important to define exactly one point to connect the "outer" circuit, if it's only like an label, the user will be able to connect to the whole net).
In Pcbnew, the layouts should be imported like an module. This would solve the problems with the movement of the whole block. The special elements (mentioned above) should be handled like pads of an ordinary part. Therefore, we need to allow tracks in the module definitions - this would also fix the problem of the current microwave tools - they create graphic segments on the copper layer, which are not checked by the DRC for collision. Also it'll fix the problem, that it's not possible right now to get the length of an "track" created with the microwave tool.

Needed changes:
Eeschema:
* Option for sheets to exclude them from (re-)annotation.
* Special part/label needed to denote the juncture to the sub-schematic.
CvPcb:
* Needs awareness about sheets.
* Needs a list with board layouts (like the footprint libs).
Pcbnew:
* Has to check for the minimum number of layers needed by all "sub-boards".
* Has to treat the special junctures as pads while performing the ratsnest with embedded layouts.
* Allow normal tracks (segments) in the module "blocks" (seen from the file format view) / footprints.
* Allow nested module blocks.

Further changes:
* If the modification of an board layout block is really needed, the elements should be move one layer up in the hierarchy, the encapsulation dropped and the parts re-annotated in the schematics / CvPcb (given we have working re-annotation).
* Allow the user to swap inner copper layers while assigning the board to as sub-sheet in CvPcb.
* Make it possible to add pads in Pcbnew, this will make the module editor obsolete. All we need in Pcbnew is the option to save as footprint (but again, there's no big difference left) - all the actions, like drawing on the silkscreen and such, are already in Pcbnew.
* Add some visual hints for the imported layouts (maybe another layer, containing zones).

Open Problems:
* If we've got the same board multiple times in the same schematic, how do we handle references? Simply renaming them or adding a pre/postfix to the current name?

Advantages:
* Faster creation of boards with multiple channels.
* Users will be able to share parts of an circuit (besides the whole circuit), this will result in an big speedup, due to the fact that effective re-use of building blocks is now possible.
* Easier panelized boards, because you won't need perfect aim to move the layout close to other layouts. Also you can set the grid to the correct size for the grid and it's nearly done.
* DRC can now deal with the modules created by the microwave tools.
* Pcbnew can now display the correct track length (due to the change from fp_line to segment).

[0]: If you append an board right now, you can move it's individual parts - this allows the user to make mistakes while selecting the board and moving it. An imported board should only be movable as whole and by individual parts, maybe add an switch to allow movement of elements.
[1]: http://code.google.com/p/klonor-kicad/
[2]: It might show one the list of parts from the schematic too, but as disabled items if the schematic has it's own layout assigned. This will give the user generally some more information while assigning footprints without the need to look at the schematic at the same time.
  part a -- sm0603
  part b -- sm0603
  sheet c -- board c
  |`-> (part d -- sm0603) <- unable to change
  |`-> (part e -- sm0603) <- -"-

Blueprint information

Status:
Not started
Approver:
None
Priority:
Undefined
Drafter:
Martin Errenst
Direction:
Needs approval
Assignee:
None
Definition:
Discussion
Series goal:
None
Implementation:
Unknown
Milestone target:
None

Related branches

Sprints

Whiteboard

(?)

Work Items

This blueprint contains Public information 
Everyone can see this information.