Inkscape Wiki - User contributions [en]

Connectors

2013-09-21T10:41:52Z

SebastianGoette:

'''Connector Tool Improvements'''

In Inkscape, it is possible to connect two shapes from their centers. But if you want to make a schematic with represent a family (for example), it's not possible to add connectors from an edge of a shape.

It will be great if connectors can be added to edge of shape, in a way that auto adaptation to "best path" is still possible.

Another idea is to implement a tool that can *restrict* the connector to vertical and horizontal lines only. For now, Inkscape is tracing straight lines or broken line if there is an shape in the path, but lines go in any direction.

It will be great if connectors can be configured in a way that they must avoid others shapes, AND pass through some specific points, AND stay even horizontal even vertical.

I do not speak yet about the functionality of making a little "bridge" when two lines cross each others and are not connected. This is a functionality that exists in M$ Visio but does not work very well :-/

Thanks for reading !

'''Printscreens'''

'''Comments'''

I'd like to formalise aspects of this project proposal. I'm the author of libavoid (the library used for routing in Inkscape) and the person who added the existing connector tool. I'd also probably be the most appropriate person to mentor this project if it were undertaken as a Google Summer of Code (GSoC) project. Below are some connector improvement tasks, along with some comments.

1) Drawing to shape edge, rather than bounding box:
Currently, the connector tool only draws connectors to the bounding box of shapes. It should (probably) instead draw them up to the first intersection point with the shape's stroke. This is probably quite easy to achieve now that lib2geom is included in Inkscape -- 2geom can find intersection points between lines or curves making up shapes. Otherwise, the old Boolean Ops code could be used instead.

2) Connector ports (Connecting to a specific point on a shape):
libavoid is able to route connectors to specific points. This work would require adding a GUI for this feature to Inkscape so that users could define connector ports on shapes. These would need to be editable through the canvas and the information saved and loaded from files. I think this activity, along with the other minor items on this list, would form the basis of a good GSoC project.

3) Orthogonal connector support (vertical and horizontal lines only):
This is something I am working on in libavoid right now. An initial version will be complete during the 2009 GSoC period, so this feature will shortly become fairly trivial to add to Inkscape.

4) Routing connectors through specific points:
This is not currently a feature of libavoid, though it is a fundamentally easy thing to do. I would be able to add this feature to libavoid fairly easily, and then the work would be in creating an interface for creating such points and working with them in Inkscape.

5) Visualising connector crossings:
libavoid can be queried to determine where connector crossings occur. Thus, Inkscape could be updated to use this information to modify the connector's path to visualise the crossings distinctly (such as by drawing a little "bridge").

6) Curved poly-line and orthogonal connectors:
Inkscape can return versions of poly-line or orthogonal connector paths with curved corners. This is purely an aesthetic improvement. Inkscape could be fairly easily modified to add an option for this and to use this feature of libavoid.

7) Routing preferences and penalties:
libavoid can provide routes that have less segments, or that have less large bends. It does this by penalising these features when determining the routes. These options could be exposed within Inkscape to give users more control over the quality of the generated paths for connectors.

I'm willing to mentor and assist an interested student who is willing to work on one or more of these tasks. -- Michael

==GSoC 2013 Project==
I spent this GSoC improving the connectors tool. Here is an overview of the changes:

* Added Points, 0-dimensional SVG elements (inkscape:point) with nothing but an X and a Y coordinate.
* Removed routing to *shapes*. Now, the ends of a connector must terminate in Points. The connector's path is always drawn up to that point and not clipped where it intersects some shape. To emulate the old behavior, place a Point on the shape's outline.
* Made the routing infrastructure more extensible. Now, libavoid routing is only one special case.
** Added simple, non object-avoiding straight and orthogonal routers.
* Modified the UI to accomodate the backend changes. Now, normal object selection is possible. Selections can contain both regular objects and Points.

===UI overview===
As previously, there is a connector tool in the main toolbar that will enter the connector editing context. In this context, shapes and Points can be selected and moved or deleted. To place a point, press Shift and click on the document. I found requiring shift to be pressed is necessary to avoid spurious points from being created everywhere I do not want them. Once a point is created, a connector can be started from it by clicking it. Once started, the connector can be aborted by pressing Escape or finished by clicking somewhere (including on other points). To select Points, shift-click them. Control-click and control-shift-click should work as in the normal selection tool, bypassing group restrictions.

To add a Point to a group, select nothing but the group and then create a Point by shift-clicking in the document. This part of the UI does not feel very finished yet as there is no way yet to remove a point from a group or to add it to one after the Point has been created.

===SVG changes===
These changes break compatibility with the old implementation since the code intersecting connectors with objects and finding object centers has been removed. I do not think that is too much of a problem since the old implementation did not appear to have found very widespread use (-- Sebastian).

SVG generated by the new implementation still contains connectors as Paths with a "inkscape:connector-type" attribute. This is a pretty bad hack that is to be fixed. The ends are indicated by URIs contained in the "inkscape:connection-start" and "inkscape:connection-end" attributes. This might change in future revisions to a single attribute containing a list of points to support intermediate points.

[[Category:Developer Documentation]]

SpecElectronicsCAD

2013-05-21T20:04:14Z

SebastianGoette:

=Electronics CAD with Inkscape‒Missing functionality=

Currently there is no ''nice'' open source electronics CAD tool. The largest
competitors are gEDA which I find awkward to use and KiCad which I find even
more awkward to use. Since a schematics editor is not much more than a
special-purpose flow graph editor and a PCB layout editor is in fact nothing
but a somewhat crippled vector graphics editor with some special-purpose
features added I think it is very promising to modify a general purpose vector
graphics editor to support the few special-purpose functions additionally
required by an electronics CAD tool.

==Scenario==
The electronics CAD process mainly consists of two parts: Drawing the schematic
and PCB (Printed Circuit Board) layout. Normally, you will first draw a
schematic and base your PCB layout off that. However, from then on you will
frequently change the schematic and layout and want to have your chages in the
one represented in the other.

