kicad-developers team mailing list archive

["daystar1013" <daystar@...>]

Hello everyone,
I'm not sure if it is relevant to this conversation, but I will 
present the question anyway. What is the intended purpose of the 
predefined 'Sheet' field in the part properties?

Thanks
Carl
--- In kicad-devel@xxxxxxxxxxxxxxx, jean-pierre charras <jean-
pierre.charras@...> wrote:
>
> Tim Hanson a écrit :
> >
> > yes, I've thought about this.
> >
> > -- The multiple units per device are not such an issue if, like 
me, you
> > group all the units in a given device onto one sheet. I think 
this is a
> > semi-reasonable assumption. It becomes too confusing if you do 
not do
> > this.
> > -- Concerning long references, it is not such an issue if you 
name your
> > sheets with really short names .. like "0" or so. Then reading a
> > component adds a maximum of one digit to the component reference. 
But, you
> > are right in that ultimately all this is compiled down to a 
board, which
> > is 'flat' in both a physical and hierarchal sense, and numbers 
are a
> > concise way of writing & storing unique identifiers :) Yet if you 
do use
> > 0402, SC-70, CSP etc there is no room for silkscreen anyway.
> >
> A problem when using the sheet number or the sheet name is these 
two 
> items are subject to change:
> - the sheet number changes when adding a new sheet.
> - the sheet name changes when the user edit it...
> 
> - Adding the sheet number or name to the reference is a good idea 
for 
> simulation,
> but this usually creates a big problem for boards if the reference 
of 
> already placed footprints changes.
> 
> In fact we can reannotate a schematic without problem on a board, 
but 
> only if we take care.
> All the items in kicad have a time stamp (m_TimeStamp member of  
the 
> EDA_BaseStruct class) which is set when the component is put on a 
sheet.
> This time stamp is different for alls items, and does not change 
when 
> editing (but it changes if we delete a component, and reload a new 
> identical component )
> This feature allows to reannotate components in the schematic and 
send 
> the changes to the board in a 3 steps manner:
> 1 - create a fresh netlist and read it by pcbnew (not really 
necessary, 
> but ensures the time stamps are corresponding between the schemativ 
and 
> the board)
> 2 - reannotate schematic and create the new netlist
> 3 - Reread the netlist by pcbnew, using the option "module 
selection" by 
> time stamp. the new references will be updated, from the time stamp.
> 
> So remember the time stamps must be handled like the references
> 
> > That said, we could avoid all of these problems by extending 
the .SCH file
> > format to include the possibility of multiple references per 
device (or
> > unit). This was my original intention, but then somebody (Frank 
Bennett)
> > on the list suggested a hierarchal system of naming. Actually, it 
would
> > not be impossible to allow both naming schemes, selectable via a 
radio
> > button. You would have to modify the file format, though. I 
suggest
> > extending the
> > L R R35
> > line to something like
> > L R R35 R67 R99 R131
> > etc
> > I think this would not break old versions of eeschema.
> > The location and size of the text would still be stored in the
> > F 0 "R35" H 6650 1800 50 0000 C C
> > line, with the R35 exchanged with an entry in the reference list, 
indexed
> > by the # of the containing sheet.
> >
> As prevously seen, the time stamp and also must be handled in a 
similar 
> manner...
> 
> Obviously, the .SCH file format will be changed to support this new 
feature.
> Of course we can't expect old versions of eeschema read a new 
feature in 
> .sch files.
> In fact, this is not a problem.
> I think the .SCH file format might not change when the projectno 
has 
> not a complex hierarchy
> If the project has a complex hierarchy, new format will not be read 
by 
> old eeschema version,
> but in fact, it is already the case! because annotations and time 
stamps 
> are lost.
> Do not bother with old eeschema versions.
> 
> So we can add new lines for each component in a complex hierarchy 
like 
> (and somewhat more verbose than other lines):
> $Comp
> L GND #PWR01
> U 1 1 4718A579
> AltRef "sheet_id" Ref="Ref" Part=n TimeStamp=<TimeStamp value> // 
as 
> many lines as sheet instances and therefore sheet_id
> P 8650 4550
> F 0 "#PWR01" H 8650 4550 30 0001 C C
> F 1 "GND" H 8650 4480 30 0001 C C
> 1 8650 4550
> 1 0 0 -1 
> $EndComp
> 
> > Right now, I've split up DrawSheetStruct and SCH_SCREEN so the 
former
> > contains a reference to the latter. Hence, you can have multiple
> > DrawSheetStructs referring to one SCH_SCREEN. SCH_SCREEN has the
> > EEDrawList of components. I think this is better than having a 
number of
> > duplicates in the hierarchy, as is done now, as this allows 
changes to one
> > schematic to immediately propagate to all other schematics, each 
which
> > ultimately is tied to the same file anyway.
> >
> > While I'm at it:
> > -- Would it be ok to split the header files up? Right now, if i 
make one
> > change to wxstruct.h, I have to recompile eeschema, which takes a 
while.
> >
> Ok.
> >
> > -- What about class names? There is:
> > --- SCH_SCREEN,
> > --- DrawSheetStruct,
> > --- EDA_DrawLineStruct,
> > --- WinEDA_ErcFrame, & others.
> > I get the Win{...} files, they are all derived from wxWidgets 
classes.
> > Would it be good to clean all this up?
> > -- The file names are confusing: there is:
> > --- annotate_dialog. cpp and dialog_find. cpp,
> >
> > --- component_class. cpp and class_screen. cpp and sheet.cpp.
> > Class member functions are often spread out among different 
files. It
> > does not bother me -- I have everything in KDevelop, and when i 
want to
> > change something i just grep all the files, but ... ?
> >
> > Anybody have opinions on these things?
> >
> Cleaning up files is a good thing.
> I suggest for file names:
> all dialog files start with "dialog_":
> dialog_xxxx.pjd (created from dialogblock)
> dialog_xxxx.cpp (when created from dialogblock, use 
dialog_blocks to 
> rename files)
> dialog_xxxx.h (when created from dialogblock, use dialog_blocks 
to 
> rename files)
>  
> all files relatives to classes start with "class_" :
> class_xxx.cpp (and class_xxx.h)
> 
> 
> >
> > > Tim Hanson a écrit :
> > >> Hi,
> > >>
> > >> Yes, I'm willing to do this, and I've already got some start.
> > >> Originally
> > >> I had planned to give every component a different reference 
> > depending on
> > >> the sheet instance it is in (orcad style, i guess), but a 
hierarchal
> > >> name
> > >> is much, much better (and requires no change to the file 
format), so
> > >> let's
> > >> do that? It will make the netlists longer, but it will also 
make them
> > >> more readable. Unless anyone has better ideas, I'll start 
tomorrow ...
> > >> cheers,
> > >> Tim
> > >>
> > >
> > > This does not work for components which have more than one part 
per
> > > package, like a 74HC00.
> > > In this case the component must have the same reference in all 
sheets
> > > (say U1), and this is only the selected part (U1A U1B or U1C...)
> > > and not the reference which changes from a sheet to an other 
sheet, and
> > > **not** the reference.
> > > Of course, the board knows only U1.
> > > In fact, handle the multiple parts per package components is 
the main
> > > difficulty.
> > > And most of cases we can't have long references in a board, 
because smd
> > > footprints are smaller and smaller,
> > > and only very short references (also true for values) can be 
drawn on
> > > the board.
> > > (And if a sheet includes an other sheet, references can become 
*very*
> > > large.)
> > >
> > > --
> > >
> > > Jean-Pierre CHARRAS
> > >
> >
> 
> 
> -- 
> 
> 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 :
> GIPSA-LIS - INPG
> 46, Avenue Félix Viallet
> 38031 Grenoble cedex
>