Hi Jean-Pierre & Dick & everybody else,
I have completed my modifications to allow multiple instances of one
sheet in a schematic hierarchy.
In the implementation I store a hash which converts path to reference
number. Path is composed via the unique ID / timestamp represented as
8 hex chars -- e.g. here is the segment of a file for one capacitor:
$Comp
L R R?
U 1 1 478AD1B6
P 5650 3400
AR Path="/478AD1B6" Ref="R?"
AR Path="/478C2053/ 478AD1B6" Ref="R2"
AR Path="/478C2408/ 478AD1B6" Ref="R4"
F 0 "R2" H 5750 3450 60 0000 C C
F 1 "R" V 5650 3400 50 0000 C C
F 2 "SM0603" H 5650 3200 60 0000 C C
1 5650 3400
1 0 0 -1
$EndComp
where AR stands for Alternate Reference. There are three alternate
references, R? for when i first created the file, R2 for when the
component is a instantiated via sheet with a timestamp of 478C2053 and
R4 when instantiated via sheet 478C2408.
The text part of F 0 or m_Field[REFERENCE] is updated when a sheet is
loaded or selected in the hierarchy; it is necessary to keep that
around be the field specifies where the text is to be drawn. BOM and
netlisting, of course, works (though it took a bit of work to make it
so!)
DrawSheetStruct is the basis for the hierarchy, as opposed to
SCH_SCREEN -- see http://m8ta. com/images/ 537_2.png
<http://m8ta.com/images/537_2.png> (I made this as I
was trying to figure out how to change eeschema, it's not the clearest
of diagrams). This required quite a few changes, including making
GetScreen() virtual. It has to be virtual because sometimes the
m_Parent pointer was a WinEDA_SchematicFra me and sometimes it was a
WinEDA_DrawFrame, and in WinEDA_SchematicFra me GetScreen() does *not*
return m_CurrentScreen -- it returns m_CurrentSheet- >m_Screen. This
means that all the classes that inherit this method are also virtual
and have the same return type of BASE_SCREEN* -- I've changed this in
pcbnew as well.
Anyway, that's done, and though I have merged the changes, I've not
checked anything in. Still need to figure out how to arrange
interaction with PCBnew, which expects timestamps / unique identifiers
based upon 32-bit integers. As I explained in an earlier email,
forming a unique ID out of the path is easier to implement and
understand than a linked-list of associations. PCB new does not
expect netlist like this, though:
(
( /478FB04E SM0805 R5 R {Lib=R}
( 1 in_3 )
( 2 out_2 )
)
( /478FB047 SM0805 R6 R {Lib=R}
( 1 out_3 )
( 2 in_2 )
)
( /478C2408/478AD1B6 SM0603 R4 R {Lib=R}
( 1 out_2 )
( 2 GND )
)
( /478C2408/478AD1B2 SM0603 R3 R {Lib=R}
( 1 VCC )
( 2 out_2 )
)
...
It loads it fine, though.
There are two options here: add another unique ID to the hash so you
have something like (in the schematic file):
AR Path="/478C2053/ 478AD1B6" Ref="R2" PCBTimeStamp= "45607AAF"
or extend PCBNEW to handle the full paths when cross-probing and
updating based on timestamp not ref (which I never have used... has
anybody?) I prefer the second of these two solutions, because the
first is 'uglier', is less elegant, causes more end-cases due to
redundant information, need to maintain two concurrent unique
identifier lists, cases where the user modifies the reference etc..
Another issue -- global labels seem to be used exclusively for
embedding a sheet in a hierarchy. It seems likely that people will
need both sheet-local labels (served by the wire labels) as well
sheet-independent labels that are truly 'global'. Does it make sense
to make glabel follow it's name (and be a global label), and make a
new button for adding sheet input-output ports?
Therefore, I'm asking you (all)'s advice on the two questions:
(1) which is best: store extra timestamps, modify PCBnew to use paths,
or don't bother & use references for updating pcbnew when the
schematic changes.
From my point of view, the best solution is a pcbnew change to use
I'm on the gEDA developer list, too, and they do not have this
feature; rather than updating the references based in instantiation,
they put the path in the netlist. We are, kinda, competing with
them.. two free software products still competing! -- this would put
us 'ahead' :) (In addition to all the work done on pcbnew.. and the
fact we use c++ not vanilla c)
thanks & sorry about the long email,
Tim
ps. Dick: I had some look at the visitor design pattern -- it looks
cool and i wanted to try to solve the GetScreen() issue without
resorting to a 'virtual BASE_SCREEN* ' (as this requires typcasting to
any of the derived classes), but, I couldn't come up with any better
solutions. :(
