[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]
Re: gEDA-user: Random thoughts on the future interface of PCB
Was it just me that got a copy with no paragraph
breaks? Looking at the ascii art I assume it was
sent with line breaks somewhere.
Rick
At 03:02 PM 12/2/2010, you wrote:
Hi guys, Just thought I'd write some of this
down and put it out there. I've spent some time
recently thinking way into the future about the
GUI / usability for an advanced PCB editing
program. I started along the lines of... how
would PCB design work if my input device was a
graphics tablet (something akin to the Wacom
Cintiq would be awesome). PCB design is a real
hybrid of art, precision engineering and black
magic. For laying tracks, some gestural actions,
fluid drawing and possibly even multi-touch
interfaces might provide user interface
opportunities never before seen in this kind of
CAD application. Some randomly sorted ideas:
Scrap straight line rats in favour of using the
topological auto-router? This is not quite the
same as auto-routing a single net. Each
rat would only avoid existing laid down
geometry, and would be allowed to cross other
rat lines. Also, I'd imagine flattening any
route generated to be in the rats plane. (The
rat would not jump between layers as an
auto-routed trace might, even if the route taken
could only be made effectively through
multiple layers). Obviously this is nice, as
the user can pick rat-lines which have routed
well and request PCB turns the rats into solid
tracking. Manually placed, rubber-banded
topological tracking? How about guiding a
track routing by drawing the topology you
desire, weaving in and out of other
components? The topology between obstacles
could easily be extracted from a hand-stroked
line drawn with a pen, mouse, or perhaps
some high-resolution touch-screen
interface. Dynamic zooming about the current
touch-point / mouse cursor when drawing in
amongst detailed objects, or the user is forced
to slow down would aid lower resolution input
devices. Rendering would have to be FAST and
slick to pull this off without disorienting the
user. Following topological drawing, tracks
could be allowed to evolve as if they were
sprung-loaded (Ã la liquid-pcb), or processed
through some routine to solidify them. For
"sprung loaded" tracking, I'd imagine having a
virtual obstacle object the user can place on
the board to constrain the tracking. Sprung
loaded / pushed tracking would be updated if the
user were to place and drag an obstacle: | |
| | | -> | | | | | -> | | | | | | |
| | | | | | | | | | | \ \ |
| | | | | | |.\ | | | |->.|
| | | | | | | | | / | | |
| / / | | | | | | | | | | |
| | | | I also imagined a stroked gesture
where the user draws a ring around a bunch of
tracks, as if to tie a rubber-band around them.
This action would group them for operations
such as re-routing. I wonder if this requires
the notion of treating
individual track-segments as a topology. This
would be handy anyway, to aid manual
rubber-banding. Drawing could potentially be
made quicker if we had higher-level data than
individual line-segments (it would reduce the
number of round capped sections requiring
drawing). Magnetic component placement An
augmentation to the grid really - make
components resist being pushed past favourable
alignment points with other components? This
wouldn't STOP components being placed off these
points, just give some "resistance". This
feature would also be quite neat for component
placement, where some future addition of a
courtyard / mechanical interference
spec. within the package definition would
constrain placement to resist motion closer to
other packages than desirable. This could be
absolutely enforced when placing a component, or
act to PUSH the component being run into.
(Obviously dependant on a good algorithm to
re-track the pushed part). I was imagining
this feature being useful for placing an array
of parts such as resistors / capacitors. We
would need the ability to semi-lock tracks I
think... Obviously some tracks won't be up for
auto-pushing, and their geometry will be set
in copper (to adapt a metaphor). Obviously it
should be possible to edit such tracks, but we
might want the to be un-pushable. How about more
novel ways to define planes? Full "pours"
support goes without saying ;) I've looked at
various commercial boards recently, and it would
appear that many use negative layers to draw
tracking. High power stuff, where practically
everything is copper, just with some
isolation between regions. The complexity of
the polygons which make up these traces would
be too prohibitive to use PCB's normal polygon
tool. They _look_ as if someone has drawn
negagtive traces to split up a plane. should
we support that? Alternatively, what about
defining traces / topology for
connected copper, then having a "bloat until
clearance hit" mode, which fattens / fills
everything? I'm still tempted to think that
negative lines gives greater editing potential
once the tracks are placed. (Basically the
negative lines stuff is just "pours" with the
addition of a negative object which subtracts
from polygons and can be used to divides up
areas). Simulation rendering.... Lets assume
we can simulate our board, and have a snapshot
of currents flowing between, or voltages at
nodes. We could render a current density plot
for traces? (Yes, AC / RF / 2D / 3D effects
might be difficult!). I'm thinking of things
like PSU design, where trace size needs to
be considered carefully. Nominal current
density / heating etc..? My ideas are pretty
vague here, but some kind of FEA plot overlaid
on the tracking might be useful. I guess it
depends on the solution method / meshing used,
whether or not it makes sense to render
this data within PCB, or some 2D / 3D FEA
post-processing tool. Electric fields might
also be interesting for some applications.
Technical stuff... Polygons give us
performance headaches. Some usage requires a
fully distilled contour, such as connectivity
checking. (*** Not sure this is 100%
true!) For some operations (e.g. rendering),
we couldn't care less whether clearance holes
overlap or not (if we are just masking them
out). Drawing simple shapes can often be
faster, and when I once accidentally broke PCB
to avoid joining holes in polygons properly, I
was amazed to find it mostly still worked (but
REALLY fast). Only when holes pierce the outer
contour / user specified holes, do they stand
a chance of affecting connectivity. (NB: this is
also true iteratively, so after processing one
hole which touches the countor, another hole
which NOW touches the new contour ALSO needs
processing. Some interesting possibilities
exist, such as making a graph of contours
touching within a polygon. (Rather than
intersecting them). Another idea which has
crossed my mind, is storing a graph of
the primitives and operations which make up a
polygon, e.g. (subtract outer_contour (unite
hole1 hole2 hole3 hole4)) I already put in a
cheat which tracks perfectly circular holes
in polygons for rendering purposes. Tracking
the genesis of shapes would allow rendering
operations which can perform these drawings as
a series of constructive solid^M^M... 2D
geometry operations in the raster plane. (Or
postscript instructions etc..) All in all, I
think this would take us back further towards
the way PCB _used_ to work (IIRC), where
polygon layers _could_ be negative, with
flashed clearances for pads etc., drawn
clearances for lines. Currently, I feel we
loose too much information, and gain too
muchhel detail by "flattening" curves and
boolean operations on geometry to polygons at
the stage we do. -- Peter Clifton Electrical
Engineering Division, Engineering Department,
University of Cambridge, 9, JJ Thomson Avenue,
Cambridge CB3 0FA Tel: +44 (0)7729 980173 - (No
signal in the lab!) Tel: +44 (0)1223 748328 -
(Shared lab phone, ask for me)
_______________________________________________
geda-user mailing list geda-user@xxxxxxxxxxxxxx
http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
_______________________________________________
geda-user mailing list
geda-user@xxxxxxxxxxxxxx
http://www.seul.org/cgi-bin/mailman/listinfo/geda-user