kicad-developers team mailing list archive

[Wayne Stambaugh <stambaughw@xxxxxxxxx>]

Daniel,

Sorry it took me so long to get back to you.  I finally had a chance to
test your intra-sheet code.  While it does appear to work as advertised,
I'm not sure this is the best way to handle the intra-sheet connections.
 Since it doesn't address the inter-sheet connections, it may confuse
users as much as it helps them.  My preference would be to use the
current dangling end testing to include testing the full net list to set
the connection state indicators (the little squares at the end of
unconnected objects) of both intra and inter-sheet connections.  The
only thing I'm not sure of using this method is whether or not
rebuilding the net list on demand will cause UI lag while the net list
connection checks are being performed.  I'm not completely ruling out
your idea, but I would like to see a solution that addresses both intra
and inter-sheet connections.  I'm not sure the extra connection objects
are necessary.  It's extra work for the designer to use them and from my
experience is not something most schematic designers would be familiar
with.  I'm not aware of any other schematic capture program that uses
this paradigm.

Cheers,

Wayne

On 2/13/2016 10:44 AM, Daniel Silverstone wrote:
> Hi,
> 
> I accept that this is somewhat out of the blue, and if a more established
> eeschema person wants to smack me down and tell me that my idea is crazypants
> then I'll accept a ruling in that manner, but...
> 
> I used to be involved in electronics at a firm which used Mentor's DesignView
> flow.  Mentor had an intra-sheet link symbol which was used to indicate when a
> net stopped at one point on a sheet and reappeared somewhere else on it.  This
> tends to be done in Eagle, KiCad etc, by means of wire segments which dangle
> around.
> 
> Having done at least one design where dangling segments ended up actually being
> something which cocked up my board I was thinking about ways to improve
> matters.  I started off by writing some ERC checks which pointed out segments
> with dangling starts or ends.  I then extended that to include junctions which
> seemed pointless (had an insufficiency of segments at them to warrant the
> junction).
> 
> Of course, at that point, perfectly legitimate dangling segments would cause
> ERC warnings which isn't exactly ideal.  I considered simply using a one-pin
> symbol to act as an intra-sheet link symbol, but since I really wanted some
> specific ERC warnings around intra-sheet links being mis-used, I figured I'd
> have a go at writing a proper NETLIST_OBJECT integrateable thing with a proper
> SCH_ITEM associated with it, etc.
> 
> The result of my hacking (and honestly, given this is the first time I am
> poking around in KiCad's codebase, it is pretty hacky) can be found at:
> 
>     https://github.com/kinnison/kicad-source-mirror
> 
> on the intralinks branch.  I appreciate this is not the accepted manner for
> submitting code for inclusion into KiCad, so please don't shout at me for that.
> At this point I'm simply looking for comments and suggestions.  There's bound
> to be at least some things I need to clean up before it'd be suitable for
> inclusion, so hints and tips would be gratefully received.
> 
> Once I've made any fixes recommended to me, and assuming noone tells me I
> really shouldn't be submitting this for inclusion, I'll sort out a bzr bundle
> or whatever is most desirable for the maintainers.
> 
> Thanks for reading this far, and if you want to give my branch a go, I'd really
> appreciate feedback; just be aware it does bump the eeschema version number
> since it adds a new kind of thing stored to the .sch files; though it'd be a
> trivial job to go in and remove the relevant lines and drop the version back
> if you did accidentally edit a real project with it.
> 
> D.
>