A schematic is basically just a flow chart. The basic features are components
(symbols) taken from a library that are put on a grid (because you do not want
to mess around with a lot of manual aligning) and that are connected with wires
(represented by lines). Wires are always either vertical or horizontal and have
names for the signal the wire is carrying. Components have a list of attributes
(an unique id, value/voltage, part number, supplier etc.), some of which are
rendered on the schematic next to the component (normally these are id and value
or part number). Finally, you want some function to place text anywhere for
comments.

A PCB design in comparision is a little more complex. A printed circuit board is
a stack of plastic and copper foil. The copper foil is etched into such shapes
that when you solder components to it they are connected in just the right way.
There may be multiple layers of copper foil (up to more than 10) in more complex
designs. Two different layers of copper may be connected with a “via”, a small
hole whose inside surface is plated with metal. These vias may go all the way
from the top to the bottom of the board or just through a few layers in the
middle (the latter is more expensive but common in complicated designs). Similar
to vias, there are larger holes through which the leads of components may be
stuck for soldering.

The outline of the PCB may be irregular, and the board may have slots, holes and
even grooves.

Beyond the top- and bottommost copper layers, there are some special layers. On
each side there is a “solder mask” which is a varnish that protects any surface
that is not meant to be soldered on from dirt and oxidation (this makes the PCB
green or blue or red), and a “silk screen” layer which is a usually white paint
used to place human-readable markings with part numbers, ids, values, outlines
as well as comments, copyright notices etc. on the surface on the board.

A very important feature of PCB layout programs is called “DRC” (design rule
checking). The most important of several possible design rule checks is that on
the PCB layout traces do no touch and there always is some clearance between
them.

==Missing features==
===Hard===
* Extension of the Symbols code to an abstraction usable for components
** Auto reference generation (“C1”, “R17” etc.)
* Connectivity test/netlist generation/net names
* Trace routing tool with 45° outing
** This absolutely is a task for the graph connector tool
* Schematic ↔ PCB mapping (components added in the schematic are also added on the PCB, components (packages) on the PCB may be exchanged for other, compatible packages)
** To ease this, schematic and PCB layout could be placed on different layers of a single SVG file

===Not so hard===
* Gnd/other plane fills
** I think there already is a live path effect for that
* Clearance calculation/DRC
** This naturally is part of the netlist generation
* PCB layers
** Can be implemented by SVG classes. When SVG 2.0 comes around, these can be assigned z-order attributes.
** Most other parts of Inkscape do not need to be aware of these classes, they only need special treatment when exporting to PCB formats.
** PCB layer classes are assigned when creating a component. Some kind of GUI would be nice for this.
* File format support
** old Eagle format
** new (XML-based) Eagle format
** Gerber
** gEDA
** KiCad
* Page frame templates → The actual frame can be realized as a drawing on a locked layer
** Auto-insertion of document properties into text fields → This looks like some pretty straight-forward placeholder replacement to me
*** ...and part numbers/values
* non-rectangular page outlines? → Probably, Inkscape's ''page'' abstraction will not even be used for the board outline (but instead a layer containing a polygon will be)
* distance measurement tool‒ ''This is very useful even outside of electronics''
* object highlighting → Some limited version of this already exists in form of these quickly disappearing red path visualizations
** Should appear on mouse hovering (perhaps with mod key)
** Should highlight the ''whole'' object, not just paths/fills/etc.
** Perhaps render the object transparent with increased brightness on top of everything else?
* transparent/desaturated “see-though” rendering of inactive layers

==Connectivity testing/netlist generation==
===Algorithm overview===
* Select starting point
** Start with elements in descending net name priority: first human-set names, second everything derived from default pin names, third just make up names
* Find overlapping or touching elements
** Does not seem too complicated. Since the heavy lifting is done by 2geom this could be implemented in python.
** Propagate net names (via labelling new parts)‒this is basically flood fill

===Net names===
* All pins/traces/planes ought to have net names
** Net names have a “priority” (an integer): 0 for auto-generated names, 100 for names derived frmo default pin names and 200 for manually-set names
* After propagating existing names, start assigning generated names to unnamed elements and propagate these

===Starting points for the algorithm===
* Pins/pads, traces, planes
** Generate names for pins by using the default net name of the pin (“CLK”). Check whether the name already exists in the document and if yes, append a number to the default net name (“CLK2”). Repeat until an unique name has been found.
* Find those by just iterating through the object tree → even pins should be found there despite them being part of a component

===Dynamic updating===
* Dynamic updating should be the normal case. When something is removed, the connectivity of its former net has to be re-checked.
** If there is a netsplit, drop the old net name, then search the two net parts for two starting points for the aforementioned algorithm. If none are found, just use ''any'' element.
** If there is an addition to an existing net (and thus a name collision), do the obvious: Use the name with the higher priority

==Component abstraction==
Inkscape's symbol functionality already supports most of this.

===Component features===
# Like groups, components group objects together
# Components have some metadata/parameters associated with them
# The parts of a component may be on different PCB layers (i.e. be assigned different PCB layer classes)
# Components can have ''terminals'' or ''pins'' (for trace routing and netlist generation). This nicely maps to the ''point'' elements described in the SVG Connector draft

===Required code===
* Python interface for parametric symbol generation

