Note:

The Tags relate to conceptual components within the object. As a Part decal may contain more than one canvas object, the Tag will apply to all objects that make up the conceptual definition. These tags will apply to items such as Outlines, Reference , Part Name, Pads, Terminals, pin numbers, pad numbers , etc. The () may contains additional information.

An alternate convention may be to use a special Tag say Data() and format the tag such as Data(ID=123, Ref=U1, Name=BC547). This may be better to manage as finding tags with arbitary data in the () may be problematic.

Using an Associative Array may also be a way of managing the data associated with the higher level object.

Software Functions

1. Add Part
   1. Find part in library
   2. Translate part to origin
2. Tag handling
   1. Get Object Data
   2. Set Object Data
   3. Find Nearest
   4. Replace Tag in Tag List
   5. Get part configuration (all items in part)
   6. Set part configuration (all items in part)
3. Move Object and connected items
   1. Rotate visual
   2. Mirror and Rotate Decal
4. Add Connection
5. Move Line segment
   1. Find Adjoining lines and update/ rubber band
   2. Break line into line segments.
6. Break segment and move new segment
7. Lay track over connection
   1. Break connection into track + unconnected
   2. Create terminal for partial track.
   3. Create track list when track swaps layers.
   4. Segment reduction after track layed.
   5. Adding Vias when changing layer
   6. Track segment moving
8. Swap connection

Object Structure

1. Part
   1. PartType
   2. Reference
   3. Bounding Box
   4. Connection Pairs
   5. Package Reference
   6. Visual
      1. Connection Points
      2. Graphic items
   7. Decal
      1. Pads
         1. Pad Number
         2. Pad graphic
      2. Graphic items

Note

Some Parts contain multiple Decals (such as logic gates). A mechanism must be found that handles this but not one that uses reqursion. Ie. Part A and B can be from the same package but can be listed as two seperate parts. The package must be kept as this will be needed for gate swaping.

Algorithms

Add Line

Bring Terminals To the Top

On Click , Find starting terminal.

Either reject multiple connections to a node or not depending on algorthm. (fyi PADS rejects.)

Create New Line object with Net of NEW. Line will have coords of x y x y.

Set Initial settings for StartX,=%x StartY=%y, Constrained=Yes,Constraint=none

Set Motion to UnConstrained Move + ProcLine

On Click Process Line segment

Right Click Cancels All of New Line and resets state data.

Constrained Move

Calculate Difference

If dX and dY are less then SC(Grid) then ignore event

If Constrained , If no direction set direction H or V by Max dX or dY

If Constrained, reset dX or dY to zero based on constraint

Pass Event to Function (Eq, Move Part, MoveTrack, MoveLine,AddLine)

ProcLine

Change Line

Check if just H or V Move. If so extend last line segment.

Check if more than one segment. Add new one if not

Extend last seqment to new X,Y

Adjust previous seqment so that x2 or y2 meets new x or y based on line direction.

Note: Line splitting algorithm may be common to MovePart connection processing.

MovePart

Move Part to new X, Y.

Get list of Connections. If none end.

Foreach Connection. Get Point connected to pin.

If can extend then do so and end connection.

Otherwise split last line in two and insert vert/horz line to make connection.

Extend last two line segments to new X,Y.

MoveLine

Find Segment in Line list

Check if segment is free to move.

If not free break line as in MovePart by adding extra zero length segment.

Set move contraint direction.

Move segment by delta X or Y.

Managing Tie Dots

The problem wiht tie dots is where are they connected? The easiest way to manage them is to connect them

to an existing net and mark the net as having a tie. This way moving the original net causes the net to be scanned. Cross referencing the net with the netname as a tag will quickly pick up all other nets that are connected.Deleting Lines with tie dots will cause a scan of all other lines to see if the Tie Dot tag is still required.

Given that The other lines are tagged with the name of the other net, tagging with an extra tag is not required.

Which ever method is used to manage tie dots, it required keeping track of tags when any line is moved or deleted. This complicates the way objects are managed and moved.

If a connection with tie dots is deleted, it is a simple matter to take the branch of the original route at the point where the route is deleted and append that to the route of the tie. This may take it to a terminal or a route. In either case the references must be updated. As there could be more than one tie line on the connection, the other ties may need additional processing as the first tie will take the place of the original route but not the net name.

If a tie dot line is to be moved, unconnect it from the end closest to the segment selected and call it a new connection.

Data Structures

Not all of the data for a schematic , netlist or PCB layout can be stored in the canvas items themselves.

Associative arrays would be used to hold the data. Possible structures would be for the following:

1. Parts in design
2. Partial Gates in packages
3. Hidden connections to vcc and gnd.
4. Connections or netlist pairs.
5. Connections to Parts for quick reference.

These data structures would be saved in the design file along with the canvas items.

Libraries

Libraries for parts should be stored in a backend database. Given that this may take some time to set up, parts should be stored in subdirectories within a Library path. This eliminates the need to manage an internal structure within the file.An example file structure is as follows:

Part PartClass RefDes {Internal nets} #Gates { {{Decals} {Visuals}} {{}...{}} }

Where:

PartClass: The Generic class for this part

RefDes: A Letter for assigning referenc designators.

#Gates : Number of Gates in Part = llength of gate list.

Internal Nets : List of internally connected pins (ie. vcc and gnd)

Decals: List of available PCB decals

Visuals: List of available Schematic decals

The Decal File could look like:

Decal Class Scale {bbox} {}

item {coords} {tags} {config}

...

item {coords} {tags} {config}

The tags on the canvas item would distinguish its type (terminal refdes, PartType etc).

A Visual file would be similar:

Visual Class Scale {bbox} {}

item {coords} {tags} {config}

...

item {coords} {tags} {config}

It is expected that Part Visuals will be converted to bitmaps to reduce the number of canvas items and also make processing faster. It would be easy to convert the visual to postscript and run it through ghostscript to convert it to a bitmap. It would be best not to use the bitmap when printing. This requires some thought on where the origins of the visual and bitmap relate in terms of canvas position so that they can be super imposed when printing.

It is quite likely that Decals and Visuals would have the same structure as they are only a collection of canvas items for display on either a schematic or PCB layout.

Note:

All coordinates would be relative to the canvas origin. PCB parts would have to have some scale such as 5 pixels per thou to ensure that pads are routed on a grid. The editor would have to be carefull in calculating the bbox if used as all pads, terminals will be offset from this as the origin. It may pay to use 0,0 as the top left edge of the bbox to avoid shifting the objects by 1 pixel. The bbox should be clipped to the grid. The item should be redrawn in a new canvas at the output scale to prevent repeated zooming and panning changing item coordinates.

The Part files could have an implicit scale describing what scale was used to draw the object. This could be used to scale the object when it is loaded. This could also be used for Decal files to set the pad spacing. This could be used to then scale the pads to exact thou coordinates.

Part Editing

A intergral Part editor would have to be incorporated into the system. In fact this would have to be the first part written. Parts could be crteated by hand to test the other two systems, but most of the support routines would be required by all three components so the starting point is best the editor so that the underlying structure is worked out for the other two components. The part editor could be based on tkpaint as a starting point. Use the basic routines for manipulating objects with some special code for tagging items appropriately such as terminals, outlines, pads, etc.