gEDA-user: Random thoughts on the future interface of PCB

[Peter Clifton <pcjc2@xxxxxxxxx>]

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