Re: [Kicad-developers] Schematic Symbol Philosophy?
I agree with you. Too loudly that this is a problem. I only suggested own idea as a new feature. P.s.In my work we use a narrow specific range of parts and make cvpcb looks excessive. For me, it'snot difficult. But for simple users that use pcad it is difficult. They say: whatto dorethe same thing(you can make mistakes). It was an offer, do not judge strictly. 08.06.2015 19:42, Andy Peters пишет: On Jun 7, 2015, at 1:33 AM, Eldar Khayrullin eldar.khayrul...@mail.ru wrote: What problem is this trying to solve? No copy sch symbols, no copy pcb footprints, more ready parts with same sch symbol and footprint, but different pins assignment. I still don’t understand why you think there are problems. Let’s talk op-amps for the moment. Does your schematic library have a generic op-amp which you place on every design? Do you then go into the schematic and modify the symbol you placed so that it calls out TL072 and the correct unit, and then do you go in and also add the desired footprint? If so, for the love of G-d, WHY? That is a recipe for disaster. Why not just have in your library a few of your favorite op-amps: TL072ACD, OPA2134UA, OP275GSZ. Note the symbol names, which are the vendor part numbers and as such have the footprint encoded into them. And, each symbol has the correct footprint embedded in it. Do you consider this “unnecessary duplication” in that each of these dual op-amps has the same symbol and uses the same footprint (SOIC-8)? It is MUCH harder to make an expensive mistake if the symbol — the “component” — is “complete,” in that it has the correct pin-out which matches the footprint. Your suggestion of a components library” solves a problem which doesn’t actually exist. -a ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp * Английский - определен * Английский * Русский * Английский * Русский javascript:void(0);# ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
Re: [Kicad-developers] on incorrect polygon behavior
Hi Tom, just for reference, you can find a benchmark of various polygon libraries here: http://rogue-modron.blogspot.de/2011/04/polygon-clipping-wrapper-benchmark.html It shows as well that Clipper performs better than Boost.Polygon and thus is a good selection. And CGAL is well known but slow compared to the alternatives. However it makes maybe sense to have a look at Boost.Geometry (not Boost.Polygon) - because this library has almost the same performance compared to Clipper but is more general; because they use metaprogramming (header-only template library). There you can find many useful algorithms and also spatial indexes like R-Trees. One advantage that I'd see is that you can adapt directly the VECTOR2 class. http://www.boost.org/doc/libs/1_58_0/libs/geometry/doc/html/index.html Greetings, Torsten Hi, It took me a bit longer than initially anticipated to write the fracturing (polygon with holes - single outline conversion) algorithm that was missing in Clipper. I managed to generate correct zones and the algorithm does not crash on the test cases that were crashing Boost.Polygon. My plan is now to: - clean SHAPE_POLY_SET code and send the patch asap (perhaps Monday, I'm out for the weekend), - optimize fracturing, which is taking most of the calculation time. To my surprise, Clipper performs calculations faster than BPL, - look into possibility of having a single polygon set class, merging the functionality of CPolyLine, CPOLYGONS_LIST and all BPL-derived classes, - keep fallback BPL zone code which could be switched on in the preferences. - add an option to dump zone geometry (outline, holes, thermals, full poly) to a text file while refilling zones. The last two options are temporary - to gather confidence in Clipper, compare the performance of BPL/Clipper and, in case of trouble, obtain test cases for both backends. Cheers, Tom ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
Re: [Kicad-developers] CvPcb change.
On 6/8/2015 6:10 AM, LordBlick wrote: In response to a message written on 07.06.2015, 20:20, from Wayne Stambaugh: I just committed a patch (r5718) from Dick that should greatly simplify the process of footprint assignment using cvpcb. This patch does away with using the intermediate *.cmp file and directly updates the s-expr netlist via kiway express messaging. This means there is no more stand alone executable of cvpcb. This also means that you will have to use the s-expr netlist when importing in pcbnew. If you do not normally back import the footprint assignments from the *.cmp file into eeschema, you will have to do this before your run cvpcb because the s-expr netlist will not contain the footprint assignments until you do this. This patch will eliminate one more unnecessary step when assigning footprints and streamline the process. I still need to fix the save tooltip in the cvpcb toolbar since the *.cmp file does not get saved. I also need to remove the read footprints from *.cmp file in the pcbnew import netlist dialog since the *.cmp can no longer be generated by cvpcb. Going forward, the *.cmp file will only be useful for back importing from pcbnew to eeschema. At some point in the future, even that will go away.j Please test this and let me know if you find any issues. It's nice message, but sth missed… In CMakeList.txt:769 not existing target „cvpcb” also should be renamed to „cvpcb_kiface”. Fixed in r5724. Thanks for pointing this out. Cheers, Wayne ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
Re: [Kicad-developers] [PATCH] pcbnew crashes when loading file with bad net ID
Chris, I committed this patch with a minor change to make the exception message a bit more understandable. Thanks, Wayne On 6/7/2015 7:24 PM, Chris Pavlina wrote: If you try to load a kicad_pcb into pcbnew that refers to an invalid net ID, pcbnew crashes after failing an assertion. It should display an error indicating that the file is corrupt instead. I've changed BOARD_CONNECTED_ITEM::SetNetCode() to be able to indicate whether the code was valid, rather than just asserting, and then changed PCB_PARSER::parseTRACK() to check for this and complain using Expecting(). I'd rather have used an exception to do this, but we don't have any exception types that look suitable. Thoughts? Here's a board file that causes this: http://misc.c4757p.com/2VB701E.kicad_pcb -- Chris ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
Re: [Kicad-developers] Schematic Symbol Philosophy?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 06/08/2015 06:42 PM, Andy Peters wrote: On Jun 7, 2015, at 1:33 AM, Eldar Khayrullin eldar.khayrul...@mail.ru wrote: What problem is this trying to solve? No copy sch symbols, no copy pcb footprints, more ready parts with same sch symbol and footprint, but different pins assignment. I still don’t understand why you think there are problems. Let’s talk op-amps for the moment. Does your schematic library have a generic op-amp which you place on every design? Do you then go into the schematic and modify the symbol you placed so that it calls out TL072 and the correct unit, and then do you go in and also add the desired footprint? If so, for the love of G-d, WHY? That is a recipe for disaster. Why not just have in your library a few of your favorite op-amps: TL072ACD, OPA2134UA, OP275GSZ. Note the symbol names, which are the vendor part numbers and as such have the footprint encoded into them. And, each symbol has the correct footprint embedded in it. Do you consider this “unnecessary duplication” in that each of these dual op-amps has the same symbol and uses the same footprint (SOIC-8)? It is MUCH harder to make an expensive mistake if the symbol — the “component” — is “complete,” in that it has the correct pin-out which matches the footprint. Your suggestion of a components library” solves a problem which doesn’t actually exist. The components library is the approach Eagle uses, and I have a bit of Eagle experience, so let me try to explain... In that approach, you do _not_ place just a symbol in a schematic, but an entire component (maybe a TL072ACD) or a component for which there are several variants (maybe a TL072A with the variants CD and DE, one a SOIC8, the other a PDIP8, but same symbol). This makes the creation of new components and variants very easy, as long as the symbol and the package (Eagle speak for footprint) exist. All you have to do is to give it a name and connect symbol pins to footprint pads. This last step is basically what you used to do with CVPCB, only you do it only once, when you create the component. You don't have to do it for every TL072ACD in your schematic (where I agree it's very error prone), and it's more flexible than CVPCB, because it can connect pin 1 (symbol) to pin 3 (footprint) or pin E (symbol) to pin 3 (footprint) - so you don't need the TO220BCE/ECB/CBE/123 footprints. So you have a single canonical version of each footprint and symbol. No need to copy symbols for creating new components, no need to update or even touch all your OP-Amps when the one you based your symbol on shows a bug. Or in other words: It takes your library with a few of your favourite OP-Amps, each with the correct footprint embedded one step further: The components only link to symbols and footprints. If you place a component in a schematic, it shows the symbol linked from it, and stores the information of available footprints to be used when you create a PCB from the schematic. If you place a component on a PCB, it shows one of the footprints it links to (or a selection dialogue). Maybe this clears the mud a little? Heiko - -- Mein PGP-Key zur Verifizierung: http://pgp.mit.edu -BEGIN PGP SIGNATURE- Version: GnuPG v2 iEYEARECAAYFAlV16sQACgkQ/Vb5NagElAVh+ACfQIRaQ6+LJqjxQFOYGQUA7ssp zOsAn1tT8g+a+25dzAdqQ3nAH8muUksb =hzJ/ -END PGP SIGNATURE- ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
[Kicad-developers] [PATCH] Show targets on bus entry as well, hide when connected
Hi,
I already sent in this patch but as a reply to my existing pin targets
thread; I think it may have got lost. This patch enables pin targets
on bus entries as well, as Wayne suggested, and hides them when the bus
entry is connected.
--
Chris
commit a646e6c4b1a9ef624b4f56101d3a55f747558bf2
Author: Chris Pavlina cpavl...@binghamton.edu
Date: Sun Jun 7 22:02:45 2015 -0400
Show targets on bus entries
diff --git a/eeschema/sch_bus_entry.cpp b/eeschema/sch_bus_entry.cpp
index 227f88a..6b3e3b6 100644
--- a/eeschema/sch_bus_entry.cpp
+++ b/eeschema/sch_bus_entry.cpp
@@ -35,6 +35,7 @@
#include common.h
#include richio.h
#include plot_common.h
+#include boost/foreach.hpp
#include eeschema_config.h
#include general.h
@@ -182,6 +183,7 @@ void SCH_BUS_ENTRY_BASE::Draw( EDA_DRAW_PANEL* aPanel, wxDC* aDC, const wxPoint
GR_DRAWMODE aDrawMode, EDA_COLOR_T aColor )
{
EDA_COLOR_T color;
+EDA_RECT* clipbox = aPanel-GetClipBox();
if( aColor = 0 )
color = aColor;
@@ -190,8 +192,16 @@ void SCH_BUS_ENTRY_BASE::Draw( EDA_DRAW_PANEL* aPanel, wxDC* aDC, const wxPoint
GRSetDrawMode( aDC, aDrawMode );
-GRLine( aPanel-GetClipBox(), aDC, m_pos.x + aOffset.x, m_pos.y + aOffset.y,
+GRLine( clipbox, aDC, m_pos.x + aOffset.x, m_pos.y + aOffset.y,
m_End().x + aOffset.x, m_End().y + aOffset.y, GetPenSize(), color );
+
+if( m_isDanglingStart ) {
+GRCircle( clipbox, aDC, m_pos.x + aOffset.x, m_pos.y + aOffset.y, TARGET_BUSENTRY_RADIUS, 0, color );
+}
+
+if( m_isDanglingEnd ) {
+GRCircle( clipbox, aDC, m_End().x + aOffset.x, m_End().y + aOffset.y, TARGET_BUSENTRY_RADIUS, 0, color );
+}
}
@@ -230,6 +240,50 @@ void SCH_BUS_ENTRY_BASE::GetEndPoints( std::vector DANGLING_END_ITEM aItemLi
}
+bool SCH_BUS_ENTRY_BASE::IsDanglingStateChanged( std::vectorDANGLING_END_ITEM aItemList )
+{
+bool previousStateStart = m_isDanglingStart;
+bool previousStateEnd = m_isDanglingEnd;
+
+m_isDanglingStart = m_isDanglingEnd = true;
+
+// Wires and buses are stored in the list as a pair, start and end. This
+// variable holds the start position from one iteration so it can be used
+// when the end position is found.
+wxPoint seg_start;
+
+BOOST_FOREACH( DANGLING_END_ITEM each_item, aItemList )
+{
+if( each_item.GetItem() == this )
+continue;
+
+switch( each_item.GetType() )
+{
+case WIRE_START_END:
+case BUS_START_END:
+seg_start = each_item.GetPosition();
+break;
+case WIRE_END_END:
+case BUS_END_END:
+if( IsPointOnSegment( seg_start, each_item.GetPosition(), m_pos ) )
+m_isDanglingStart = false;
+if( IsPointOnSegment( seg_start, each_item.GetPosition(), m_End() ) )
+m_isDanglingEnd = false;
+default:
+break;
+}
+}
+
+return (previousStateStart != m_isDanglingStart) || (previousStateEnd != m_isDanglingEnd);
+}
+
+
+bool SCH_BUS_ENTRY_BASE::IsDangling() const
+{
+return m_isDanglingStart || m_isDanglingEnd;
+}
+
+
bool SCH_BUS_ENTRY_BASE::IsSelectStateChanged( const wxRect aRect )
{
bool previousState = IsSelected();
diff --git a/eeschema/sch_bus_entry.h b/eeschema/sch_bus_entry.h
index 09e1007..5de14e6 100644
--- a/eeschema/sch_bus_entry.h
+++ b/eeschema/sch_bus_entry.h
@@ -32,6 +32,8 @@
#include sch_item_struct.h
+#define TARGET_BUSENTRY_RADIUS 12 // Circle diameter drawn at the ends
+
/**
* Class SCH_BUS_ENTRY_BASE
@@ -43,6 +45,7 @@ class SCH_BUS_ENTRY_BASE : public SCH_ITEM
protected:
wxPoint m_pos;
wxSize m_size;
+bool m_isDanglingStart, m_isDanglingEnd;
public:
SCH_BUS_ENTRY_BASE( KICAD_T aType, const wxPoint pos = wxPoint( 0, 0 ), char shape = '\\' );
@@ -100,6 +103,10 @@ public:
void GetEndPoints( std::vector DANGLING_END_ITEM aItemList );
+bool IsDanglingStateChanged( std::vectorDANGLING_END_ITEM aItemList );
+
+bool IsDangling() const;
+
bool IsSelectStateChanged( const wxRect aRect );
bool IsConnectable() const { return true; }
___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help : https://help.launchpad.net/ListHelp
Re: [Kicad-developers] 3D model generation.
If you can give me some sample part numbers I'll have a look. - Cirilo On Tue, Jun 9, 2015 at 1:55 AM, Wayne Stambaugh stambau...@gmail.com wrote: Does anyone have a parametric 3D model generator script for two pin J lead components like SMD tantalum caps or SMD DO diode packages? I'm using some of the large SMD wire wound resistor packages (2515, 4527, etc.) in some of my designs and I was hoping there would be an easier way to create them rather than using Wings3D. Thanks, Wayne ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
Re: [Kicad-developers] on incorrect polygon behavior
On 08.06.2015 19:42, Torsten Hüter wrote: Boost.Geometry (not Boost.Polygon) - because this library has almost the same performance compared to Clipper but is more general; because they use metaprogrammin Hi Torsten, Thanks for the tip. I've known this performance comparison, it shows Clipper is quite fast and if you combine its speed with simplicity (only 2 very cleanly written source files), it's one of the best libraries available. After working with BPL for a while, looking at the quality of the code and the idea of generic geometry library (BPL authors admit it works only for integer types, because for floats/doubles rounding is not handled correctly), I'm sure I'll never use boost for anything geometry-related. Tom ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
Re: [Kicad-developers] Schematic Symbol Philosophy?
On Mon, Jun 08, 2015 at 11:28:08PM +0200, Heiko Rosemann wrote: A given component should have exactly ONE available footprint. If your opamp comes in PDIP-8 and SOIC-8, those are two different components. Why? There's a good point for the opposite: Making different PCBs (SMD for series production/no SMD for prototyping/hobbyists or different casings) from a single - consistent - schematic. Otherwise you are going to run into trouble because you'll have multiple schematics of the same system and you need to change something on the logical (schematic) side. I explained this already. Look at the pinouts for the different footprints of LT1013. Only a very inexperienced person would claim that assuming different footprints have the same pinout is a good idea. -- Chris ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
Re: [Kicad-developers] Schematic Symbol Philosophy?
On Jun 8, 2015, at 12:19 PM, Heiko Rosemann heiko.rosem...@web.de wrote: The components library is the approach Eagle uses, and I have a bit of Eagle experience, so let me try to explain... In that approach, you do _not_ place just a symbol in a schematic, but an entire component (maybe a TL072ACD) or a component for which there are several variants (maybe a TL072A with the variants CD and DE, one a SOIC8, the other a PDIP8, but same symbol). This makes the creation of new components and variants very easy, as long as the symbol and the package (Eagle speak for footprint) exist. All you have to do is to give it a name and connect symbol pins to footprint pads. This last step is basically what you used to do with CVPCB, only you do it only once, when you create the component. You don't have to do it for every TL072ACD in your schematic (where I agree it's very error prone), and it's more flexible than CVPCB, because it can connect pin 1 (symbol) to pin 3 (footprint) or pin E (symbol) to pin 3 (footprint) - so you don't need the TO220BCE/ECB/CBE/123 footprints. For the record: I’ve never used CvPCB, and I’ve always thought that it was a mistake. I have always embedded footprint (and custom part numbers) into my schematic symbols. So you have a single canonical version of each footprint and symbol. No need to copy symbols for creating new components, no need to update or even touch all your OP-Amps when the one you based your symbol on shows a bug. Or in other words: It takes your library with a few of your favourite OP-Amps, each with the correct footprint embedded one step further: The components only link to symbols and footprints. OK, so this “component” library is something that maps symbols (from a symbol library) and footprints (from a footprint library) into a third library, in much the same was as Altium does with their Integrated libraries. If you place a component in a schematic, it shows the symbol linked from it, and stores the information of available footprints to be used when you create a PCB from the schematic. A given component should have exactly ONE available footprint. If your opamp comes in PDIP-8 and SOIC-8, those are two different components. If you place a component on a PCB, it shows one of the footprints it links to (or a selection dialogue). Here’s a question: why would you place a component on a PCB? That component has no connectivity information, and Kicad won’t (and IMHO, shouldn’t) let you edit the netlist in pcbnew. (How should it regenerate the schematic when you do that?) So I see what you’re saying … the “symbol” library should contain symbols only, and have no connection to a footprint, and you need a component library to map a symbol with a footprint (and a 3D model, and a custom part number for the BOM). The engineer doing the design interacts only with the component library; only the librarian needs to be concerned with the symbol and the footprint libraries. Gotcha. From the perspective of the user who considers each symbol to be a component (again, that is: embedded footprint, embedded custom part number, different symbols for TL072ACD and TL072ACP) and ignores the CvPCB crap, there’s not much benefit to a separate component library. That is especially true given the inability to edit a netlist in pcbnew. -a ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
Re: [Kicad-developers] Schematic Symbol Philosophy?
On Jun 8, 2015, at 2:28 PM, Heiko Rosemann heiko.rosem...@web.de wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 06/08/2015 10:41 PM, Andy Peters wrote: On Jun 8, 2015, at 12:19 PM, Heiko Rosemann heiko.rosem...@web.de wrote: So you have a single canonical version of each footprint and symbol. No need to copy symbols for creating new components, no need to update or even touch all your OP-Amps when the one you based your symbol on shows a bug. Or in other words: It takes your library with a few of your favourite OP-Amps, each with the correct footprint embedded one step further: The components only link to symbols and footprints. OK, so this “component” library is something that maps symbols (from a symbol library) and footprints (from a footprint library) into a third library, in much the same was as Altium does with their Integrated libraries. Yes, it is for Eagle (although components, footprints and symbols were all saved in the same file when I last used Eagle, but still during the schematic and PCB design phase you only interact with components) and I guess that's what Eldar tried to achieve too. If you place a component in a schematic, it shows the symbol linked from it, and stores the information of available footprints to be used when you create a PCB from the schematic. A given component should have exactly ONE available footprint. If your opamp comes in PDIP-8 and SOIC-8, those are two different components. Why? There's a good point for the opposite: Making different PCBs (SMD for series production/no SMD for prototyping/hobbyists or different casings) from a single - consistent - schematic. Otherwise you are going to run into trouble because you'll have multiple schematics of the same system and you need to change something on the logical (schematic) side. Maybe the hobbyist will do a through-hole prototype and then an SMD version for “production,” but here in the real world, we never do that. Really. It just doesn’t happen. Stuffing boards with SMD parts is a solved problem. And, as Chris Pavlina has noted in a reply on this thread, it’s folly to assume that a part that is available in different packages has the same pinout for all of those packages. LT1371, for example, has an 20-pin wide SO package in addition to two 7-pin packages (TO-220 and DDR). Of course the different variants of a single component would also need different BOM numbers, different 3D models etc. and stuff like the BOM needs to be generated from the PCB, not from the schematic, in this use case. Right, and that argues AGAINST having one schematic for wildly-different implementations. It’s bad enough trying to keep track of stuffing options, which only affect the BOM and assembly, but to add in the option for a different PCB with different footprints? That’s a new design. If you place a component on a PCB, it shows one of the footprints it links to (or a selection dialogue). Here’s a question: why would you place a component on a PCB? That component has no connectivity information, and Kicad won’t (and IMHO, shouldn’t) let you edit the netlist in pcbnew. (How should it regenerate the schematic when you do that?) 1) For very simple layouts, you may not need a schematic at all, but need a PCB file for manufacturing the board, so you just place the components and draw lines for tracks. If the layout is that simple, shouldn’t drawing the schematic be equally simple? How hard is it, really? 2) Other software (and maybe also kicad someday?) can do back-annotation, i.e. netlist editing from the PCB editor. That's where adding a component on a PCB really comes into play (and deleting is still more relevant than adding) So let’s say you are doing your layout and you add an inverting op-amp circuit, so you need the op-amp, two resistors, and maybe two decoupling caps. You add the parts to the artwork, then you edit the netlist to connect those parts, and then you add values to the resistors and capacitors. Now to back-annotate to the schematic. Imagine what kind of mess will be made of the schematic when you do that. How is the back-annotation thing supposed to know what looks best to the human? I mean, even in the “we need this feature” case where you are simply changing the connections to an FPGA by moving some traces around, the back-annotation would look like crap. And, seriously, that’s FASTER than just editing the schematic properly in the first place, regenerating and importing the netlist, then moving the parts to where the need to be and routing? It’s really just crazy. The only back-annotation I want to see is where once place and route is finished, you just tell the tools to renumber the reference designators in a geographical fashion and update the schematic with those new values. From the perspective of the user who considers each symbol to be a component (again, that is: embedded footprint,
Re: [Kicad-developers] Schematic Symbol Philosophy?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 06/08/2015 10:41 PM, Andy Peters wrote: On Jun 8, 2015, at 12:19 PM, Heiko Rosemann heiko.rosem...@web.de wrote: So you have a single canonical version of each footprint and symbol. No need to copy symbols for creating new components, no need to update or even touch all your OP-Amps when the one you based your symbol on shows a bug. Or in other words: It takes your library with a few of your favourite OP-Amps, each with the correct footprint embedded one step further: The components only link to symbols and footprints. OK, so this “component” library is something that maps symbols (from a symbol library) and footprints (from a footprint library) into a third library, in much the same was as Altium does with their Integrated libraries. Yes, it is for Eagle (although components, footprints and symbols were all saved in the same file when I last used Eagle, but still during the schematic and PCB design phase you only interact with components) and I guess that's what Eldar tried to achieve too. If you place a component in a schematic, it shows the symbol linked from it, and stores the information of available footprints to be used when you create a PCB from the schematic. A given component should have exactly ONE available footprint. If your opamp comes in PDIP-8 and SOIC-8, those are two different components. Why? There's a good point for the opposite: Making different PCBs (SMD for series production/no SMD for prototyping/hobbyists or different casings) from a single - consistent - schematic. Otherwise you are going to run into trouble because you'll have multiple schematics of the same system and you need to change something on the logical (schematic) side. Of course the different variants of a single component would also need different BOM numbers, different 3D models etc. and stuff like the BOM needs to be generated from the PCB, not from the schematic, in this use case. If you place a component on a PCB, it shows one of the footprints it links to (or a selection dialogue). Here’s a question: why would you place a component on a PCB? That component has no connectivity information, and Kicad won’t (and IMHO, shouldn’t) let you edit the netlist in pcbnew. (How should it regenerate the schematic when you do that?) 1) For very simple layouts, you may not need a schematic at all, but need a PCB file for manufacturing the board, so you just place the components and draw lines for tracks. 2) Other software (and maybe also kicad someday?) can do back-annotation, i.e. netlist editing from the PCB editor. That's where adding a component on a PCB really comes into play (and deleting is still more relevant than adding) So I see what you’re saying … the “symbol” library should contain symbols only, and have no connection to a footprint, and you need a component library to map a symbol with a footprint (and a 3D model, and a custom part number for the BOM). The engineer doing the design interacts only with the component library; only the librarian needs to be concerned with the symbol and the footprint libraries. Gotcha. True, the big advantage would be on the librarian's side - much easier to keep all the components correct and on the same up-to-date symbol and footprint set when you only have to do pin-to-pad mappings instead of copying/drawing symbols. Imagine just 20 OP-Amps, and then for some reason you (or your customers) want a different font size in the schematic - in a non-component-embedded-footprint-symbol approach you'd need to touch every single symbol, in a component-as-symbol-footprint-pin-pad-mapping approach there's only one file to touch: The OP-Amp symbol. From the perspective of the user who considers each symbol to be a component (again, that is: embedded footprint, embedded custom part number, different symbols for TL072ACD and TL072ACP) and ignores the CvPCB crap, there’s not much benefit to a separate component library. That is especially true given the inability to edit a netlist in pcbnew. If there was a library for every part the user would ever want to use, that would be true. I have yet to meet a PCB designer who never created any library components (as in: Choosing symbol, footprint, doing pin association) though... But this topic has crept up on this list about every other year (I'd say) and nobody (me included) is putting any coding effort (or similar contribution to kicad) behind it, so we might as well drop the conversation here - I just wanted to drop in because I felt you and Eldar weren't really discussing the same thing ;) Good night from Germany, Heiko - -- Mein PGP-Key zur Verifizierung: http://pgp.mit.edu -BEGIN PGP SIGNATURE- Version: GnuPG v2 iEYEARECAAYFAlV2COgACgkQ/Vb5NagElAUL4gCgoAWeazdFoUnB85HN/aQ20EYb WRwAoI1ZsTrhAR0qlu14e2fpHoqc6y/A =b0yI -END PGP SIGNATURE- ___ Mailing list:
Re: [Kicad-developers] Schematic Symbol Philosophy?
Hi folks! This is just to say my original question has been answered quite a few replies up, which was that KiCad still supports both philosophies, and the library team is going this way. Thanks everyone! I'm certain there's a bunch more discussion we can do on this, but I'm glad I got the clarification from Wayne that I did. Adam Wolf On Mon, Jun 8, 2015 at 11:42 AM, Andy Peters de...@latke.net wrote: On Jun 7, 2015, at 1:33 AM, Eldar Khayrullin eldar.khayrul...@mail.ru wrote: What problem is this trying to solve? No copy sch symbols, no copy pcb footprints, more ready parts with same sch symbol and footprint, but different pins assignment. I still don’t understand why you think there are problems. Let’s talk op-amps for the moment. Does your schematic library have a generic op-amp which you place on every design? Do you then go into the schematic and modify the symbol you placed so that it calls out TL072 and the correct unit, and then do you go in and also add the desired footprint? If so, for the love of G-d, WHY? That is a recipe for disaster. Why not just have in your library a few of your favorite op-amps: TL072ACD, OPA2134UA, OP275GSZ. Note the symbol names, which are the vendor part numbers and as such have the footprint encoded into them. And, each symbol has the correct footprint embedded in it. Do you consider this “unnecessary duplication” in that each of these dual op-amps has the same symbol and uses the same footprint (SOIC-8)? It is MUCH harder to make an expensive mistake if the symbol — the “component” — is “complete,” in that it has the correct pin-out which matches the footprint. Your suggestion of a components library” solves a problem which doesn’t actually exist. -a ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
[Kicad-developers] How to handle mounting holes with satellite vias?
Having troubles getting an useable workflow with a common usage: the mounting hole with satellite vias (see attachment). Rationale: when you have a big hole for a screw and need to have plane connectivity, a PTH supported pad is often not a good choice. Mostly because on the wave solder machine they tend to get clogged (requiring an expensive peel mask). There are other reason, like ground plane impedance, but manufacturing convenience is the biggest one :P So I did the following thing: (module HOLE-M4-NPTH (layer F.Cu) (tedit 557548BB) (descr Mechanical Hole, M4) (attr virtual) (fp_text reference HOLE-M4-NPTH (at 0 0) (layer F.Fab) (effects (font (size 1.2 1.2) (thickness 0.12 (fp_text value HOLE-M4-NPTH (at 0 0) (layer F.Fab) hide (effects (font (size 1.2 1.2) (thickness 0.12 (fp_circle (center 0 0) (end 5.85 0) (layer F.CrtYd) (width 0.01)) (fp_circle (center 0 0) (end 5.85 0) (layer B.CrtYd) (width 0.01)) (fp_circle (center 0 0) (end 5.5 0) (layer F.SilkS) (width 0.12)) (fp_circle (center 0 0) (end 2.2 0) (layer F.Fab) (width 0.12)) (fp_circle (center 0 0) (end 2.2 0) (layer B.Fab) (width 0.12)) (fp_circle (center 0 0) (end 2.2 0) (layer Dwgs.User) (width 0.12)) (pad np_thru_hole circle (at 0 0) (size 4.4 4.4) (drill 4.4) (layers *.Cu)) (pad HOLE smd circle (at 0 0) (size 8.35 8.35) (layers *.Cu)) (pad HOLE thru_hole circle (at 3.2 0) (size 0.8 0.8) (drill 0.4) (layers *.Cu) (zone_connect 2)) (pad HOLE thru_hole circle (at -3.2 0) (size 0.8 0.8) (drill 0.4) (layers *.Cu) (zone_connect 2)) (pad HOLE thru_hole circle (at 1.6 -2.8) (size 0.8 0.8) (drill 0.4) (layers *.Cu) (zone_connect 2)) (pad HOLE thru_hole circle (at -1.6 -2.8) (size 0.8 0.8) (drill 0.4) (layers *.Cu) (zone_connect 2)) (pad HOLE thru_hole circle (at -1.6 2.8) (size 0.8 0.8) (drill 0.4) (layers *.Cu) (zone_connect 2)) (pad HOLE thru_hole circle (at 1.6 2.8) (size 0.8 0.8) (drill 0.4) (layers *.Cu) (zone_connect 2))) I have a big SMD round pad on all layers for the support copper, an NPTH hole for the drill tape, and common pads for the satellite vias. The zone_connect forces solid fill, not that it would have really mattered (since there is the big pad covering all). Less cruft in the gerbers... Problem #1: pad snap always pick the big SMD pad and the track get rejected because it falls into the NPTH hole; workaround: disable pad snap and locate it by hands. Not a big issue since usually these are tied to fills and they attach correctly. Problem #2: the big pad and the NPTH hole are conflicting in the DRC (quite correctly, in theory). However that's a PITA because the message can 'obscure' more severe errors. Any idea on how to solve this? -- Lorenzo Marcantonio Logos Srl ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
Re: [Kicad-developers] How to handle mounting holes with satellite vias?
On 08.06.2015 12:24, Cirilo Bernardo wrote: One method which comes to mind is to add yet another hole definition in software, and that may be the best way to address the problem; this way we can also ensure the correct thickness of the annulus and check the chosen number/size of vias. There is another way: don't use a pad to simulate a via. Letting vias retain their nets (or - in case of footprints - follow the connectivity starting from pads) is IMHO a way to fix this and many other issues (thermal via fields, etc.) Tom - Cirilo On Mon, Jun 8, 2015 at 5:59 PM, Lorenzo Marcantonio l.marcanto...@logossrl.com mailto:l.marcanto...@logossrl.com wrote: Having troubles getting an useable workflow with a common usage: the mounting hole with satellite vias (see attachment). Rationale: when you have a big hole for a screw and need to have plane connectivity, a PTH supported pad is often not a good choice. Mostly because on the wave solder machine they tend to get clogged (requiring an expensive peel mask). There are other reason, like ground plane impedance, but manufacturing convenience is the biggest one :P So I did the following thing: (module HOLE-M4-NPTH (layer F.Cu) (tedit 557548BB) (descr Mechanical Hole, M4) (attr virtual) (fp_text reference HOLE-M4-NPTH (at 0 0) (layer F.Fab) (effects (font (size 1.2 1.2) (thickness 0.12 (fp_text value HOLE-M4-NPTH (at 0 0) (layer F.Fab) hide (effects (font (size 1.2 1.2) (thickness 0.12 (fp_circle (center 0 0) (end 5.85 0) (layer F.CrtYd) (width 0.01)) (fp_circle (center 0 0) (end 5.85 0) (layer B.CrtYd) (width 0.01)) (fp_circle (center 0 0) (end 5.5 0) (layer F.SilkS) (width 0.12)) (fp_circle (center 0 0) (end 2.2 0) (layer F.Fab) (width 0.12)) (fp_circle (center 0 0) (end 2.2 0) (layer B.Fab) (width 0.12)) (fp_circle (center 0 0) (end 2.2 0) (layer Dwgs.User) (width 0.12)) (pad np_thru_hole circle (at 0 0) (size 4.4 4.4) (drill 4.4) (layers *.Cu)) (pad HOLE smd circle (at 0 0) (size 8.35 8.35) (layers *.Cu)) (pad HOLE thru_hole circle (at 3.2 0) (size 0.8 0.8) (drill 0.4) (layers *.Cu) (zone_connect 2)) (pad HOLE thru_hole circle (at -3.2 0) (size 0.8 0.8) (drill 0.4) (layers *.Cu) (zone_connect 2)) (pad HOLE thru_hole circle (at 1.6 -2.8) (size 0.8 0.8) (drill 0.4) (layers *.Cu) (zone_connect 2)) (pad HOLE thru_hole circle (at -1.6 -2.8) (size 0.8 0.8) (drill 0.4) (layers *.Cu) (zone_connect 2)) (pad HOLE thru_hole circle (at -1.6 2.8) (size 0.8 0.8) (drill 0.4) (layers *.Cu) (zone_connect 2)) (pad HOLE thru_hole circle (at 1.6 2.8) (size 0.8 0.8) (drill 0.4) (layers *.Cu) (zone_connect 2))) I have a big SMD round pad on all layers for the support copper, an NPTH hole for the drill tape, and common pads for the satellite vias. The zone_connect forces solid fill, not that it would have really mattered (since there is the big pad covering all). Less cruft in the gerbers... Problem #1: pad snap always pick the big SMD pad and the track get rejected because it falls into the NPTH hole; workaround: disable pad snap and locate it by hands. Not a big issue since usually these are tied to fills and they attach correctly. Problem #2: the big pad and the NPTH hole are conflicting in the DRC (quite correctly, in theory). However that's a PITA because the message can 'obscure' more severe errors. Any idea on how to solve this? -- Lorenzo Marcantonio Logos Srl ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net mailto:kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
Re: [Kicad-developers] CvPcb change.
In response to a message written on 07.06.2015, 20:20, from Wayne Stambaugh: I just committed a patch (r5718) from Dick that should greatly simplify the process of footprint assignment using cvpcb. This patch does away with using the intermediate *.cmp file and directly updates the s-expr netlist via kiway express messaging. This means there is no more stand alone executable of cvpcb. This also means that you will have to use the s-expr netlist when importing in pcbnew. If you do not normally back import the footprint assignments from the *.cmp file into eeschema, you will have to do this before your run cvpcb because the s-expr netlist will not contain the footprint assignments until you do this. This patch will eliminate one more unnecessary step when assigning footprints and streamline the process. I still need to fix the save tooltip in the cvpcb toolbar since the *.cmp file does not get saved. I also need to remove the read footprints from *.cmp file in the pcbnew import netlist dialog since the *.cmp can no longer be generated by cvpcb. Going forward, the *.cmp file will only be useful for back importing from pcbnew to eeschema. At some point in the future, even that will go away.j Please test this and let me know if you find any issues. It's nice message, but sth missed… In CMakeList.txt:769 not existing target „cvpcb” also should be renamed to „cvpcb_kiface”. -- Best Regards, LordBlick ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
Re: [Kicad-developers] How to handle mounting holes with satellite vias?
One method which comes to mind is to add yet another hole definition in software, and that may be the best way to address the problem; this way we can also ensure the correct thickness of the annulus and check the chosen number/size of vias. - Cirilo On Mon, Jun 8, 2015 at 5:59 PM, Lorenzo Marcantonio l.marcanto...@logossrl.com wrote: Having troubles getting an useable workflow with a common usage: the mounting hole with satellite vias (see attachment). Rationale: when you have a big hole for a screw and need to have plane connectivity, a PTH supported pad is often not a good choice. Mostly because on the wave solder machine they tend to get clogged (requiring an expensive peel mask). There are other reason, like ground plane impedance, but manufacturing convenience is the biggest one :P So I did the following thing: (module HOLE-M4-NPTH (layer F.Cu) (tedit 557548BB) (descr Mechanical Hole, M4) (attr virtual) (fp_text reference HOLE-M4-NPTH (at 0 0) (layer F.Fab) (effects (font (size 1.2 1.2) (thickness 0.12 (fp_text value HOLE-M4-NPTH (at 0 0) (layer F.Fab) hide (effects (font (size 1.2 1.2) (thickness 0.12 (fp_circle (center 0 0) (end 5.85 0) (layer F.CrtYd) (width 0.01)) (fp_circle (center 0 0) (end 5.85 0) (layer B.CrtYd) (width 0.01)) (fp_circle (center 0 0) (end 5.5 0) (layer F.SilkS) (width 0.12)) (fp_circle (center 0 0) (end 2.2 0) (layer F.Fab) (width 0.12)) (fp_circle (center 0 0) (end 2.2 0) (layer B.Fab) (width 0.12)) (fp_circle (center 0 0) (end 2.2 0) (layer Dwgs.User) (width 0.12)) (pad np_thru_hole circle (at 0 0) (size 4.4 4.4) (drill 4.4) (layers *.Cu)) (pad HOLE smd circle (at 0 0) (size 8.35 8.35) (layers *.Cu)) (pad HOLE thru_hole circle (at 3.2 0) (size 0.8 0.8) (drill 0.4) (layers *.Cu) (zone_connect 2)) (pad HOLE thru_hole circle (at -3.2 0) (size 0.8 0.8) (drill 0.4) (layers *.Cu) (zone_connect 2)) (pad HOLE thru_hole circle (at 1.6 -2.8) (size 0.8 0.8) (drill 0.4) (layers *.Cu) (zone_connect 2)) (pad HOLE thru_hole circle (at -1.6 -2.8) (size 0.8 0.8) (drill 0.4) (layers *.Cu) (zone_connect 2)) (pad HOLE thru_hole circle (at -1.6 2.8) (size 0.8 0.8) (drill 0.4) (layers *.Cu) (zone_connect 2)) (pad HOLE thru_hole circle (at 1.6 2.8) (size 0.8 0.8) (drill 0.4) (layers *.Cu) (zone_connect 2))) I have a big SMD round pad on all layers for the support copper, an NPTH hole for the drill tape, and common pads for the satellite vias. The zone_connect forces solid fill, not that it would have really mattered (since there is the big pad covering all). Less cruft in the gerbers... Problem #1: pad snap always pick the big SMD pad and the track get rejected because it falls into the NPTH hole; workaround: disable pad snap and locate it by hands. Not a big issue since usually these are tied to fills and they attach correctly. Problem #2: the big pad and the NPTH hole are conflicting in the DRC (quite correctly, in theory). However that's a PITA because the message can 'obscure' more severe errors. Any idea on how to solve this? -- Lorenzo Marcantonio Logos Srl ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
Re: [Kicad-developers] How to handle mounting holes with satellite vias?
On Mon, Jun 08, 2015 at 01:15:39PM +0200, Tomasz Wlostowski wrote: There is another way: don't use a pad to simulate a via. Letting vias retain their nets (or - in case of footprints - follow the connectivity starting from pads) is IMHO a way to fix this and many other issues (thermal via fields, etc.) The main problem is another way: the NPTH conflicts with the main pad; I don't really care about the vias (since they don't harm DRC) Maybe special-casing hole in the same module could be a solution, if you trust people do to correct modules... -- Lorenzo Marcantonio Logos Srl ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
Re: [Kicad-developers] How to handle mounting holes with satellite vias?
In response to a message written on 08.06.2015, 14:37, from Lorenzo Marcantonio: On Mon, Jun 08, 2015 at 01:15:39PM +0200, Tomasz Wlostowski wrote: There is another way: don't use a pad to simulate a via. Letting vias retain their nets (or - in case of footprints - follow the connectivity starting from pads) is IMHO a way to fix this and many other issues (thermal via fields, etc.) The main problem is another way: the NPTH conflicts with the main pad; I don't really care about the vias (since they don't harm DRC) Maybe special-casing hole in the same module could be a solution, if you trust people do to correct modules... IMHO, there is no any obstacles, that NPTH pads can have some net, only last wall is in peoples minds… ;) -- Best Regards, LordBlick ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
Re: [Kicad-developers] [PATCH] compile broken on clang - overload conflict
Nope, using a by-reference parameter does not appease clang; no idea about MSVC. On Mon, Jun 08, 2015 at 09:15:16AM -0400, Wayne Stambaugh wrote: On 6/8/2015 8:58 AM, Chris Pavlina wrote: It can't and it shouldn't - gcc is the one at fault here. wxString provides the constructor: wxString(char ch, size_t nRepeat=1) which is the one in question, I believe, as the integer literal can also represent a character. Using a reference should work too, though changing the name is a more common solution (and better IMHO) particularly considering the two methods do provide slightly different functions. I would think that searching a list with a string vs. an index is pretty self explanatory but maybe I've been doing this too long :) Apparently MSVC won't compile it either. On Mon, Jun 08, 2015 at 08:50:15AM -0400, Wayne Stambaugh wrote: Really! Clang can't differentiate between SCH_SHEET_LIST::GetSheet(const wxString, bool); and SCH_SHEET_LIST::GetSheet(int); How can these two definitions be ambiguous? Does using a reference to the wxString instead of passing the entire string on the stack fix the problem? If so, I would prefer that fix. On 6/7/2015 9:17 PM, Chris Pavlina wrote: 5720 broke the build on clang by making SCH_SHEET_LIST::GetSheet(int) a const method, which changed the overload resolution order and resulted in failure due to ambiguity. This patch ranames SCH_SHEET_LIST::GetSheet(const wxString, bool) to ::GetSheetByPath to resolve that conflict. -- Chris ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
Re: [Kicad-developers] How to handle mounting holes with satellite vias?
On Mon, Jun 08, 2015 at 02:57:46PM +0200, LordBlick wrote: IMHO, there is no any obstacles, that NPTH pads can have some net, only last wall is in peoples minds… ;) There *are* issues having a net attached to an NPTH, at least last time I checked (i.e. when they where added). pcbnew has no handling for holes which don't connect planes, that's the biggest one :D At the time I pondered a lot about it and I were with the 'no net to NPTH pads' peoples. -- Lorenzo Marcantonio Logos Srl ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
Re: [Kicad-developers] [PATCH] compile broken on clang - overload conflict
One is a search and the other is a direct access by index. It's an academic discussion anyway - as long as the conflict is resolved somehow so that kicad compiling doesn't depend on a gcc quirk, I'm happy. On Mon, Jun 08, 2015 at 09:15:16AM -0400, Wayne Stambaugh wrote: On 6/8/2015 8:58 AM, Chris Pavlina wrote: It can't and it shouldn't - gcc is the one at fault here. wxString provides the constructor: wxString(char ch, size_t nRepeat=1) which is the one in question, I believe, as the integer literal can also represent a character. Using a reference should work too, though changing the name is a more common solution (and better IMHO) particularly considering the two methods do provide slightly different functions. I would think that searching a list with a string vs. an index is pretty self explanatory but maybe I've been doing this too long :) Apparently MSVC won't compile it either. On Mon, Jun 08, 2015 at 08:50:15AM -0400, Wayne Stambaugh wrote: Really! Clang can't differentiate between SCH_SHEET_LIST::GetSheet(const wxString, bool); and SCH_SHEET_LIST::GetSheet(int); How can these two definitions be ambiguous? Does using a reference to the wxString instead of passing the entire string on the stack fix the problem? If so, I would prefer that fix. On 6/7/2015 9:17 PM, Chris Pavlina wrote: 5720 broke the build on clang by making SCH_SHEET_LIST::GetSheet(int) a const method, which changed the overload resolution order and resulted in failure due to ambiguity. This patch ranames SCH_SHEET_LIST::GetSheet(const wxString, bool) to ::GetSheetByPath to resolve that conflict. -- Chris ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
Re: [Kicad-developers] How to handle mounting holes with satellite vias?
I use this workaround ... I manually added net number to the NPTH drill pad (with notepad)... please find attached the pcb module then you can use this module inside a library (import without editing and save lib) and it is possible to wire tracks and there is no DRC violations... maybe to solve this prob in a clean way it could be nice to add the option to have pin nbr also for NPTH drill pad... Regards Maurice On 08/06/2015 14.37, Lorenzo Marcantonio wrote: On Mon, Jun 08, 2015 at 01:15:39PM +0200, Tomasz Wlostowski wrote: There is another way: don't use a pad to simulate a via. Letting vias retain their nets (or - in case of footprints - follow the connectivity starting from pads) is IMHO a way to fix this and many other issues (thermal via fields, etc.) The main problem is another way: the NPTH conflicts with the main pad; I don't really care about the vias (since they don't harm DRC) Maybe special-casing hole in the same module could be a solution, if you trust people do to correct modules... (module a_ANCHORS:1pinD35-NPTH-drilled (layer F.Cu) (tedit 55758F44) (fp_text reference J*** (at 0 -4.699) (layer F.SilkS) hide (effects (font (size 1.00076 1.00076) (thickness 0.2032))) ) (fp_text value anchor (at 0 4.953) (layer F.SilkS) hide (effects (font (size 1.00076 1.00076) (thickness 0.2032))) ) (fp_circle (center 0 0) (end 0 1.6764) (layer B.SilkS) (width 0.16)) (fp_circle (center 0 0) (end -0.0254 1.6764) (layer F.SilkS) (width 0.16)) (fp_circle (center 0 0) (end 0 3.556) (layer B.SilkS) (width 0.16)) (fp_circle (center 0 0) (end 0 3.556) (layer F.SilkS) (width 0.16)) (pad 1 thru_hole circle (at 0 -2.2606) (size 0.6 0.6) (drill 0.381) (layers *.Cu *.Mask)) (pad 1 thru_hole circle (at -2.2606 0) (size 0.6 0.6) (drill 0.381) (layers *.Cu *.Mask)) (pad 1 thru_hole circle (at 0 2.2606) (size 0.6 0.6) (drill 0.381) (layers *.Cu *.Mask)) (pad 1 thru_hole circle (at 2.2606 0) (size 0.6 0.6) (drill 0.381) (layers *.Cu *.Mask)) (pad 1 thru_hole circle (at 1.6002 -1.6002) (size 0.6 0.6) (drill 0.381) (layers *.Cu *.Mask)) (pad 1 thru_hole circle (at -1.6002 -1.6002) (size 0.6 0.6) (drill 0.381) (layers *.Cu *.Mask)) (pad 1 thru_hole circle (at -1.6002 1.6002) (size 0.6 0.6) (drill 0.381) (layers *.Cu *.Mask)) (pad 1 thru_hole circle (at 1.6002 1.6002) (size 0.6 0.6) (drill 0.381) (layers *.Cu *.Mask)) (pad 1 np_thru_hole circle (at 0 0) (size 3.5 3.5) (drill 3.5) (layers *.Cu *.Mask F.SilkS)) (pad 1 smd circle (at 0 0) (size 5.6 5.6) (layers F.Cu F.SilkS F.Mask)) (pad 1 smd circle (at 0 0) (size 5.6 5.6) (layers B.Cu B.SilkS B.Mask)) ) ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
Re: [Kicad-developers] [PATCH] compile broken on clang - overload conflict
It can't and it shouldn't - gcc is the one at fault here. wxString provides the constructor: wxString(char ch, size_t nRepeat=1) which is the one in question, I believe, as the integer literal can also represent a character. Using a reference should work too, though changing the name is a more common solution (and better IMHO) particularly considering the two methods do provide slightly different functions. Apparently MSVC won't compile it either. On Mon, Jun 08, 2015 at 08:50:15AM -0400, Wayne Stambaugh wrote: Really! Clang can't differentiate between SCH_SHEET_LIST::GetSheet(const wxString, bool); and SCH_SHEET_LIST::GetSheet(int); How can these two definitions be ambiguous? Does using a reference to the wxString instead of passing the entire string on the stack fix the problem? If so, I would prefer that fix. On 6/7/2015 9:17 PM, Chris Pavlina wrote: 5720 broke the build on clang by making SCH_SHEET_LIST::GetSheet(int) a const method, which changed the overload resolution order and resulted in failure due to ambiguity. This patch ranames SCH_SHEET_LIST::GetSheet(const wxString, bool) to ::GetSheetByPath to resolve that conflict. -- Chris ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
Re: [Kicad-developers] [PATCH] Hide pin targets when properly connected
Also keep in mind that the standard is pay-to-access. That's not fit for an open-source project. I rather suspect it would be frowned upon if we were to buy a copy and then put it into the documentation for all to access - and if we don't, how can we follow it? Forget the damn standard. Make our own, if need be. On Mon, Jun 08, 2015 at 08:58:50AM -0400, Wayne Stambaugh wrote: Let's not get too hung up on EN60617-3. I really don't care if KiCad is compliant to some standard other than exporting to third party file formats. What I do care about is the user experience. If the goal is to make it obvious to the user (IMO a good thing) that a schematic connection is or is not made, then I would rather do what makes the best user experience rather than follow some standard generated by government body and/or committee. On 6/8/2015 8:25 AM, Chris Pavlina wrote: 60617-3 allows a dotless junction (as in 03-02-06), but the same connection can be represented with two 03-02-05; it is not a violation of the standard to always use dots. On Mon, Jun 08, 2015 at 08:48:12AM +0300, Vesa Solonen wrote: 08/06/15, 00:44, Wayne Stambaugh kirjoitti: One thing I did notice is that bus entries do not draw the connection point so they cannot show their connection status. It would be nice if bus entries exhibited the same behavior. I'm not sure how much work would be involved. I'm surprised I never noticed that before or AFAIR no one has every said anything about it. Are you guys aware that to support both options in EN 60617-3 (1997) [symbols 03-02-04 to 03-02-07] the connection point must only be drawn when the connection is in crossing or identical branching [symbol 03-02-09] wires/buses? Otherwise it should be an user configurable option. Maybe Kicad could use the same end-centered ring hint for all open connections in addition to pins, also while drawing wires and buses. -Vesa ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
Re: [Kicad-developers] [PATCH] Hide pin targets when properly connected
60617-3 allows a dotless junction (as in 03-02-06), but the same connection can be represented with two 03-02-05; it is not a violation of the standard to always use dots. On Mon, Jun 08, 2015 at 08:48:12AM +0300, Vesa Solonen wrote: 08/06/15, 00:44, Wayne Stambaugh kirjoitti: One thing I did notice is that bus entries do not draw the connection point so they cannot show their connection status. It would be nice if bus entries exhibited the same behavior. I'm not sure how much work would be involved. I'm surprised I never noticed that before or AFAIR no one has every said anything about it. Are you guys aware that to support both options in EN 60617-3 (1997) [symbols 03-02-04 to 03-02-07] the connection point must only be drawn when the connection is in crossing or identical branching [symbol 03-02-09] wires/buses? Otherwise it should be an user configurable option. Maybe Kicad could use the same end-centered ring hint for all open connections in addition to pins, also while drawing wires and buses. -Vesa ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
Re: [Kicad-developers] [PATCH] compile broken on clang - overload conflict
Really! Clang can't differentiate between SCH_SHEET_LIST::GetSheet(const wxString, bool); and SCH_SHEET_LIST::GetSheet(int); How can these two definitions be ambiguous? Does using a reference to the wxString instead of passing the entire string on the stack fix the problem? If so, I would prefer that fix. On 6/7/2015 9:17 PM, Chris Pavlina wrote: 5720 broke the build on clang by making SCH_SHEET_LIST::GetSheet(int) a const method, which changed the overload resolution order and resulted in failure due to ambiguity. This patch ranames SCH_SHEET_LIST::GetSheet(const wxString, bool) to ::GetSheetByPath to resolve that conflict. -- Chris ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
Re: [Kicad-developers] [PATCH] compile broken on clang - overload conflict
On 6/8/2015 8:58 AM, Chris Pavlina wrote: It can't and it shouldn't - gcc is the one at fault here. wxString provides the constructor: wxString(char ch, size_t nRepeat=1) which is the one in question, I believe, as the integer literal can also represent a character. Using a reference should work too, though changing the name is a more common solution (and better IMHO) particularly considering the two methods do provide slightly different functions. I would think that searching a list with a string vs. an index is pretty self explanatory but maybe I've been doing this too long :) Apparently MSVC won't compile it either. On Mon, Jun 08, 2015 at 08:50:15AM -0400, Wayne Stambaugh wrote: Really! Clang can't differentiate between SCH_SHEET_LIST::GetSheet(const wxString, bool); and SCH_SHEET_LIST::GetSheet(int); How can these two definitions be ambiguous? Does using a reference to the wxString instead of passing the entire string on the stack fix the problem? If so, I would prefer that fix. On 6/7/2015 9:17 PM, Chris Pavlina wrote: 5720 broke the build on clang by making SCH_SHEET_LIST::GetSheet(int) a const method, which changed the overload resolution order and resulted in failure due to ambiguity. This patch ranames SCH_SHEET_LIST::GetSheet(const wxString, bool) to ::GetSheetByPath to resolve that conflict. -- Chris ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
Re: [Kicad-developers] [PATCH] Hide pin targets when properly connected
Let's not get too hung up on EN60617-3. I really don't care if KiCad is compliant to some standard other than exporting to third party file formats. What I do care about is the user experience. If the goal is to make it obvious to the user (IMO a good thing) that a schematic connection is or is not made, then I would rather do what makes the best user experience rather than follow some standard generated by government body and/or committee. On 6/8/2015 8:25 AM, Chris Pavlina wrote: 60617-3 allows a dotless junction (as in 03-02-06), but the same connection can be represented with two 03-02-05; it is not a violation of the standard to always use dots. On Mon, Jun 08, 2015 at 08:48:12AM +0300, Vesa Solonen wrote: 08/06/15, 00:44, Wayne Stambaugh kirjoitti: One thing I did notice is that bus entries do not draw the connection point so they cannot show their connection status. It would be nice if bus entries exhibited the same behavior. I'm not sure how much work would be involved. I'm surprised I never noticed that before or AFAIR no one has every said anything about it. Are you guys aware that to support both options in EN 60617-3 (1997) [symbols 03-02-04 to 03-02-07] the connection point must only be drawn when the connection is in crossing or identical branching [symbol 03-02-09] wires/buses? Otherwise it should be an user configurable option. Maybe Kicad could use the same end-centered ring hint for all open connections in addition to pins, also while drawing wires and buses. -Vesa ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
Re: [Kicad-developers] [PATCH] Hide pin targets when properly connected
Yes, but we are not a small group, we are everybody who can contribute. How can an open source project implement/follow a standard when it can't make that standard available to its contributors? On Mon, Jun 08, 2015 at 05:34:46PM +0300, Vesa Solonen wrote: I generally agree with both of you, but if Kicad wants to be a serious tool for documentation it has to support EN60617 pretty well. No company can use it for official documentation and certainly some one guy design offices will lose bids if they can not fullfill customer requirement of EN60617 compliant schematics... It certainly will be frowned upon if we copied the standard, but making a component library or software functionality according to one is certainly not copying, but implementing the standard. I havent read the fine print regarding implementation fee, but somehow I suspect every screw made to DIN913 has to pay either. -Vesa ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
Re: [Kicad-developers] [PATCH] Hide pin targets when properly connected
08/06/15, 17:54, Chris Pavlina kirjoitti: Yes, but we are not a small group, we are everybody who can contribute. How can an open source project implement/follow a standard when it can't make that standard available to its contributors? On Mon, Jun 08, 2015 at 05:34:46PM +0300, Vesa Solonen wrote: I generally agree with both of you, but if Kicad wants to be a serious tool for documentation it has to support EN60617 pretty well. No company can use it for official documentation and certainly some one guy design offices will lose bids if they can not fullfill customer requirement of EN60617 compliant schematics... It certainly will be frowned upon if we copied the standard, but making a component library or software functionality according to one is certainly not copying, but implementing the standard. I havent read the fine print regarding implementation fee, but somehow I suspect every screw made to DIN913 has to pay either. -Vesa I don't have an ideal solution to this. The whole industry section mindset has to change to make it. Last time we did something similar went somewhat as follows. The ones who had the access to the standard described the contents in their own words for the exact parts needed. The gaps were filled from various sources and the implementation of details from the ones who had the standard. Regarding availability I would suggest visiting some technical university library and ask from there. Here in Finland standards are available for reading at the spot, but not for loan. Somewhat annopying to go there sitting with a laptop for a day, but at least possible. -Vesa ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
Re: [Kicad-developers] [PATCH] Hide pin targets when properly connected
08/06/15, 16:06, Chris Pavlina kirjoitti: Also keep in mind that the standard is pay-to-access. That's not fit for an open-source project. I rather suspect it would be frowned upon if we were to buy a copy and then put it into the documentation for all to access - and if we don't, how can we follow it? Forget the damn standard. Make our own, if need be. On Mon, Jun 08, 2015 at 08:58:50AM -0400, Wayne Stambaugh wrote: Let's not get too hung up on EN60617-3. I really don't care if KiCad is compliant to some standard other than exporting to third party file formats. What I do care about is the user experience. If the goal is to make it obvious to the user (IMO a good thing) that a schematic connection is or is not made, then I would rather do what makes the best user experience rather than follow some standard generated by government body and/or committee. On 6/8/2015 8:25 AM, Chris Pavlina wrote: 60617-3 allows a dotless junction (as in 03-02-06), but the same connection can be represented with two 03-02-05; it is not a violation of the standard to always use dots. I generally agree with both of you, but if Kicad wants to be a serious tool for documentation it has to support EN60617 pretty well. No company can use it for official documentation and certainly some one guy design offices will lose bids if they can not fullfill customer requirement of EN60617 compliant schematics... It certainly will be frowned upon if we copied the standard, but making a component library or software functionality according to one is certainly not copying, but implementing the standard. I havent read the fine print regarding implementation fee, but somehow I suspect every screw made to DIN913 has to pay either. -Vesa ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
Re: [Kicad-developers] [PATCH] compile broken on clang - overload conflict
GCC was still generating a warning using the reference as well so I applied your patch in r5722. Thanks, Wayne On 6/8/2015 10:08 AM, Chris Pavlina wrote: Nope, using a by-reference parameter does not appease clang; no idea about MSVC. On Mon, Jun 08, 2015 at 09:15:16AM -0400, Wayne Stambaugh wrote: On 6/8/2015 8:58 AM, Chris Pavlina wrote: It can't and it shouldn't - gcc is the one at fault here. wxString provides the constructor: wxString(char ch, size_t nRepeat=1) which is the one in question, I believe, as the integer literal can also represent a character. Using a reference should work too, though changing the name is a more common solution (and better IMHO) particularly considering the two methods do provide slightly different functions. I would think that searching a list with a string vs. an index is pretty self explanatory but maybe I've been doing this too long :) Apparently MSVC won't compile it either. On Mon, Jun 08, 2015 at 08:50:15AM -0400, Wayne Stambaugh wrote: Really! Clang can't differentiate between SCH_SHEET_LIST::GetSheet(const wxString, bool); and SCH_SHEET_LIST::GetSheet(int); How can these two definitions be ambiguous? Does using a reference to the wxString instead of passing the entire string on the stack fix the problem? If so, I would prefer that fix. On 6/7/2015 9:17 PM, Chris Pavlina wrote: 5720 broke the build on clang by making SCH_SHEET_LIST::GetSheet(int) a const method, which changed the overload resolution order and resulted in failure due to ambiguity. This patch ranames SCH_SHEET_LIST::GetSheet(const wxString, bool) to ::GetSheetByPath to resolve that conflict. -- Chris ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
[Kicad-developers] 3D model generation.
Does anyone have a parametric 3D model generator script for two pin J lead components like SMD tantalum caps or SMD DO diode packages? I'm using some of the large SMD wire wound resistor packages (2515, 4527, etc.) in some of my designs and I was hoping there would be an easier way to create them rather than using Wings3D. Thanks, Wayne ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
Re: [Kicad-developers] 3D model generation.
08/06/15, 18:55, Wayne Stambaugh kirjoitti: Does anyone have a parametric 3D model generator script for two pin J lead components like SMD tantalum caps or SMD DO diode packages? I'm using some of the large SMD wire wound resistor packages (2515, 4527, etc.) in some of my designs and I was hoping there would be an easier way to create them rather than using Wings3D. Pretty close, but for old library format and Perl: http://bazaar.launchpad.net/~oyvind-aabling/kicad-newlib/mod/files -Vesa ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
Re: [Kicad-developers] Schematic Symbol Philosophy?
On Jun 7, 2015, at 1:33 AM, Eldar Khayrullin eldar.khayrul...@mail.ru wrote: What problem is this trying to solve? No copy sch symbols, no copy pcb footprints, more ready parts with same sch symbol and footprint, but different pins assignment. I still don’t understand why you think there are problems. Let’s talk op-amps for the moment. Does your schematic library have a generic op-amp which you place on every design? Do you then go into the schematic and modify the symbol you placed so that it calls out TL072 and the correct unit, and then do you go in and also add the desired footprint? If so, for the love of G-d, WHY? That is a recipe for disaster. Why not just have in your library a few of your favorite op-amps: TL072ACD, OPA2134UA, OP275GSZ. Note the symbol names, which are the vendor part numbers and as such have the footprint encoded into them. And, each symbol has the correct footprint embedded in it. Do you consider this “unnecessary duplication” in that each of these dual op-amps has the same symbol and uses the same footprint (SOIC-8)? It is MUCH harder to make an expensive mistake if the symbol — the “component” — is “complete,” in that it has the correct pin-out which matches the footprint. Your suggestion of a components library” solves a problem which doesn’t actually exist. -a ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
