← Back to team overview

kicad-developers team mailing list archive

Re: zone fill and Eeschema


Tim Hanson a écrit :

How are the zones filled at this point? If they are filled with other
tracks, then we could just do a region-growing algorithm on all the
tracks in that filled region, much the same way the netlist is created
from segments by propagating net codes. For each net, select one pad
and propagate to all others that are connected by line & endpoint
radius considerations -> those not affected are not connected. I do
not think it is possible to determine whether a via is connected to a
zone without an actual fill 'plan' or 'instantiation' .

> FreePCB does not detect insulated pads in a zone, and we can have
> inside a zone a pad not connected (if tracks encircle this pad)
> I (or an other guy) must study gpcb code.

Or we could just ask them. gEDA people are plenty friendly...i asked
them about the hierarchy stuff.

Good !
(And the last version of gervb is very good.)

> Unfortunately, currently i have a lot of work, and i must also finish
> some sections of code relative to the complex hierarchy implantation.

uh... you mean the stuff I grafted into eeschema? Need any help? What
was wrong with what I wrote??

Need any help? Yes.
What you wrote is good!
And again, thanks.
I am using the new eeschema in a recent project.

But some things are not finished. (i have seen some comments in new code related to this).
And some (very complex) things must be fully tested.
What i fixed is:
- some unicode problems
- problem when a file is not found when loading a schematic hierarchy.
What i fixed but needs more tests is:
- better hierarchy management when changing the filename in a hierarchical sheet.
What i fixed but needs more tests and more work is:
- Undo/redo sheets deletion (sheet or block delete)

In fact what happens in a complex hierarchy is ... complex! when events are relatedt to undo/redo and some block commands:
What needs tests and work is:
- Block copy and block save.
- Undo redo, mainly with block delelete, copy and save.

Undo (and redo) retains the 10 last commands, so problems can happen after 10 (or more) changes.

Enhancements or/and tests an check:
copy of an existing sheet in the current hierarchy must be enhanced and tested:
- the copy must have a new timestamp
- the components must be unannotated.
- the sheet name must be unique (like time stamp), therefore changed.
- The undo/redo must be tested

- Multi part per package components create problems (duplicate)
I believe the current code could be easily enhanced to support multiparts in a complex hierarchy if the part ident is managed like the ref (in a <vector> list)

Generally speaking we must test what happens in a complex hierarchy (3 or more levels with a sheet used in many other sheets at different levels) in "curious" circumstances:
Critical commands are block commands and undo/redo.
- undo/redo sheet edition (like resize, delete a pin label...) (the undo/redo involves copy of the sheet) - Succesive commands like delete, reannotate, block move, copy, paste, undo/redo (the block undo/redo also involves copy of sheets)...
- changing file name or sheet name (undo/redo...)
- reread only a file in the hierarchy
- insert a sheet which already includes the current sheet (easily possible when editing a filename...)
- and others curious things (users **have** curious ideas)

If you have some time to spend to do some topics, thanks.

PS: it is better to use an unicode version of wxWidget, because code working in unicode version works in ansi version,
but code working in ansi version does not always works in unicode version

Jean-Pierre CHARRAS
Maître de conférences
Directeur d'études 2ieme année.
Génie Electrique et Informatique Industrielle 2
Institut Universitaire de Technologie 1 de Grenoble
BP 67, 38402 St Martin d'Heres Cedex

Recherche :
Grenoble Image Parole Signal Automatique (GIPSA - INPG)
46, Avenue Félix Viallet
38031 Grenoble Cedex