________________________________
From: Robert <birmingham_spider@...>
To: kicad-users@...
Sent: Tuesday, June 12, 2012 6:10 PM
Subject: Re: [kicad-users] Re: Comments About Eeschema [1 Attachment]
?
[Attachment(s) from Robert included below]
In that case I'll go ahead with a basic set of symbols.?? I'll leave
Bernd's library alone, copying symbols as necessary.?? I will shrink
some components, so perhaps I should postfix the components with _SMALL
to eliminate clashes.?? Mainly I'll be shortening pin lengths.
Is it OK in IEC60617 to have circles around transistors??? I notice that
a circle is included when one of the electrodes is connected to the
envelope (and then you're supposed to show the connection with a dot),
but what about where there is no connection??? My PDF shows no circle.
I like having the circle because it shows at a glance that the part
has its own package, and by making part of the circle dashed one can
show at a glance that the component shares its package with other
devices (and therefore there will be fewer packages on the board).?? By
way of example?? I've attached an image showing my own symbol for a
BC817DS, for which Yahoo Groups should provide a link.
Regards,
Robert.
Hi Robert,
?The circle indicates the physical envelope of the device and is probably still in the standard (looking at schematics from work, the circle is there); typically you see transistors without that circle on IC datasheets where the envelope is drawn as a rectangle showing the equivalent simplified circuitry inside, and if you were using a chip with multiple unconnected transistors you would use the symbol without a circle and provide a reference designator to indicate that the transistor is part of a multi-component package. However, the emitter and collector lines must not intersect - they only touch the base and not eachother.? In general none of these slanted lines should intersect; after all, in the physical device E and C do not connect.
- Cirilo
On 12/06/2012 00:15, Cirilo Bernardo wrote:
Hi Bernd,
Thanks for your responses.??I went through the KiCAD posts looking
for discussions on grid sizes; it looks like EESchema will retain the
mil grid (in all the posts I can find regarding grids, the devs say
they have no plans to change the schematic grid since there is no
great advantage to this). So I was mistaken; symbol standardization
can go on with the mil grid.??This does result in larger symbols
though since nodes are at 2.54mm rather than 2.0mm.
________________________________ From: Bernd
Wiebus<bernd.wiebus@...> To: kicad-users@... Sent:
Tuesday, June 12, 2012 4:08 AM Subject: Re: [kicad-users] Re:
Comments About Eeschema
Hello Cirilo.
Have you seen Bernd Wiebus's EN60617 (aka IEC60617) kicad
library?
If it's correct (I have no reason to doubt that but I have
nothing to check it against, though maybe those Chinese sites
are worth exploring) I guess it would be a good place to start,
though personally I find Bernd's symbols too big.?? Is it the
latest standard?
Some of those symbols do comply with the IEC standard and many
that don't do comply with older standards.
If this is, it is marked by the symbols name. Thomething with
"old". In this cases, there are existing two symbols, one for the
old standard, ans one for the new. This is because here most people
like the old timed full black inductance boxes.....
But there are some "needfull things" among those EN60617 symbols,
wich are not EN60617, but this are normally not electronic devices,
with the exeption of "wire bridges". If desired, i could split this
library in two and purify the EN60617 part.
I suspected some people wanted older symbols; personally I think some
of the older symbols are prettier and for me they're easier to
understand. It would be good to keep the EN60617 compliant symbols in
their own directory+library since that will help a lot with the
standardization process and in the future if people have requirements
to use a specific symbol set it makes it easier for them to comply.
Anyway, as I said, what's important is that people can read the
schematics.
I think Bernd's symbols can't really be shrunk much more;
EN60617 makes no statements about the aspect ratio of symbols
(means wether a resistor "box" is lean or fat and something like
this). And for kicad i should not go away from the 50-50 raster for
easily drawing circuits without jumping into the engin room and
changing the raster.
That's one of the situations common with standards (lack of
implementation details).??In this case it just means choosing your
own settings based on what looks good and is easy to read; the grids
used might impose some restrictions on what you can draw and that may
be one reason the aspect ratio is not specified.
I'd say his symbols are OK, certainly usable, but most can be
improved (for example, the purists will howl about the line
connecting the vertices of the inductor symbols - and rightly
so). The problem as usual is time; building a good symbol set
takes an awful lot,
Yes. This is a time problem. But there are some other points
counted against creating a "new" library. And this is to be
compatible with older versions of this library. If i change them to
much, people will see gaps if the new symbols do not fit to the
same connections as the old do. This may not be an issue for an
experinenced kicad user, but for an necomer.
I agree 100%.??I was thinking there would be a metric and a mil set
of symbols, but for now it looks like EESchema will retain the mil
grid.
and at this point in time I'd recommend waiting for KiCAD to go
metric (internal units = nanometers) before spending time
building up standard symbols. However, if you look at the symbols
which come with KiCAD, very many (I can't say 'most' because I
haven't looked through the set and counted the bad ones) are not
only non-compliant with the latest IEC specifications, but I
don't recognize the symbols as IEC, IEEE, or ASME - some of the
symbols are such poor caricatures of standard symbols that they
will actually make a schematic difficult to read.
This is because there is not only a mixing between IEC, IEEE, ASME
ec. but with different ages of this librarys, too.
What I would like to see in the future is a standards-compliant
symbol set for KiCAD.??This can start with an IEC60617 directory
with libraries classified according to form or function - that
alone will give us many of the symbols we typically use - and
then people can contribute other symbols but those symbols will
need to be vetted before they're put into the library tree; once
you head down the path of standardization you really can't afford
any compromise - any symbols which have not been vetted will have
to go into a 'non-standard' directory branch.
Ok.
This is all somewhat academic at the moment.??KiCAD is certainly
usable as it is and although it would be great to start
implementing improvements, KiCAD also happens to be in a state of
development where it's probably best to hold back on making those
improvements.
The actual version of my EN60617 Library is RefE4. So send me your
suggestions for improvement.
With best regards: Bernd Wiebus alias dl1eic
Thanks Bernd,??for now I can't really comment since I don't have a
copy of the specifications or a current subscription to the database;
my previous comments such as the one about the wire crossing the
vertices of the inductor symbol was based on what I remember of
specifications ca. 1998.??I think for now, just keeping the standards
compliant symbols separate from the others and with perhaps a note in
the directory to give the name of the reference document is a good
step.??Hopefully in about a year I can put some effort into building
and checking symbols.
- Cirilo
------------------------------------
Please read the Kicad FAQ in the group files section before posting
your question. Please post your bug reports here. They will be picked
up by the creator of Kicad. Please visit for
details of how to contribute your symbols/modules to the kicad
library. For building Kicad from source and other development
questions visit the kicad-devel group at
! Groups Links
--- avast! Antivirus: Inbound message clean. Virus Database (VPS):
120611-0, 11/06/2012 Tested on: 12/06/2012 08:26:12 avast! -
copyright (c) 1988-2012 AVAST Software.
--
() Plain text email - safe, readable, inclusive.
/\