==See also==
[https://bitbucket.org/boldport/pcbmode PCBmodE]

The [https://google-melange.appspot.com/gsoc/proposal/review/google/gsoc2013/jaseg/1 GSoC Proposal]

The [http://dev.w3.org/SVG/modules/connector/SVGConnector.html SVG Connector draft]

SpecElectronicsCAD

2013-05-21T20:01:43Z

SebastianGoette:

=Electronics CAD with Inkscape‒Missing functionality=

Currently there is no ''nice'' open source electronics CAD tool. The largest
competitors are gEDA which I find awkward to use and KiCad which I find even
more awkward to use. Since a schematics editor is not much more than a
special-purpose flow graph editor and a PCB layout editor is in fact nothing
but a somewhat crippled vector graphics editor with some special-purpose
features added I think it is very promising to modify a general purpose vector
graphics editor to support the few special-purpose functions additionally
required by an electronics CAD tool.

==Scenario==
The electronics CAD process mainly consists of two parts: Drawing the schematic
and PCB (Printed Circuit Board) layout. Normally, you will first draw a
schematic and base your PCB layout off that. However, from then on you will
frequently change the schematic and layout and want to have your chages in the
one represented in the other.

A schematic is basically just a flow chart. The basic features are components
(symbols) taken from a library that are put on a grid (because you do not want
to mess around with a lot of manual aligning) and that are connected with wires
(represented by lines). Wires are always either vertical or horizontal and have
names for the signal the wire is carrying. Components have a list of attributes
(an unique id, value/voltage, part number, supplier etc.), some of which are
rendered on the schematic next to the component (normally these are id and value
or part number). Finally, you want some function to place text anywhere for
comments.

A PCB design in comparision is a little more complex. A printed circuit board is
a stack of plastic and copper foil. The copper foil is etched into such shapes
that when you solder components to it they are connected in just the right way.
There may be multiple layers of copper foil (up to more than 10) in more complex
designs. Two different layers of copper may be connected with a “via”, a small
hole whose inside surface is plated with metal. These vias may go all the way
from the top to the bottom of the board or just through a few layers in the
middle (the latter is more expensive but common in complicated designs). Similar
to vias, there are larger holes through which the leads of components may be
stuck for soldering.

The outline of the PCB may be irregular, and the board may have slots, holes and
even grooves.

Beyond the top- and bottommost copper layers, there are some special layers. On
each side there is a “solder mask” which is a varnish that protects any surface
that is not meant to be soldered on from dirt and oxidation (this makes the PCB
green or blue or red), and a “silk screen” layer which is a usually white paint
used to place human-readable markings with part numbers, ids, values, outlines
as well as comments, copyright notices etc. on the surface on the board.

A very important feature of PCB layout programs is called “DRC” (design rule
checking). The most important of several possible design rule checks is that on
the PCB layout traces do no touch and there always is some clearance between
them.

==Missing features==
===Hard===
* Extension of the Symbols code to an abstraction usable for components
** Auto reference generation (“C1”, “R17” etc.)
* Connectivity test/netlist generation/net names
* Trace routing tool with 45° outing
** This absolutely is a task for the graph connector tool
* Schematic ↔ PCB mapping (components added in the schematic are also added on the PCB, components (packages) on the PCB may be exchanged for other, compatible packages)
** To ease this, schematic and PCB layout could be placed on different layers of a single SVG file

===Not so hard===
* Gnd/other plane fills
** I think there already is a live path effect for that
* Clearance calculation/DRC
** This naturally is part of the netlist generation
* PCB layers
** Can be implemented by SVG classes. When SVG 2.0 comes around, these can be assigned z-order attributes.
** Most other parts of Inkscape do not need to be aware of these classes, they only need special treatment when exporting to PCB formats.
** PCB layer classes are assigned when creating a component. Some kind of GUI would be nice for this.
* File format support
** old Eagle format
** new (XML-based) Eagle format
** Gerber
** gEDA
** KiCad
* Page frame templates → The actual frame can be realized as a drawing on a locked layer
** Auto-insertion of document properties into text fields → This looks like some pretty straight-forward placeholder replacement to me
*** ...and part numbers/values
* non-rectangular page outlines? → Probably, Inkscape's ''page'' abstraction will not even be used for the board outline (but instead a layer containing a polygon will be)
* distance measurement tool‒ ''This is very useful even outside of electronics''
* object highlighting → Some limited version of this already exists in form of these quickly disappearing red path visualizations
** Should appear on mouse hovering (perhaps with mod key)
** Should highlight the ''whole'' object, not just paths/fills/etc.
** Perhaps render the object transparent with increased brightness on top of everything else?
* transparent/desaturated “see-though” rendering of inactive layers

==Connectivity testing/netlist generation==
===Algorithm overview===
* Select starting point
** Start with elements in descending net name priority: first human-set names, second everything derived from default pin names, third just make up names
* Find overlapping or touching elements
** Does not seem too complicated. Since the heavy lifting is done by 2geom this could be implemented in python.
** Propagate net names (via labelling new parts)‒this is basically flood fill

===Net names===
* All pins/traces/planes ought to have net names
** Net names have a “priority” (an integer): 0 for auto-generated names, 100 for names derived frmo default pin names and 200 for manually-set names
* After propagating existing names, start assigning generated names to unnamed elements and propagate these

===Starting points for the algorithm===
* Pins/pads, traces, planes
** Generate names for pins by using the default net name of the pin (“CLK”). Check whether the name already exists in the document and if yes, append a number to the default net name (“CLK2”). Repeat until an unique name has been found.
* Find those by just iterating through the object tree → even pins should be found there despite them being part of a component

===Dynamic updating===
* Dynamic updating should be the normal case. When something is removed, the connectivity of its former net has to be re-checked.
** If there is a netsplit, drop the old net name, then search the two net parts for two starting points for the aforementioned algorithm. If none are found, just use ''any'' element.
** If there is an addition to an existing net (and thus a name collision), do the obvious: Use the name with the higher priority

==Component abstraction==
===Component features===
# Like groups, components group objects together
# Components have some metadata/parameters associated with them
# The parts of a component may be on different PCB layers (i.e. be assigned different PCB layer classes)
# Components can have ''terminals'' or ''pins'' (for trace routing and netlist generation). This nicely maps to the ''point'' elements described in the SVG Connector draft

===Required code===
* Python interface for parametric component generation

==See also==
[https://bitbucket.org/boldport/pcbmode PCBmodE]

The [https://google-melange.appspot.com/gsoc/proposal/review/google/gsoc2013/jaseg/1 GSoC Proposal]

The [http://dev.w3.org/SVG/modules/connector/SVGConnector.html SVG Connector draft]

SpecElectronicsCAD

2013-05-21T19:51:41Z

SebastianGoette: /* Component abstraction */

=Electronics CAD with Inkscape‒Missing functionality=

Currently there is no ''nice'' open source electronics CAD tool. The largest
competitors are gEDA which I find awkward to use and KiCad which I find even
more awkward to use. Since a schematics editor is not much more than a
special-purpose flow graph editor and a PCB layout editor is in fact nothing
but a somewhat crippled vector graphics editor with some special-purpose
features added I think it is very promising to modify a general purpose vector
graphics editor to support the few special-purpose functions additionally
required by an electronics CAD tool.

==Scenario==
The electronics CAD process mainly consists of two parts: Drawing the schematic
and PCB (Printed Circuit Board) layout. Normally, you will first draw a
schematic and base your PCB layout off that. However, from then on you will
frequently change the schematic and layout and want to have your chages in the
one represented in the other.

A schematic is basically just a flow chart. The basic features are components
(symbols) taken from a library that are put on a grid (because you do not want
to mess around with a lot of manual aligning) and that are connected with wires
(represented by lines). Wires are always either vertical or horizontal and have
names for the signal the wire is carrying. Components have a list of attributes
(an unique id, value/voltage, part number, supplier etc.), some of which are
rendered on the schematic next to the component (normally these are id and value
or part number). Finally, you want some function to place text anywhere for
comments.

A PCB design in comparision is a little more complex. A printed circuit board is
a stack of plastic and copper foil. The copper foil is etched into such shapes
that when you solder components to it they are connected in just the right way.
There may be multiple layers of copper foil (up to more than 10) in more complex
designs. Two different layers of copper may be connected with a “via”, a small
hole whose inside surface is plated with metal. These vias may go all the way
from the top to the bottom of the board or just through a few layers in the
middle (the latter is more expensive but common in complicated designs). Similar
to vias, there are larger holes through which the leads of components may be
stuck for soldering.

The outline of the PCB may be irregular, and the board may have slots, holes and
even grooves.

Beyond the top- and bottommost copper layers, there are some special layers. On
each side there is a “solder mask” which is a varnish that protects any surface
that is not meant to be soldered on from dirt and oxidation (this makes the PCB
green or blue or red), and a “silk screen” layer which is a usually white paint
used to place human-readable markings with part numbers, ids, values, outlines
as well as comments, copyright notices etc. on the surface on the board.

A very important feature of PCB layout programs is called “DRC” (design rule
checking). The most important of several possible design rule checks is that on
the PCB layout traces do no touch and there always is some clearance between
them.

==Missing features==
===Hard===
* Extension of the Symbols code to an abstraction usable for components
** Auto reference generation (“C1”, “R17” etc.)
* Connectivity test/netlist generation/net names
* Trace routing tool with 45° outing → This absolutely is a task for the graph connector tool
* Schematic ↔ PCB mapping (components added in the schematic are also added on the PCB, components (packages) on the PCB may be exchanged for other, compatible packages)

===Not so hard===
* Gnd/other plane fills → I think there already is a live path effect for that
* Clearance calculation/DRC
* PCB layers → Will map nicely to regular inkscape layers
* File format support
** old Eagle format
** new (XML-based) Eagle format
** Gerber
** gEDA
** KiCad
* Page frame templates → The actual frame can be realized as a drawing on a locked layer
** Auto-insertion of document properties into text fields → This looks like some pretty straight-forward placeholder replacement to me
*** ...and part numbers/values
* non-rectangular page outlines? → Probably, Inkscape's ''page'' abstraction will not even be used for the board outline (but instead a layer containing a polygon will be)
* distance measurement tool‒ ''This is very useful even outside of electronics''
* object highlighting → Some limited version of this already exists in form of these quickly disappearing red path visualizations
** Should appear on mouse hovering (perhaps with mod key)
** Should highlight the ''whole'' object, not just paths/fills/etc.
** Perhaps render the object transparent with increased brightness on top of everything else?
* transparent/desaturated “see-though” rendering of inactive layers

==Connectivity testing/netlist generation==
===Algorithm overview===
* Select starting point
** Start with elements in descending net name priority: first human-set names, second everything derived from default pin names, third just make up names
* Find overlapping or touching elements
** Is there some existing functionality that can be (ab)used for that?
* Propagate net (via labelling new parts)‒this is basically flood fill

===Net names===
* All pins/traces/planes ought to have net names
** Net names have a “priority” (an integer): 0 for auto-generated names, 100 for names derived frmo default pin names and 200 for manually-set names
* After propagating existing names, start assigning generated names to unnamed elements and propagate these

===Starting points for the algorithm===
* Pins/pads, traces, planes
** Generate names for pins by using the default net name of the pin (“CLK”). Check whether the name already exists in the document and if yes, append a number to the default net name (“CLK2”). Repeat until an unique name has been found.
* Find those by just iterating through the object tree → even pins should be found there despite them being part of a component

===Dynamic updating===
* Dynamic updating should be the normal case. When something is removed, the connectivity of its former net has to be re-checked.
** If there is a netsplit, drop the old net name, then search the two net parts for two starting points for the aforementioned algorithm. If none are found, just use ''any'' element.
** If there is an addition to an existing net (and thus a name collision), do the obvious: Use the name with the higher priority

==Component abstraction==
===Component features===
# Like groups, components group objects together
# Components have some metadata/parameters associated with them
# The parts of a component may be on different PCB layers (i.e. be assigned different PCB layer classes)
# Components can have ''terminals'' or ''pins'' (for trace routing and netlist generation). Pins may have some metadata like direction and default net name

===Required code===
* Python interface for parametric component generation
* Component ''templates'' to be placed in a library‒I plan on two options: an SVG file (which is just pasted into the document) or python scripts outputting SVG (for parametrizeable generators) → There already is a blueprint of that exact technology (but applied on a whole-document basis as document templates)
* An actual “component” object that can span multiple layers

==See also==
[https://bitbucket.org/boldport/pcbmode PCBmodE]

The [https://google-melange.appspot.com/gsoc/proposal/review/google/gsoc2013/jaseg/1 GSoC Proposal]

The [http://dev.w3.org/SVG/modules/connector/SVGConnector.html SVG Connector draft]

SpecElectronicsCAD

2013-05-21T19:44:34Z

SebastianGoette: /* Hard */

=Electronics CAD with Inkscape‒Missing functionality=

Currently there is no ''nice'' open source electronics CAD tool. The largest
competitors are gEDA which I find awkward to use and KiCad which I find even
more awkward to use. Since a schematics editor is not much more than a
special-purpose flow graph editor and a PCB layout editor is in fact nothing
but a somewhat crippled vector graphics editor with some special-purpose
features added I think it is very promising to modify a general purpose vector
graphics editor to support the few special-purpose functions additionally
required by an electronics CAD tool.

==Scenario==
The electronics CAD process mainly consists of two parts: Drawing the schematic
and PCB (Printed Circuit Board) layout. Normally, you will first draw a
schematic and base your PCB layout off that. However, from then on you will
frequently change the schematic and layout and want to have your chages in the
one represented in the other.

A schematic is basically just a flow chart. The basic features are components
(symbols) taken from a library that are put on a grid (because you do not want
to mess around with a lot of manual aligning) and that are connected with wires
(represented by lines). Wires are always either vertical or horizontal and have
names for the signal the wire is carrying. Components have a list of attributes
(an unique id, value/voltage, part number, supplier etc.), some of which are
rendered on the schematic next to the component (normally these are id and value
or part number). Finally, you want some function to place text anywhere for
comments.

A PCB design in comparision is a little more complex. A printed circuit board is
a stack of plastic and copper foil. The copper foil is etched into such shapes
that when you solder components to it they are connected in just the right way.
There may be multiple layers of copper foil (up to more than 10) in more complex
designs. Two different layers of copper may be connected with a “via”, a small
hole whose inside surface is plated with metal. These vias may go all the way
from the top to the bottom of the board or just through a few layers in the
middle (the latter is more expensive but common in complicated designs). Similar
to vias, there are larger holes through which the leads of components may be
stuck for soldering.

The outline of the PCB may be irregular, and the board may have slots, holes and
even grooves.

Beyond the top- and bottommost copper layers, there are some special layers. On
each side there is a “solder mask” which is a varnish that protects any surface
that is not meant to be soldered on from dirt and oxidation (this makes the PCB
green or blue or red), and a “silk screen” layer which is a usually white paint
used to place human-readable markings with part numbers, ids, values, outlines
as well as comments, copyright notices etc. on the surface on the board.

A very important feature of PCB layout programs is called “DRC” (design rule
checking). The most important of several possible design rule checks is that on
the PCB layout traces do no touch and there always is some clearance between
them.

==Missing features==
===Hard===
* Extension of the Symbols code to an abstraction usable for components
** Auto reference generation (“C1”, “R17” etc.)
* Connectivity test/netlist generation/net names
* Trace routing tool with 45° outing → This absolutely is a task for the graph connector tool
* Schematic ↔ PCB mapping (components added in the schematic are also added on the PCB, components (packages) on the PCB may be exchanged for other, compatible packages)

===Not so hard===
* Gnd/other plane fills → I think there already is a live path effect for that
* Clearance calculation/DRC
* PCB layers → Will map nicely to regular inkscape layers
* File format support
** old Eagle format
** new (XML-based) Eagle format
** Gerber
** gEDA
** KiCad
* Page frame templates → The actual frame can be realized as a drawing on a locked layer
** Auto-insertion of document properties into text fields → This looks like some pretty straight-forward placeholder replacement to me
*** ...and part numbers/values
* non-rectangular page outlines? → Probably, Inkscape's ''page'' abstraction will not even be used for the board outline (but instead a layer containing a polygon will be)
* distance measurement tool‒ ''This is very useful even outside of electronics''
* object highlighting → Some limited version of this already exists in form of these quickly disappearing red path visualizations
** Should appear on mouse hovering (perhaps with mod key)
** Should highlight the ''whole'' object, not just paths/fills/etc.
** Perhaps render the object transparent with increased brightness on top of everything else?
* transparent/desaturated “see-though” rendering of inactive layers

==Connectivity testing/netlist generation==
===Algorithm overview===
* Select starting point
** Start with elements in descending net name priority: first human-set names, second everything derived from default pin names, third just make up names
* Find overlapping or touching elements
** Is there some existing functionality that can be (ab)used for that?
* Propagate net (via labelling new parts)‒this is basically flood fill

===Net names===
* All pins/traces/planes ought to have net names
** Net names have a “priority” (an integer): 0 for auto-generated names, 100 for names derived frmo default pin names and 200 for manually-set names
* After propagating existing names, start assigning generated names to unnamed elements and propagate these

===Starting points for the algorithm===
* Pins/pads, traces, planes
** Generate names for pins by using the default net name of the pin (“CLK”). Check whether the name already exists in the document and if yes, append a number to the default net name (“CLK2”). Repeat until an unique name has been found.
* Find those by just iterating through the object tree → even pins should be found there despite them being part of a component

===Dynamic updating===
* Dynamic updating should be the normal case. When something is removed, the connectivity of its former net has to be re-checked.
** If there is a netsplit, drop the old net name, then search the two net parts for two starting points for the aforementioned algorithm. If none are found, just use ''any'' element.
** If there is an addition to an existing net (and thus a name collision), do the obvious: Use the name with the higher priority

==Component abstraction==
===Component features===
# Components may be references to a ''library'' or be physically embedded into the document
# Like groups, components group objects together‒but they may do this cross-layer
# Components have some metadata/parameters associated with them
# Components can have ''terminals'' or ''pins'' (these are important for trace routing and netlist generation). Pins may have some metadata like direction and default net name

===Required code===
* Component library‒(easiest version: folder of SVGs, or a folder of folders of SVGs for easier organization)
* Component ''templates'' to be placed in a library‒I plan on two options: an SVG file (which is just pasted into the document) or python scripts outputting SVG (for parametrizeable generators) → There already is a blueprint of that exact technology (but applied on a whole-document basis as document templates)
* An actual “component” object that can span multiple layers

==See also==
[https://bitbucket.org/boldport/pcbmode PCBmodE]

The [https://google-melange.appspot.com/gsoc/proposal/review/google/gsoc2013/jaseg/1 GSoC Proposal]

The [http://dev.w3.org/SVG/modules/connector/SVGConnector.html SVG Connector draft]

SpecElectronicsCAD

2013-05-09T15:09:07Z

SebastianGoette:

=Electronics CAD with Inkscape‒Missing functionality=

Currently there is no ''nice'' open source electronics CAD tool. The largest
competitors are gEDA which I find awkward to use and KiCad which I find even
more awkward to use. Since a schematics editor is not much more than a
special-purpose flow graph editor and a PCB layout editor is in fact nothing
but a somewhat crippled vector graphics editor with some special-purpose
features added I think it is very promising to modify a general purpose vector
graphics editor to support the few special-purpose functions additionally
required by an electronics CAD tool.

==Scenario==
The electronics CAD process mainly consists of two parts: Drawing the schematic
and PCB (Printed Circuit Board) layout. Normally, you will first draw a
schematic and base your PCB layout off that. However, from then on you will
frequently change the schematic and layout and want to have your chages in the
one represented in the other.

A schematic is basically just a flow chart. The basic features are components
(symbols) taken from a library that are put on a grid (because you do not want
to mess around with a lot of manual aligning) and that are connected with wires
(represented by lines). Wires are always either vertical or horizontal and have
names for the signal the wire is carrying. Components have a list of attributes
(an unique id, value/voltage, part number, supplier etc.), some of which are
rendered on the schematic next to the component (normally these are id and value
or part number). Finally, you want some function to place text anywhere for
comments.

A PCB design in comparision is a little more complex. A printed circuit board is
a stack of plastic and copper foil. The copper foil is etched into such shapes
that when you solder components to it they are connected in just the right way.
There may be multiple layers of copper foil (up to more than 10) in more complex
designs. Two different layers of copper may be connected with a “via”, a small
hole whose inside surface is plated with metal. These vias may go all the way
from the top to the bottom of the board or just through a few layers in the
middle (the latter is more expensive but common in complicated designs). Similar
to vias, there are larger holes through which the leads of components may be
stuck for soldering.

The outline of the PCB may be irregular, and the board may have slots, holes and
even grooves.

Beyond the top- and bottommost copper layers, there are some special layers. On
each side there is a “solder mask” which is a varnish that protects any surface
that is not meant to be soldered on from dirt and oxidation (this makes the PCB
green or blue or red), and a “silk screen” layer which is a usually white paint
used to place human-readable markings with part numbers, ids, values, outlines
as well as comments, copyright notices etc. on the surface on the board.

A very important feature of PCB layout programs is called “DRC” (design rule
checking). The most important of several possible design rule checks is that on
the PCB layout traces do no touch and there always is some clearance between
them.

==Missing features==
===Hard===
* Component abstraction
** Auto reference generation (“C1”, “R17” etc.)
* Connectivity test/netlist generation/net names
* Trace routing tool with 45° outing → This absolutely is a task for the graph connector tool
* Schematic ↔ PCB mapping (components added in the schematic are also added on the PCB, components (packages) on the PCB may be exchanged for other, compatible packages)

===Not so hard===
* Gnd/other plane fills → I think there already is a live path effect for that
* Clearance calculation/DRC
* PCB layers → Will map nicely to regular inkscape layers
* File format support
** old Eagle format
** new (XML-based) Eagle format
** Gerber
** gEDA
** KiCad
* Page frame templates → The actual frame can be realized as a drawing on a locked layer
** Auto-insertion of document properties into text fields → This looks like some pretty straight-forward placeholder replacement to me
*** ...and part numbers/values
* non-rectangular page outlines? → Probably, Inkscape's ''page'' abstraction will not even be used for the board outline (but instead a layer containing a polygon will be)
* distance measurement tool‒ ''This is very useful even outside of electronics''
* object highlighting → Some limited version of this already exists in form of these quickly disappearing red path visualizations
** Should appear on mouse hovering (perhaps with mod key)
** Should highlight the ''whole'' object, not just paths/fills/etc.
** Perhaps render the object transparent with increased brightness on top of everything else?
* transparent/desaturated “see-though” rendering of inactive layers

==Connectivity testing/netlist generation==
===Algorithm overview===
* Select starting point
** Start with elements in descending net name priority: first human-set names, second everything derived from default pin names, third just make up names
* Find overlapping or touching elements
** Is there some existing functionality that can be (ab)used for that?
* Propagate net (via labelling new parts)‒this is basically flood fill

===Net names===
* All pins/traces/planes ought to have net names
** Net names have a “priority” (an integer): 0 for auto-generated names, 100 for names derived frmo default pin names and 200 for manually-set names
* After propagating existing names, start assigning generated names to unnamed elements and propagate these

===Starting points for the algorithm===
* Pins/pads, traces, planes
** Generate names for pins by using the default net name of the pin (“CLK”). Check whether the name already exists in the document and if yes, append a number to the default net name (“CLK2”). Repeat until an unique name has been found.
* Find those by just iterating through the object tree → even pins should be found there despite them being part of a component

===Dynamic updating===
* Dynamic updating should be the normal case. When something is removed, the connectivity of its former net has to be re-checked.
** If there is a netsplit, drop the old net name, then search the two net parts for two starting points for the aforementioned algorithm. If none are found, just use ''any'' element.
** If there is an addition to an existing net (and thus a name collision), do the obvious: Use the name with the higher priority

==Component abstraction==
===Component features===
# Components may be references to a ''library'' or be physically embedded into the document
# Like groups, components group objects together‒but they may do this cross-layer
# Components have some metadata/parameters associated with them
# Components can have ''terminals'' or ''pins'' (these are important for trace routing and netlist generation). Pins may have some metadata like direction and default net name

===Required code===
* Component library‒(easiest version: folder of SVGs, or a folder of folders of SVGs for easier organization)
* Component ''templates'' to be placed in a library‒I plan on two options: an SVG file (which is just pasted into the document) or python scripts outputting SVG (for parametrizeable generators) → There already is a blueprint of that exact technology (but applied on a whole-document basis as document templates)
* An actual “component” object that can span multiple layers

==See also==
[https://bitbucket.org/boldport/pcbmode PCBmodE]

The [https://google-melange.appspot.com/gsoc/proposal/review/google/gsoc2013/jaseg/1 GSoC Proposal]

The [http://dev.w3.org/SVG/modules/connector/SVGConnector.html SVG Connector draft]

SpecElectronicsCAD

2013-05-09T15:08:31Z

SebastianGoette:

=Electronics CAD with Inkscape‒Missing functionality=

Currently there is no ''nice'' open source electronics CAD tool. The largest
competitors are gEDA which I find awkward to use and KiCad which I find even
more awkward to use. Since a schematics editor is not much more than a
special-purpose flow graph editor and a PCB layout editor is in fact nothing
but a somewhat crippled vector graphics editor with some special-purpose
features added I think it is very promising to modify a general purpose vector
graphics editor to support the few special-purpose functions additionally
required by an electronics CAD tool.

==Scenario==
The electronics CAD process mainly consists of two parts: Drawing the schematic
and PCB (Printed Circuit Board) layout. Normally, you will first draw a
schematic and base your PCB layout off that. However, from then on you will
frequently change the schematic and layout and want to have your chages in the
one represented in the other.

A schematic is basically just a flow chart. The basic features are components
(symbols) taken from a library that are put on a grid (because you do not want
to mess around with a lot of manual aligning) and that are connected with wires
(represented by lines). Wires are always either vertical or horizontal and have
names for the signal the wire is carrying. Components have a list of attributes
(an unique id, value/voltage, part number, supplier etc.), some of which are
rendered on the schematic next to the component (normally these are id and value
or part number). Finally, you want some function to place text anywhere for
comments.

A PCB design in comparision is a little more complex. A printed circuit board is
a stack of plastic and copper foil. The copper foil is etched into such shapes
that when you solder components to it they are connected in just the right way.
There may be multiple layers of copper foil (up to more than 10) in more complex
designs. Two different layers of copper may be connected with a “via”, a small
hole whose inside surface is plated with metal. These vias may go all the way
from the top to the bottom of the board or just through a few layers in the
middle (the latter is more expensive but common in complicated designs). Similar
to vias, there are larger holes through which the leads of components may be
stuck for soldering.

The outline of the PCB may be irregular, and the board may have slots, holes and
even grooves.

Beyond the top- and bottommost copper layers, there are some special layers. On
each side there is a “solder mask” which is a varnish that protects any surface
that is not meant to be soldered on from dirt and oxidation (this makes the PCB
green or blue or red), and a “silk screen” layer which is a usually white paint
used to place human-readable markings with part numbers, ids, values, outlines
as well as comments, copyright notices etc. on the surface on the board.

A very important feature of PCB layout programs is called “DRC” (design rule
checking). The most important of several possible design rule checks is that on
the PCB layout traces do no touch and there always is some clearance between
them.

==Missing features==
===Hard===
* Component abstraction
** Auto reference generation (“C1”, “R17” etc.)
* Connectivity test/netlist generation/net names
* Trace routing tool with 45° outing → This absolutely is a task for the graph connector tool
* Schematic ↔ PCB mapping (components added in the schematic are also added on the PCB, components (packages) on the PCB may be exchanged for other, compatible packages)

===Not so hard===
* Gnd/other plane fills → I think there already is a live path effect for that
* Clearance calculation/DRC
* PCB layers → Will map nicely to regular inkscape layers
* File format support
** old Eagle format
** new (XML-based) Eagle format
** Gerber
** gEDA
** KiCad
* Page frame templates → The actual frame can be realized as a drawing on a locked layer
** Auto-insertion of document properties into text fields → This looks like some pretty straight-forward placeholder replacement to me
*** ...and part numbers/values
* non-rectangular page outlines? → Probably, Inkscape's ''page'' abstraction will not even be used for the board outline (but instead a layer containing a polygon will be)
* distance measurement tool‒ ''This is very useful even outside of electronics''
* object highlighting → Some limited version of this already exists in form of these quickly disappearing red path visualizations
** Should appear on mouse hovering (perhaps with mod key)
** Should highlight the ''whole'' object, not just paths/fills/etc.
** Perhaps render the object transparent with increased brightness on top of everything else?
* transparent/desaturated “see-though” rendering of inactive layers

==Connectivity testing/netlist generation==
===Algorithm overview===
* Select starting point
** Start with elements in descending net name priority: first human-set names, second everything derived from default pin names, third just make up names
* Find overlapping or touching elements
** Is there some existing functionality that can be (ab)used for that?
* Propagate net (via labelling new parts)‒this is basically flood fill

===Net names===
* All pins/traces/planes ought to have net names
** Net names have a “priority” (an integer): 0 for auto-generated names, 100 for names derived frmo default pin names and 200 for manually-set names
* After propagating existing names, start assigning generated names to unnamed elements and propagate these

===Starting points for the algorithm===
* Pins/pads, traces, planes
** Generate names for pins by using the default net name of the pin (“CLK”). Check whether the name already exists in the document and if yes, append a number to the default net name (“CLK2”). Repeat until an unique name has been found.
* Find those by just iterating through the object tree → even pins should be found there despite them being part of a component

===Dynamic updating===
* Dynamic updating should be the normal case. When something is removed, the connectivity of its former net has to be re-checked.
** If there is a netsplit, drop the old net name, then search the two net parts for two starting points for the aforementioned algorithm. If none are found, just use ''any'' element.
** If there is an addition to an existing net (and thus a name collision), do the obvious: Use the name with the higher priority

==Component abstraction==
===Component features===
# Components may be references to a ''library'' or be physically embedded into the document
# Like groups, components group objects together‒but they may do this cross-layer
# Components have some metadata/parameters associated with them
# Components can have ''terminals'' or ''pins'' (these are important for trace routing and netlist generation). Pins may have some metadata like direction and default net name

===Required code===
* Component library‒(easiest version: folder of SVGs, or a folder of folders of SVGs for easier organization)
* Component ''templates'' to be placed in a library‒I plan on two options: an SVG file (which is just pasted into the document) or python scripts outputting SVG (for parametrizeable generators) → There already is a blueprint of that exact technology (but applied on a whole-document basis as document templates)
* An actual “component” object that can span multiple layers

==See also==
[https://bitbucket.org/boldport/pcbmode PCBmodE]

The [https://google-melange.appspot.com/gsoc/proposal/review/google/gsoc2013/jaseg/1 GSoC Proposal]

SpecElectronicsCAD

2013-04-30T14:38:51Z

SebastianGoette: Created page with "=Electronics CAD with Inkscape‒Missing functionality= Currently there is no ''nice'' open source electronics CAD tool. The largest competitors are gEDA which I find awkward..."

=Electronics CAD with Inkscape‒Missing functionality=

Currently there is no ''nice'' open source electronics CAD tool. The largest
competitors are gEDA which I find awkward to use and KiCad which I find even
more awkward to use. Since a schematics editor is not much more than a
special-purpose flow graph editor and a PCB layout editor is in fact nothing
but a somewhat crippled vector graphics editor with some special-purpose
features added I think it is very promising to modify a general purpose vector
graphics editor to support the few special-purpose functions additionally
required by an electronics CAD tool.

==Scenario==
The electronics CAD process mainly consists of two parts: Drawing the schematic
and PCB (Printed Circuit Board) layout. Normally, you will first draw a
schematic and base your PCB layout off that. However, from then on you will
frequently change the schematic and layout and want to have your chages in the
one represented in the other.

A schematic is basically just a flow chart. The basic features are components
(symbols) taken from a library that are put on a grid (because you do not want
to mess around with a lot of manual aligning) and that are connected with wires
(represented by lines). Wires are always either vertical or horizontal and have
names for the signal the wire is carrying. Components have a list of attributes
(an unique id, value/voltage, part number, supplier etc.), some of which are
rendered on the schematic next to the component (normally these are id and value
or part number). Finally, you want some function to place text anywhere for
comments.

A PCB design in comparision is a little more complex. A printed circuit board is
a stack of plastic and copper foil. The copper foil is etched into such shapes
that when you solder components to it they are connected in just the right way.
There may be multiple layers of copper foil (up to more than 10) in more complex
designs. Two different layers of copper may be connected with a “via”, a small
hole whose inside surface is plated with metal. These vias may go all the way
from the top to the bottom of the board or just through a few layers in the
middle (the latter is more expensive but common in complicated designs). Similar
to vias, there are larger holes through which the leads of components may be
stuck for soldering.

The outline of the PCB may be irregular, and the board may have slots, holes and
even grooves.

Beyond the top- and bottommost copper layers, there are some special layers. On
each side there is a “solder mask” which is a varnish that protects any surface
that is not meant to be soldered on from dirt and oxidation (this makes the PCB
green or blue or red), and a “silk screen” layer which is a usually white paint
used to place human-readable markings with part numbers, ids, values, outlines
as well as comments, copyright notices etc. on the surface on the board.

A very important feature of PCB layout programs is called “DRC” (design rule
checking). The most important of several possible design rule checks is that on
the PCB layout traces do no touch and there always is some clearance between
them.

==Missing features==
===Hard===
* Component abstraction
** Auto reference generation (“C1”, “R17” etc.)
* Connectivity test/netlist generation/net names
* Trace routing tool with 45° outing → This absolutely is a task for the graph connector tool
* Schematic ↔ PCB mapping (components added in the schematic are also added on the PCB, components (packages) on the PCB may be exchanged for other, compatible packages)

===Not so hard===
* Gnd/other plane fills → I think there already is a live path effect for that
* Clearance calculation/DRC
* PCB layers → Will map nicely to regular inkscape layers
* File format support
** old Eagle format
** new (XML-based) Eagle format
** Gerber
** gEDA
** KiCad
* Page frame templates → The actual frame can be realized as a drawing on a locked layer
** Auto-insertion of document properties into text fields → This looks like some pretty straight-forward placeholder replacement to me
*** ...and part numbers/values
* non-rectangular page outlines? → Probably, Inkscape's ''page'' abstraction will not even be used for the board outline (but instead a layer containing a polygon will be)
* distance measurement tool‒ ''This is very useful even outside of electronics''
* object highlighting → Some limited version of this already exists in form of these quickly disappearing red path visualizations
** Should appear on mouse hovering (perhaps with mod key)
** Should highlight the ''whole'' object, not just paths/fills/etc.
** Perhaps render the object transparent with increased brightness on top of everything else?
* transparent/desaturated “see-though” rendering of inactive layers

==Connectivity testing/netlist generation==
===Algorithm overview===
* Select starting point
** Start with elements in descending net name priority: first human-set names, second everything derived from default pin names, third just make up names
* Find overlapping or touching elements
** Is there some existing functionality that can be (ab)used for that?
* Propagate net (via labelling new parts)‒this is basically flood fill

===Net names===
* All pins/traces/planes ought to have net names
** Net names have a “priority” (an integer): 0 for auto-generated names, 100 for names derived frmo default pin names and 200 for manually-set names
* After propagating existing names, start assigning generated names to unnamed elements and propagate these

===Starting points for the algorithm===
* Pins/pads, traces, planes
** Generate names for pins by using the default net name of the pin (“CLK”). Check whether the name already exists in the document and if yes, append a number to the default net name (“CLK2”). Repeat until an unique name has been found.
* Find those by just iterating through the object tree → even pins should be found there despite them being part of a component

===Dynamic updating===
* Dynamic updating should be the normal case. When something is removed, the connectivity of its former net has to be re-checked.
** If there is a netsplit, drop the old net name, then search the two net parts for two starting points for the aforementioned algorithm. If none are found, just use ''any'' element.
** If there is an addition to an existing net (and thus a name collision), do the obvious: Use the name with the higher priority

==Component abstraction==
===Component features===
# Components may be references to a ''library'' or be physically embedded into the document
# Like groups, components group objects together‒but they may do this cross-layer
# Components have some metadata/parameters associated with them
# Components can have ''terminals'' or ''pins'' (these are important for trace routing and netlist generation). Pins may have some metadata like direction and default net name

===Required code===
* Component library‒(easiest version: folder of SVGs, or a folder of folders of SVGs for easier organization)
* Component ''templates'' to be placed in a library‒I plan on two options: an SVG file (which is just pasted into the document) or python scripts outputting SVG (for parametrizeable generators) → There already is a blueprint of that exact technology (but applied on a whole-document basis as document templates)
* An actual “component” object that can span multiple layers