Re: [Kicad-developers] Experiments and considerations for more layer
On Fri, Sep 06, 2013 at 06:46:16AM -0500, Dick Hollenbeck wrote: > Iteration and iteration only, was the topic of discussion with Tom. This was > a discussion > between Tom and me, only. Walking a linked list is a fast means of > iteration. I don't > know how hard that is to understand. A good software designer can > compartmentalize > his/her thinking. Not if the linked list contains stuff which certainly is not of any use (as an example the plotting layer scan was already given in the past). That was what I was referring to. If you mean 'everything on the board' then, sure, it was a misunderstanding of mine. > Anything else is a separate discussion, one I am not participating in because > I have > already participated in them, and led them. The whole partitioning into > layer datasets > was suggested by me to other lead developers ages ago, Tom in that set, and > is coming > about to a large extent because of those suggestions. Ok, then it was only a misunderstanding. Good. > > Lorenzo, I am temporarily suspending your commit rights to the testing > branch. In a > recent posting you made two threats to existing layer names in the pretty > footprint files > and in the UI. I'd rather do this on a temporary basis and review your patch > submissions Yes I think that the UI should have localized names. The footprint files can contain whatever they want (where I was suggesting to change them?) Also we are simply discussing what would the best feature set and the following implementation, I'm not proposing any concrete code (the only coding I've done is raising the count to 64, and that's in my private branch). Are we at a point where we can't even *suggest* things? -- 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] Experiments and considerations for more layer
On 09/05/2013 03:55 PM, Lorenzo Marcantonio wrote: > On Thu, Sep 05, 2013 at 02:14:03PM -0500, Dick Hollenbeck wrote: >> You are correct about the model being somewhat exposed. But the model is >> working nicely >> everywhere else, and it is fast. > > I could argue about the 'fast' thing. You have no problem arguing about anything. I am still digging your postings out of my spam folder, because I consider every one them another argument waiting to happen. Iteration and iteration only, was the topic of discussion with Tom. This was a discussion between Tom and me, only. Walking a linked list is a fast means of iteration. I don't know how hard that is to understand. A good software designer can compartmentalize his/her thinking. Anything else is a separate discussion, one I am not participating in because I have already participated in them, and led them. The whole partitioning into layer datasets was suggested by me to other lead developers ages ago, Tom in that set, and is coming about to a large extent because of those suggestions. Lorenzo, I am temporarily suspending your commit rights to the testing branch. In a recent posting you made two threats to existing layer names in the pretty footprint files and in the UI. I'd rather do this on a temporary basis and review your patch submissions rather than have to permanently revoke your commit rights according to a warning I issued earlier. So this is actually to your advantage. After the layer work is done, I will review the situation again, although we're talking about changing up some of the branches pretty soon. Dick The indexed by layer structure IMHO is > very promising (the bounding box rtree would be the next logical step). > > Of course some kind of global enumeration (call it dlist, or thru the > collectors) need to be maintained anyway. > ___ 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] Experiments and considerations for more layer
On 09/06/2013 09:26 AM, Lorenzo Marcantonio wrote: > On Fri, Sep 06, 2013 at 08:53:12AM +0200, Maciej Sumiński wrote: > Other than being a technique listen even in '80 computer graphics books, > I suppose that's needed also for 1) culling the primitives using the > rtree and 2) sorting the draw operation by layers to achieve correct > blending. > > IIRC even using the z-buffer and checking blending only works correcly > when drawing from bottom up, in opengl (and probably everywhere else > too) About culling - you are right, only things that are visible in the current viewport are drawn. The order of drawing is a matter only for the Cairo backend, in OpenGL it works fine without such requirement. Regards, Orson ___ 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] Experiments and considerations for more layer
On Fri, Sep 06, 2013 at 08:53:12AM +0200, Maciej Sumiński wrote: > BTW: This is the way how it is done in the VIEW class in the GAL - > items are held using R-trees, which are created for every layer. It > was also necessary to know which layers are occupied by a single > item, so there is ViewGetLayers() function that returns an int[] > containing layer numbers for the given item. The layer numbers are > computed during the function call (ie. ViewGetLayers() is overridden > in derived classes, so eg. TRACK may return a different set of > layers than SEGVIA), but I lean toward using std::bitset. Other than being a technique listen even in '80 computer graphics books, I suppose that's needed also for 1) culling the primitives using the rtree and 2) sorting the draw operation by layers to achieve correct blending. IIRC even using the z-buffer and checking blending only works correcly when drawing from bottom up, in opengl (and probably everywhere else too) Also since these are somewhat easy to maintain indices they would surely help for all the layer-oriented operation in kicad... even picking (which is more 'position oriented') has a layer priority depending on the current/mode layer and would benefit from it. -- 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] Experiments and considerations for more layer
On 09/05/2013 10:55 PM, Lorenzo Marcantonio wrote: On Thu, Sep 05, 2013 at 02:14:03PM -0500, Dick Hollenbeck wrote: You are correct about the model being somewhat exposed. But the model is working nicely everywhere else, and it is fast. I could argue about the 'fast' thing. The indexed by layer structure IMHO is very promising (the bounding box rtree would be the next logical step). Of course some kind of global enumeration (call it dlist, or thru the collectors) need to be maintained anyway. BTW: This is the way how it is done in the VIEW class in the GAL - items are held using R-trees, which are created for every layer. It was also necessary to know which layers are occupied by a single item, so there is ViewGetLayers() function that returns an int[] containing layer numbers for the given item. The layer numbers are computed during the function call (ie. ViewGetLayers() is overridden in derived classes, so eg. TRACK may return a different set of layers than SEGVIA), but I lean toward using std::bitset. Regards, Orson ___ 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] Experiments and considerations for more layer
On Thu, Sep 05, 2013 at 05:26:46PM -0700, Cirilo Bernardo wrote: > > I think Tom's class is adequate. I don't think Brian S.'s idea about > > dynamically > > assignable layer slots is optimal. I think fixed layer slots are easier to > > code, but I > > don't see why you have to limit the number of slots with Tom's > > approach. You can have 300 > > layers if you want, but I think you need to pre-assign all of them, and > > chose > > not to use > > but a subset of them on any board. Exactly like my original approach. > > I think fixed technical layer names are important, both to KiCad branding > > and to > > board > > merging like JP mentioned. Because these names are being indexed by google. LOL... I've *never* tought about the google thing. However I agree with JP (look in the past messages, I've already raised the issue) and also proposed a solution (I admit is not simple) for the generic case. > > This is part of why I don't want to mess with the technical layer names > > that > > are in place > > already and why I yanked the international language translations for them. I think this is not correct for the user, at least in the UI he should see its national names. I agree that it's better to handle the fixed name for the special layers inside files. > > a) specctra numbers copper layers from front to back, starting from zero. > > > > > > b) in contrast, my most recent conversations with bare board houses in > > China had > > them > > numbering layers from back to front, starting at 1 on the back. And the problem is? Altium has separate numbering for signal and coppers, for example... during fabrication for every not-trivial board you have to submit a full stackup specification (with prepregs and so on) containing the gerber names, anyway. > > c) The internal copper bit masks for layers has always bothered me, the > > sequence > > that is. Please elaborate on this. It's like the chinese numbering... what bothers you in that? > > d) Existing problematic code fragments should be identified early in the > > planning phase, > > and any design change should be evaluated on its ability to handle the > > problematic code > > collection. Please start that problematic list with where I output the > > pretty > > layers, and > > extend it by adding to it. I haven't changed a line in the I/O routines since they pull names and number from the layerset. The only problematic thing would be the .* handling which is ad-hoc (and redundant anyway). Also the initial stackup description obviously (*reading* it would be difficult) > > If the result of the first implementation is that you do not depend on > > layer > > numbers > > (much), but rather on names or range checking, then you can shift that > > enumeration at any > > time in the future without causing the source code or existing data files > > any > > grief. Mostly agree with that. It's the same as my proposal. However I think that trying to fixedly enumerate all the possible layer from the start is a lost battle. For non-special layers I think the Altium approach is better if we want to 'fix' the number of layers. > > These LAYERs and LAYER_SET are done using "Tom's 20 minute solution > > plus augmentation, as > > needed". I didn't look closely at that but why not simply use std::bitset then? > > > > If you have based your files on concise English names for all but the Cu > > layers, > > but those > > cu layers are also named, then I don't see any large grief to shift this > > conceptual > > enumeration which runs from 0 - MAX_LAYER. Not only can you make MAX_LAYER > > higher, but > > you can also shift regions of interest within it without radically impact > > code > > or data > > files later. Inner1 and Inner2 are names, anyway... the new format always uses names so it shouldn't be a problem; the layer numbering table at the beginning would describe the bit allocation. AFAIK that change is already possible (with the constraint of keeping copper layers adjacent); the only nuisance is the ranging code in the layer selector (used *only* to exclude the board borders) which would be a minor fix anyway. In substance I think that if we can keep the things between FIRST_COPPER_LAYER...LAST_COPPER_LAYER and FIRST_NON_COPPER_LAYER...LAST_NON_COPPER_LAYER, nothing should break. I would add a FIRST_USER_LAYER...LAST_USER_LAYER subrange reserved for an Altium-like configurable range i.e. non special renameable user layers (so adhesives, draw, comment, eco1, eco2 would fit in that as 'useful defaults'). I already extracted all the pairing code so it only need a way to store which user layer is paired with which (if it's paired). Or, splurge another layer range number and have a range of front-back front-back front-back user layers with fixed pairing and a range of non paired user layers. That would be even simpler to handle. -- Lorenzo Marcantonio Logos Srl ___ Mailing list:
Re: [Kicad-developers] Experiments and considerations for more layer
- Original Message - > From: Dick Hollenbeck > To: kicad-developers@lists.launchpad.net > Cc: > Sent: Friday, September 6, 2013 3:49 AM > Subject: Re: [Kicad-developers] Experiments and considerations for more > layer > > On 09/05/2013 12:03 PM, Lorenzo Marcantonio wrote: >> On Thu, Sep 05, 2013 at 11:02:36AM -0500, Dick Hollenbeck wrote: >>> Says you. Says me: having the the bits in the instance block matter. >>> >>> >>> I guess if what I have to say is going to be labelled as irrelevant > right out the box, I'd >>> be wasting my time continuing. >> >> Strange that, said by someone which a little while ago told that data >> could even be on the moon and it's all a question of interface... > I'd >> like you to notice that in my first message I was concerned about >> performance of an object vs a simple integer. These things should be a) >> readily copyable and b) readily passed around by value, from the common >> usage pattern I've seen. >> >>> From a performance standpoint I'd roughly evaluate the > implementations (both in >> space and in time) in this order: int, std::bitset<>, > std::vector, >> std::set. The adhoc implementation should be roughly on par with >> bitset. > > > Agreed, I estimate the same. > > >> >> However, what I meant was that there were 'bigger' proposals on the > list >> to evaluate. Something like std::bitset (i.e. something inherently >> configured and limited at compile time) clearly is not adequate for >> these proposals. > > > > I think Tom's class is adequate. I don't think Brian S.'s idea about > dynamically > assignable layer slots is optimal. I think fixed layer slots are easier to > code, but I > don't see why you have to limit the number of slots with Tom's > approach. You can have 300 > layers if you want, but I think you need to pre-assign all of them, and chose > not to use > but a subset of them on any board. > > I think fixed technical layer names are important, both to KiCad branding and > to > board > merging like JP mentioned. Because these names are being indexed by google. > > KiCad branding comes about via help with google and propagation of opensource > boards and > pretty footprint libraries. > > This is part of why I don't want to mess with the technical layer names that > are in place > already and why I yanked the international language translations for them. > *Adding* to > that established list with concise English names is not a problem for me. > The > footprint > format, at least pretty, should not be viewed as forever fixed. However the > keywords we > have already chosen should not be changed, while remaining open to > significant > additions > to it. > > > Some observations: > > a) specctra numbers copper layers from front to back, starting from zero. > > > b) in contrast, my most recent conversations with bare board houses in China > had > them > numbering layers from back to front, starting at 1 on the back. > > > c) The internal copper bit masks for layers has always bothered me, the > sequence > that is. > > > d) Existing problematic code fragments should be identified early in the > planning phase, > and any design change should be evaluated on its ability to handle the > problematic code > collection. Please start that problematic list with where I output the > pretty > layers, and > extend it by adding to it. > > > It seems to me we could go with a conceptual enumeration embodied in Tom's > FLAG_SET > template, where the enumeration starts at zero and goes on up forever if need > be. > Although you pick the end of the range with a compiled in number, that is > pertinent until > it is inadequate. > > If the result of the first implementation is that you do not depend on layer > numbers > (much), but rather on names or range checking, then you can shift that > enumeration at any > time in the future without causing the source code or existing data files any > grief. > > > For for the sake of discussion, I propose as one possibility: > > 0 - 31 are cu layers > > 32 - MAX_LAYER are technical layers. > > > These LAYERs and LAYER_SET are done using "Tom's 20 minute solution > plus augmentation, as > needed". > > > If you have based your files on concise English names for all but the Cu > layers, > but those > cu layers are also named, then I don
Re: [Kicad-developers] Experiments and considerations for more layer
On 09/03/2013 08:08 AM, Tomasz Wlostowski wrote:
> On 09/03/2013 02:24 PM, Lorenzo Marcantonio wrote:
>> On Tue, Sep 03, 2013 at 05:29:12AM -0600, Brian F. G. Bidulock wrote:
>>> See my other note. Just remember what layers things are on instead
>>> of messing around with bitmasks. So, when you place pin 1, you place
>>> it in the cells occupied by its shape and clearance, and place it (by
>>> reference) in the front, inner1, inner2, back copper, silk front, mask
>>> front, assembly front and assembly back layer sets.
>>
>> Now I got it. You keep a 'by layer' index of entities. It's a good
>> solution, I agree. However when loading/saving/editing a pad (or
>> computing the netlist) it's way more handy to have the list of the
>> layers a pad is on, so I'd keep it around in the pad (not necessarily
>> a bitmask, see other message).
>>
>>
>>
> It's all a matter of the interface. IMHO the biggest problem with the
> current storage are the DLISTs, that leak the internals of the model to
> every single file in the code. For instance, if I want to iterate over
> the tracks, I can't do anything else than:
>
> for (TRACK *t = board->m_Track; t; t = t->Next() ) {...}.
>
> The t->Next() leaks an implementation detail (a doubly linked list) into
> the interface. If somebody wants to replace that list with a spatially
> indexing container, he'll likely have a problem, and what's worse, he'll
> have to rewrite a huge pile of code that directly accesses the DLIST...,
> at least replacing the m_Track (or whatever else) with an iterator class
> having same interface as the DLIST:
>
> for (BOARD::Iterator t = board->Iterate ( PCB_TRACE_T ); t; t =
> t.Next() ) {...}.
>
> IMHO the first goal is to clean the non-model code of the references to
> the internals of the model. Then we are free to implement any sort of
> cell/tree/layer-set indexing in BOARD without having to change the
> interface.
Tom,
We may have more dialogue when we can see the code.
But, we've had this same conversation before. I said:
a) we'd be reluctant to change the BOARD model,
b) that you should use class COLLECTOR to avoid any knowledge about where items
are
stored. At least to acquire the items of interest. You can get anything you
want into an
STL container (COLLECTOR and derivatives would be such) that way, and can
extend COLLECTOR
in any way you want just to acquire the BOARD_ITEMs.
c) once you have the board items, I suggested you build a facade of your own
design for
the TRACK and VIA management.example:
/// via living in the facade, and MAYBE in the BOARD too.
class RVIA
{
// a SEGVIA, never NULL. But it may or may not be in BOARD.
SEGVIA* m_via;
bool IOwn()
{
// is it in the BOARD yet, I really don't care either way yet.
return !m_Via->Next() && !m_via->Prev();
}
};
/// track living in the facade, and MAYBE in the BOARD too.
class RTRACK
{
// same idea
};
Your facade can be RVIA's and RTRACKS, indexed and augmented with any data you
want. When
your user is done routing, or taking a break gesture-wise, make a pass through
your facade
and add any TRACKs or VIAs that you own (see IOwn() above) i.e. that are not in
the BOARD,
to the BOARD.
This should be possible since your VIEW is what you graphically draw from, not
from the BOARD.
You are correct about the model being somewhat exposed. But the model is
working nicely
everywhere else, and it is fast.
We may have more dialogue when we can see the code.
>
> For the P&S I also needed some sort of lightweight copying (I call it
> branching), that is creating lots of copies of the root model that are
> slightly changed wrs to the root (I use it for making the traces
> "springback" when the cursor is moved back and for comparing different
> optimization strategies). I learned that having links between items
> stored in the items makes such copying mechanism difficult to implement.
>
> My experience after writing the P&S router is:
> - restrict access to the model through Add, Remove, Replace methods and
> iterators (in my case QueryColliding/NearestObstacle).
> - store connectivity information in the container, not in the items
> (JointMap). This way it's possible to replace any set of segments/vias
> in the newer branch without having to modify the old ones or the parent
> node that hosts them.
> - copy - modify - replace instead of modify live thing. I know it's
> slower but at least in case of the P&S, the bottleneck is collision
> finding...
>
> Tom
>
> PS. about more than 64 layers - I attached an example flag set class. Of
> course it's not as fast as a bare int/int64 (4 assembly instructions
> instead of one/two), but it brings type safety and automatic
> serialization (it's just a demo written in 20 minutes, not a quality code).
>
>
>
> ___
> Mailing list: https://launchpad.net/~kicad-develope
Re: [Kicad-developers] Experiments and considerations for more layer
On 09/05/2013 12:03 PM, Lorenzo Marcantonio wrote: > On Thu, Sep 05, 2013 at 11:02:36AM -0500, Dick Hollenbeck wrote: >> Says you. Says me: having the the bits in the instance block matter. >> >> >> I guess if what I have to say is going to be labelled as irrelevant right >> out the box, I'd >> be wasting my time continuing. > > Strange that, said by someone which a little while ago told that data > could even be on the moon and it's all a question of interface... I'd > like you to notice that in my first message I was concerned about > performance of an object vs a simple integer. These things should be a) > readily copyable and b) readily passed around by value, from the common > usage pattern I've seen. > >>From a performance standpoint I'd roughly evaluate the implementations (both >>in > space and in time) in this order: int, std::bitset<>, std::vector, > std::set. The adhoc implementation should be roughly on par with > bitset. Agreed, I estimate the same. > > However, what I meant was that there were 'bigger' proposals on the list > to evaluate. Something like std::bitset (i.e. something inherently > configured and limited at compile time) clearly is not adequate for > these proposals. I think Tom's class is adequate. I don't think Brian S.'s idea about dynamically assignable layer slots is optimal. I think fixed layer slots are easier to code, but I don't see why you have to limit the number of slots with Tom's approach. You can have 300 layers if you want, but I think you need to pre-assign all of them, and chose not to use but a subset of them on any board. I think fixed technical layer names are important, both to KiCad branding and to board merging like JP mentioned. Because these names are being indexed by google. KiCad branding comes about via help with google and propagation of opensource boards and pretty footprint libraries. This is part of why I don't want to mess with the technical layer names that are in place already and why I yanked the international language translations for them. *Adding* to that established list with concise English names is not a problem for me. The footprint format, at least pretty, should not be viewed as forever fixed. However the keywords we have already chosen should not be changed, while remaining open to significant additions to it. Some observations: a) specctra numbers copper layers from front to back, starting from zero. b) in contrast, my most recent conversations with bare board houses in China had them numbering layers from back to front, starting at 1 on the back. c) The internal copper bit masks for layers has always bothered me, the sequence that is. d) Existing problematic code fragments should be identified early in the planning phase, and any design change should be evaluated on its ability to handle the problematic code collection. Please start that problematic list with where I output the pretty layers, and extend it by adding to it. It seems to me we could go with a conceptual enumeration embodied in Tom's FLAG_SET template, where the enumeration starts at zero and goes on up forever if need be. Although you pick the end of the range with a compiled in number, that is pertinent until it is inadequate. If the result of the first implementation is that you do not depend on layer numbers (much), but rather on names or range checking, then you can shift that enumeration at any time in the future without causing the source code or existing data files any grief. For for the sake of discussion, I propose as one possibility: 0 - 31 are cu layers 32 - MAX_LAYER are technical layers. These LAYERs and LAYER_SET are done using "Tom's 20 minute solution plus augmentation, as needed". If you have based your files on concise English names for all but the Cu layers, but those cu layers are also named, then I don't see any large grief to shift this conceptual enumeration which runs from 0 - MAX_LAYER. Not only can you make MAX_LAYER higher, but you can also shift regions of interest within it without radically impact code or data files later. Dick > > std::set (usually a balanced tree) is the bigger and slower and > IMHO only would have a meaning if we allowed arbitrarily large and > sparse layer numbers. std::vector feels a good compromise. An > std::bitset<> or a int64_t would be useful if we put a cap of maximum 64 > or whatever number of simultaneous layers. With an 'adequate' layerset > structure that could be arranged. > > ___ 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] Experiments and considerations for more layer
On Thu, Sep 05, 2013 at 11:02:36AM -0500, Dick Hollenbeck wrote: > Says you. Says me: having the the bits in the instance block matter. > > > I guess if what I have to say is going to be labelled as irrelevant right out > the box, I'd > be wasting my time continuing. Strange that, said by someone which a little while ago told that data could even be on the moon and it's all a question of interface... I'd like you to notice that in my first message I was concerned about performance of an object vs a simple integer. These things should be a) readily copyable and b) readily passed around by value, from the common usage pattern I've seen. >From a performance standpoint I'd roughly evaluate the implementations (both in space and in time) in this order: int, std::bitset<>, std::vector, std::set. The adhoc implementation should be roughly on par with bitset. However, what I meant was that there were 'bigger' proposals on the list to evaluate. Something like std::bitset (i.e. something inherently configured and limited at compile time) clearly is not adequate for these proposals. std::set (usually a balanced tree) is the bigger and slower and IMHO only would have a meaning if we allowed arbitrarily large and sparse layer numbers. std::vector feels a good compromise. An std::bitset<> or a int64_t would be useful if we put a cap of maximum 64 or whatever number of simultaneous layers. With an 'adequate' layerset structure that could be arranged. Am I still wasting your time? -- 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] Experiments and considerations for more layer
On 09/05/2013 09:38 AM, Lorenzo Marcantonio wrote: > On Thu, Sep 05, 2013 at 07:12:40AM -0500, Dick Hollenbeck wrote: >> That looks excellent. > > Yep, quite. > >> I was also thinking bit set. The fact that std::bitset<> takes a size >> suggests it is >> putting the bits in the instance block, not in a separate block of memory. > > I think the issue is not the 'best' kind of bit vector (his > implementation is more or less like the bitset, there are also > std::vector, or even std::set which are not > compile-time bound in size). Says you. Says me: having the the bits in the instance block matter. I guess if what I have to say is going to be labelled as irrelevant right out the box, I'd be wasting my time continuing. I don't have it to waste. Of course you can't have an 'unbounded' > fixed size structure (there are tricks, like, keep the first 32 often > used bits in a local word and allocate a block if other ones are needed, > but this is an implementation optimization). > > I think the question is if to keep the current fixed-in-code layer > stackup or moving toward a more dynamic layer structure. > ___ 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] Experiments and considerations for more layer
On Thu, Sep 05, 2013 at 02:14:03PM -0500, Dick Hollenbeck wrote: > You are correct about the model being somewhat exposed. But the model is > working nicely > everywhere else, and it is fast. I could argue about the 'fast' thing. The indexed by layer structure IMHO is very promising (the bounding box rtree would be the next logical step). Of course some kind of global enumeration (call it dlist, or thru the collectors) need to be maintained anyway. -- 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] Experiments and considerations for more layer
On Thu, Sep 05, 2013 at 07:12:40AM -0500, Dick Hollenbeck wrote: > That looks excellent. Yep, quite. > I was also thinking bit set. The fact that std::bitset<> takes a size > suggests it is > putting the bits in the instance block, not in a separate block of memory. I think the issue is not the 'best' kind of bit vector (his implementation is more or less like the bitset, there are also std::vector, or even std::set which are not compile-time bound in size). Of course you can't have an 'unbounded' fixed size structure (there are tricks, like, keep the first 32 often used bits in a local word and allocate a block if other ones are needed, but this is an implementation optimization). I think the question is if to keep the current fixed-in-code layer stackup or moving toward a more dynamic layer structure. -- 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] Experiments and considerations for more layer
> PS. about more than 64 layers - I attached an example flag set class. Of
> course it's not as fast as a bare int/int64 (4 assembly instructions
> instead of one/two), but it brings type safety and automatic
> serialization (it's just a demo written in 20 minutes, not a quality code).
Tom,
That looks excellent.
I was also thinking bit set. The fact that std::bitset<> takes a size suggests
it is
putting the bits in the instance block, not in a separate block of memory.
Efficiency seems is more than adequate, and might even be more than adequate
even if
FLAG_SET::operator| () and FLAG_SET::operator& ()
were *not* inlined. It would be worth looking at how much code is put out for
those ops
to decide.
If we got rid of the tabs and we could use it tomorrow.
We probably need either 1) or 2) below so we can do:
if( bool( layer1 & layer2 ) )
{
}
1
FLAG_SET::operator bool () to return
return (bool) this.count();
2
change FLAG_SET::operator& () to return
return (bool) rv.count();
In this case you would also need a |= opertor and &= operator to assemble
LAYER_SETs.
___
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] Experiments and considerations for more layer
- Original Message -
> From: Lorenzo Marcantonio
> To: Kicad Developers
> Cc:
> Sent: Tuesday, September 3, 2013 10:09 PM
> Subject: Re: [Kicad-developers] Experiments and considerations for more
> layer
>
> On Tue, Sep 03, 2013 at 04:15:39AM -0700, Cirilo Bernardo wrote:
>> A down side to keeping things manageable (such as merging components into
> the PCB) would be that there has to be a mapping which KiCAD enforces for the
> integer layer ID and the usage. That is certainly possible and when
> implemented
> I suspect the biggest nuisance would be to people who use custom layers - but
> even that can be addressed by reserving a block of IDs which KiCAD will never
> use in the main tree.
>
> Nothing forbids to reserve a range of layer IDs for that. Eagle for
> example has the first 100 layers 'reserved'. We can decide, for example
> that 0-15 (or maybe 0-31) are copper layers, the next ten or so are the
> special layers and over a 'safe' number (64, or 100) are available to
> the user for his stuff.
>
> That would simplify the reconciling code a bit and let use integer
> literals for the special layers (with ominous operator definitions,
> obviously). Of course user defined layers would need the stackup object
> help to correlate. Semi-formal example:
>
> Board A 'domain'
> Stackup object STACKA
> 0 Front
> ..
> 15 Back
> 16 Silk Front
> ..
> 100 Peel Mask
>
> Board B 'domain' (could be for a library module, maybe)
> Stackup object STACKB
> 0 Front
> ..
> 15 Back
> 16 Silk Front
> ..
> 150 Peel Mask
> 160 Plating
>
> The stackup would be vectors or sets, depending on the maximum number of
> layers you want to handle. Also O(1) vs O(log n) performance. The usual
> tradeoff.
>
> A layer id would be an ordered pair containing the stackup and the layer
> number. A pointer and an integers in other words. Significantly larger
> than an int but still acceptable. These things have to be designed to be
> passed around by value, like numbers (C++ can do that without problems).
>
> So STACKA:15 is the back copper in the board A domain, STACKB:160 is the
> plating layer in the board B domain.
>
> Also, a 'small integer' is valid as a layer id for fixed meaning layers.
> So 16 is *always* silk front, 0 is always copper front and so on. 150
> has *no meaning* by itself since it's not a common layer. IIRC you can
> define these implicit constructors, too.
>
> Then, establish an equivalence relationship same-layer-as where:
> 0 same-layer-as STACKA:0,
> 0 same-layer-as STACKB:0,
> STACKA:100 same-layer-as STACKB:150
>
> (things to clarify: should it this be on the name given by the user? also,
> what if a layer with the same name has different attributes on the
> opposite sides? example: STACKA:100 could have a paired layer,
> STACKB:150 not necessarily; an 'incompatible definition' exception
> should be resolved in some way)
>
> Finally, add an operation change-domain so that:
> 0 change-domain STACKA -> 0 (no need to qualify it!)
> STACKA:100 change-domain STACKB -> STACKB:150 (a lookup)
> STACKB:160 change-domain STACKA -> STACKA:somenewnumber (the merge
> operation)
> obviously after that
> STACKA:thepreviousnumber change-domain STACKB -> STACKB:160
>
> For the masking issue: as correctly shown *most* operation actually need
> only one layers (or a range, for vias). OTOH pads need a bitmask or
> something similar. These could be represented as vector or
> set (same consideration as before). Layer masks need to reference
> to a stackup, as layer ids. So valid masks could be:
>
> STACKA:0,1,2,3,4,5,6,7,8,9,10,11,12,13,14,15 (a THT pad)
> STACKB:0,160 (a card egde pad, maybe)
>
> Optional: the 1-14 range could be optimized with a flag 'all inner
> layers', since it's a very common thing and wastes both time to manage
> and space in the mask structure.
>
> Define on this object the change-domain operation (trivial) and a lookup
> operation for containment (trivial, too, and actually the most frequent
> operation on layer masks). Testing a layer for containment in a mask
> from another domain could simply apply change-domain to the checked
> layer before testing.
>
> In short, instead of (mask & LAYER_FRONT) use
> mask.contains(LAYER_N_FRONT). Many mask uses actually in a loop like
> this:
>
> for (i = LAYER_N_FRONT; i <= LAYER_N_BACK; ++i) {
> LAYER_MASK msk = GetLayerMask(i);
> if (the_mask & msk) stuff();
> }
>
> and that becomes (I find it more
Re: [Kicad-developers] Experiments and considerations for more layer
On Tue, Sep 03, 2013 at 03:23:46PM +0200, Tomasz Wlostowski wrote: > BTW. Judging from Altium's ASCII file format, it also copies every > component - and it's a pretty decent PCB program... Also: until 2009 it only had 16 mechanical layers, and even today that you have 32 you have to be consistent on how to use them in the library/projects... (i.e. they are addressed by number, not name) Look on youtube, there is a tutorial where the first thing they show you is a sheet with their layer allocation:D As for the component copy issue I find it acceptable. Copy-on-write would be better but there are areas more in need of work than that. -- 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] Experiments and considerations for more layer
On 09/03/2013 12:33 PM, Brian F. G. Bidulock wrote: Lorenzo, On Tue, 03 Sep 2013, Lorenzo Marcantonio wrote: On Tue, Sep 03, 2013 at 04:21:59AM -0600, Brian F. G. Bidulock wrote: 5000 module descriptions to extract the 5000 pieces of placement data is the horror of kicad's internal representation. There is a reason for components being copied and not instantiated. Often you need to 'tweak' a component, slimming or fattening a pad, or removing unusing fixture holes. So your 5000 capacitors are not necessarily all the same! But they are the same. Only an fool copies something 5000 times in preparation for the never occuring eventuality of modifying one of them: the code to copy when modification is demanded is trivial. But it is an apt indication of the pond-scum maturity of the code base. Only a fool copies something 5000 times, if he has the time to write and debug the code that avoids copying. In all other cases I'd say copying is fine, and RAMs are dirt cheap nowadays. If someone orders PCBs with 5k+ components that cost thousands of dollars, (s)he can also spend $50 for extra few GBs of memory. BTW. Judging from Altium's ASCII file format, it also copies every component - and it's a pretty decent PCB program... 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] Experiments and considerations for more layer
On 09/03/2013 02:24 PM, Lorenzo Marcantonio wrote:
On Tue, Sep 03, 2013 at 05:29:12AM -0600, Brian F. G. Bidulock wrote:
See my other note. Just remember what layers things are on instead
of messing around with bitmasks. So, when you place pin 1, you place
it in the cells occupied by its shape and clearance, and place it (by
reference) in the front, inner1, inner2, back copper, silk front, mask
front, assembly front and assembly back layer sets.
Now I got it. You keep a 'by layer' index of entities. It's a good
solution, I agree. However when loading/saving/editing a pad (or
computing the netlist) it's way more handy to have the list of the
layers a pad is on, so I'd keep it around in the pad (not necessarily
a bitmask, see other message).
It's all a matter of the interface. IMHO the biggest problem with the
current storage are the DLISTs, that leak the internals of the model to
every single file in the code. For instance, if I want to iterate over
the tracks, I can't do anything else than:
for (TRACK *t = board->m_Track; t; t = t->Next() ) {...}.
The t->Next() leaks an implementation detail (a doubly linked list) into
the interface. If somebody wants to replace that list with a spatially
indexing container, he'll likely have a problem, and what's worse, he'll
have to rewrite a huge pile of code that directly accesses the DLIST...,
at least replacing the m_Track (or whatever else) with an iterator class
having same interface as the DLIST:
for (BOARD::Iterator t = board->Iterate ( PCB_TRACE_T ); t; t =
t.Next() ) {...}.
IMHO the first goal is to clean the non-model code of the references to
the internals of the model. Then we are free to implement any sort of
cell/tree/layer-set indexing in BOARD without having to change the
interface.
For the P&S I also needed some sort of lightweight copying (I call it
branching), that is creating lots of copies of the root model that are
slightly changed wrs to the root (I use it for making the traces
"springback" when the cursor is moved back and for comparing different
optimization strategies). I learned that having links between items
stored in the items makes such copying mechanism difficult to implement.
My experience after writing the P&S router is:
- restrict access to the model through Add, Remove, Replace methods and
iterators (in my case QueryColliding/NearestObstacle).
- store connectivity information in the container, not in the items
(JointMap). This way it's possible to replace any set of segments/vias
in the newer branch without having to modify the old ones or the parent
node that hosts them.
- copy - modify - replace instead of modify live thing. I know it's
slower but at least in case of the P&S, the bottleneck is collision
finding...
Tom
PS. about more than 64 layers - I attached an example flag set class. Of
course it's not as fast as a bare int/int64 (4 assembly instructions
instead of one/two), but it brings type safety and automatic
serialization (it's just a demo written in 20 minutes, not a quality code).
/*
* KiRouter - a push-and-(sometimes)-shove PCB router
*
* Copyright (C) 2013 CERN
* @author Tomasz WÅostowski
*
* This program is free software: you can redistribute it and/or modify it
* under the terms of the GNU General Public License as published by the
* Free Software Foundation, either version 3 of the License, or (at your
* option) any later version.
* This program is distributed in the hope that it will be useful, but
* WITHOUT ANY WARRANTY; without even the implied warranty of
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
* General Public License for more details.
* You should have received a copy of the GNU General Public License along
* with this program. If not, see
Re: [Kicad-developers] Experiments and considerations for more layer
Lorenzo, On Tue, 03 Sep 2013, Lorenzo Marcantonio wrote: > On Tue, Sep 03, 2013 at 05:29:12AM -0600, Brian F. G. Bidulock wrote: > > See my other note. Just remember what layers things are on instead > > of messing around with bitmasks. So, when you place pin 1, you place > > it in the cells occupied by its shape and clearance, and place it (by > > reference) in the front, inner1, inner2, back copper, silk front, mask > > front, assembly front and assembly back layer sets. > > Now I got it. You keep a 'by layer' index of entities. It's a good > solution, I agree. However when loading/saving/editing a pad (or > computing the netlist) it's way more handy to have the list of the > layers a pad is on, so I'd keep it around in the pad (not necessarily > a bitmask, see other message). That's it. The board item doesn't have to change hardly. It just has a thread reference to the cells and layers to which it belongs. The layer reference is just the m_class/m_index packed in a 32-bit int. A pair for vias. This already exists in the object, the accessors just changed slightly. The cells are a std::set of cells (or not, they can be recalculated when moving the object). --brian -- Brian F. G. Bidulock� The reasonable man adapts himself to the � bidul...@openss7.org� world; the unreasonable one persists in � http://www.openss7.org/ � trying to adapt the world to himself. � � Therefore all progress depends on the � � unreasonable man. -- George Bernard Shaw � ___ 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] Experiments and considerations for more layer
On Tue, Sep 03, 2013 at 05:29:12AM -0600, Brian F. G. Bidulock wrote: > See my other note. Just remember what layers things are on instead > of messing around with bitmasks. So, when you place pin 1, you place > it in the cells occupied by its shape and clearance, and place it (by > reference) in the front, inner1, inner2, back copper, silk front, mask > front, assembly front and assembly back layer sets. Now I got it. You keep a 'by layer' index of entities. It's a good solution, I agree. However when loading/saving/editing a pad (or computing the netlist) it's way more handy to have the list of the layers a pad is on, so I'd keep it around in the pad (not necessarily a bitmask, see other message). -- Lorenzo Marcantonio Logos Srl smime.p7s Description: S/MIME cryptographic 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
Re: [Kicad-developers] Experiments and considerations for more layer
On Tue, Sep 03, 2013 at 05:21:58AM -0600, Brian F. G. Bidulock wrote: > Want to generate a Gerber for copper layer 4? Just iterate. No > masking required. Major column versus major row... you optimize one thing and slow down the other. A design decision like any other. What if you want to know all the things related on a pad? or 1) you sweep all the layers for a match or 2) cross index them. Also: what if there is cross dependency between layers i.e. the same entity is on more than one layer? for example the refdes has to be plotted in its position on silk and on the component origin on assembly. This kind of operation is better suited to the current data structure. Also see the debate on row vs column based database partitioning for the issue on a *way* bigger scale. > The same as layers is true for locality. Want to know what is close > to board item 14951? Kicad compares its geometrical distance to > EVERY OTHER ITEM ON THE BOARD, EACH TIME! Using crude integer math I agree; *that* part of kicad literally sucks:P:P (worse, it does on every track every time you move the mouse dragging a track). The display refresh which doesn't even cull is guilty too. I can't agree more with you in that. Rumors are that there is an R-tree in the works, at least. Oh, and still there is the clip routine which calculates the distance even it the target pointer is null (IIRC something like 22% of the redraw time). Have to fix that one of these days... -- 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] Experiments and considerations for more layer
On Tue, Sep 03, 2013 at 04:15:39AM -0700, Cirilo Bernardo wrote:
> A down side to keeping things manageable (such as merging components into the
> PCB) would be that there has to be a mapping which KiCAD enforces for the
> integer layer ID and the usage. That is certainly possible and when
> implemented I suspect the biggest nuisance would be to people who use custom
> layers - but even that can be addressed by reserving a block of IDs which
> KiCAD will never use in the main tree.
Nothing forbids to reserve a range of layer IDs for that. Eagle for
example has the first 100 layers 'reserved'. We can decide, for example
that 0-15 (or maybe 0-31) are copper layers, the next ten or so are the
special layers and over a 'safe' number (64, or 100) are available to
the user for his stuff.
That would simplify the reconciling code a bit and let use integer
literals for the special layers (with ominous operator definitions,
obviously). Of course user defined layers would need the stackup object
help to correlate. Semi-formal example:
Board A 'domain'
Stackup object STACKA
0 Front
..
15 Back
16 Silk Front
..
100 Peel Mask
Board B 'domain' (could be for a library module, maybe)
Stackup object STACKB
0 Front
..
15 Back
16 Silk Front
..
150 Peel Mask
160 Plating
The stackup would be vectors or sets, depending on the maximum number of
layers you want to handle. Also O(1) vs O(log n) performance. The usual
tradeoff.
A layer id would be an ordered pair containing the stackup and the layer
number. A pointer and an integers in other words. Significantly larger
than an int but still acceptable. These things have to be designed to be
passed around by value, like numbers (C++ can do that without problems).
So STACKA:15 is the back copper in the board A domain, STACKB:160 is the
plating layer in the board B domain.
Also, a 'small integer' is valid as a layer id for fixed meaning layers.
So 16 is *always* silk front, 0 is always copper front and so on. 150
has *no meaning* by itself since it's not a common layer. IIRC you can
define these implicit constructors, too.
Then, establish an equivalence relationship same-layer-as where:
0 same-layer-as STACKA:0,
0 same-layer-as STACKB:0,
STACKA:100 same-layer-as STACKB:150
(things to clarify: should it this be on the name given by the user? also,
what if a layer with the same name has different attributes on the
opposite sides? example: STACKA:100 could have a paired layer,
STACKB:150 not necessarily; an 'incompatible definition' exception
should be resolved in some way)
Finally, add an operation change-domain so that:
0 change-domain STACKA -> 0 (no need to qualify it!)
STACKA:100 change-domain STACKB -> STACKB:150 (a lookup)
STACKB:160 change-domain STACKA -> STACKA:somenewnumber (the merge
operation)
obviously after that
STACKA:thepreviousnumber change-domain STACKB -> STACKB:160
For the masking issue: as correctly shown *most* operation actually need
only one layers (or a range, for vias). OTOH pads need a bitmask or
something similar. These could be represented as vector or
set (same consideration as before). Layer masks need to reference
to a stackup, as layer ids. So valid masks could be:
STACKA:0,1,2,3,4,5,6,7,8,9,10,11,12,13,14,15 (a THT pad)
STACKB:0,160 (a card egde pad, maybe)
Optional: the 1-14 range could be optimized with a flag 'all inner
layers', since it's a very common thing and wastes both time to manage
and space in the mask structure.
Define on this object the change-domain operation (trivial) and a lookup
operation for containment (trivial, too, and actually the most frequent
operation on layer masks). Testing a layer for containment in a mask
from another domain could simply apply change-domain to the checked
layer before testing.
In short, instead of (mask & LAYER_FRONT) use
mask.contains(LAYER_N_FRONT). Many mask uses actually in a loop like
this:
for (i = LAYER_N_FRONT; i <= LAYER_N_BACK; ++i) {
LAYER_MASK msk = GetLayerMask(i);
if (the_mask & msk) stuff();
}
and that becomes (I find it more elegant)
for (i = LAYER_N_FRONT; i <= LAYER_N_BACK; ++i) {
/* i is a reserved layer number so an int is acceptable! */
if (the_mask.contains(i)) stuff();
}
of course member iteration would be an interesting thing to do, if
needed.
I don't remember if intersection between arbitrary masks is ever
used... that could be defined as logical/set intersection, no problem
with that.
Add useful predicates like: IsFrontLayer (for a layer) or HasFrontLayer
(for a mask, to check if it contains at least one layer on the front
side). The list of these predicates has to be determined by inspection
(i.e. during implementation :D). Some of these are already in use (look
in the layer header). Also the fliplayer function. A layer can access
its stackup so it can ask it for its paired layer.
IIRC these are all the operations needed (well, serialization too but
th
Re: [Kicad-developers] Experiments and considerations for more layer
Cirilo, On Tue, 03 Sep 2013, Cirilo Bernardo wrote: > A down side to keeping things manageable (such as merging components > into the PCB) would be that there has to be a mapping which KiCAD > enforces for the integer layer ID and the usage. That is certainly > possible and when implemented I suspect the biggest nuisance would be > to people who use custom layers - but even that can be addressed by > reserving a block of IDs which KiCAD will never use in the main tree. > > Time is certainly the biggest thing; it would be great if we had > corporate sponsors so people could dedicate their time to the code. I > have so much free time that I haven't even been able to implement some > rather simple features on the VRML export. Oh well, at least I managed > to fix some simple bugs in the VRML code all those months ago when we > moved to nanometer units. It would be a great shame if Brian's work > didn't eventually merge back into the main tree; I suspect that > staging the changes would be at least one full time job though. I > was thinking of what minimal implementation of IDF3 import would be of > use in KiCAD and I didn't realize that Brian had implemented enough > new features to support all of IDF3 and much more. In 2009-2010 I spent a full year coding on kicad, full time, just to try and build one 10G board. Not a single line of code was adopted. It took 3 years for kicad to recreate the internal unit change that I accomplished in the first 3 months. I have never encountered a project so adverse to contributions (mind you, I never tried to contribute to Gnome). There is a real opportunity for kicad with CERN. They have the same objectives I did: 10G boards or better. They have many more better coders. Their time is free to you. They want IDF too, but also much more. Hopefully they will just fork it when they discover that their changes will never see the mainline. --brian -- Brian F. G. Bidulock� The reasonable man adapts himself to the � bidul...@openss7.org� world; the unreasonable one persists in � http://www.openss7.org/ � trying to adapt the world to himself. � � Therefore all progress depends on the � � unreasonable man. -- George Bernard Shaw � ___ 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] Experiments and considerations for more layer
Lorenzo, On Tue, 03 Sep 2013, Lorenzo Marcantonio wrote: > On Tue, Sep 03, 2013 at 04:38:13AM -0600, Brian F. G. Bidulock wrote: > > You don't need list of layers: just from and to--a pair. > > How do you fit mask, silk and other technical layers in a range? I agree > that it would work for copped layers. But IMHO the 'right' solution > would be to have a pin object containing it's instances for each layer > i.e. > > Pin 1 > Pin 1 on front > Pin 1 on inner 1 > Pin 1 on inner 2 > Pin 1 on back > Pin 1 on silk front > Pin 1 on mask front > Pin 1 on mask back > Pin 1 on assembly front > Pin 1 on assembly back > > That would allow you to have 'true' padstacks. Vias of course could remain > range based (unless you wanted to personalize via by layers, that could be > overkill) See my other note. Just remember what layers things are on instead of messing around with bitmasks. So, when you place pin 1, you place it in the cells occupied by its shape and clearance, and place it (by reference) in the front, inner1, inner2, back copper, silk front, mask front, assembly front and assembly back layer sets. Any procedure wanting to find whats in those layers or cells will simply find pin 1 there as part of the sets. std::set union and intersection operations are fast, and comparisons are decimated. --brian -- Brian F. G. Bidulock� The reasonable man adapts himself to the � bidul...@openss7.org� world; the unreasonable one persists in � http://www.openss7.org/ � trying to adapt the world to himself. � � Therefore all progress depends on the � � unreasonable man. -- George Bernard Shaw � ___ 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] Experiments and considerations for more layer
Lorenzo, On Tue, 03 Sep 2013, Lorenzo Marcantonio wrote: > On Tue, Sep 03, 2013 at 03:41:26AM -0600, Brian F. G. Bidulock wrote: > > Mid-term in the wrong direction. Kicad is like that... > > Look. I have this board due to fabrication for the end of month. > I simply can't implement the whole object model in time *and* do the > board layout to produce it. > > It's a human resource allocation problem :D it's a temporary solution > but *it works*; the optimal solution is not useful if it's not available > for use. > > The kicad object model is not perfect (and anyway everyone has its own > idea of perfect model), but kicad itself is not exactly small. Probably > only you and me know exactly how many time a layer type is > used/iterated/converted in pcbnew:P > > Also if you remember even my type cleanup was partially rejected > becaused they wanted to keep layers as 'simple integer'. And if was > actually a little more than a typedef. A mergeable layerset > implementation would require a full layer class and other objects (as > you said, correctly), but I simply don't think that would be accepted by > the 'steering commitee' of kicad:P I don't like, too, the asymmetry > between the board layer structure (renameable) and the module one (the > 'standard english'). Going generic requires a pervasive layer container > (call it stackup or whatever) and layers would then coordinate with > their own container, or something like that. > > In short, I perfectly agree with you but I don't think is feasible to > propose such a big change (which is mostly a management issue). I almost > got lynched when I proposed switching to enums from #defines.. (reason: > you have to type the containing namespace, too) I hear you. But for conjecture sake (nothing will ever really change in kicad), consider this: someone though that because bit masks are fast that it would be a simplification to take each mask and ALWAYS COMPARE IT TO EVERY FEATURE ON THE BOARD, EACH TIME! Better way: remember what items are on what layers. That's what I did. What's on copper layer 4? Kicad makes a bitmask for copper layer 4 and then compares its (mask and match) to every feature on the board just to get the list of whats currently on copper layer 4. What I do: when the feature is defined to exist on copper layer 4, I add it to the copper layer 4 LAYER_SET. Want to know whats on copper layer 4 now? Just iterate over the copper layer 4 layer set. Kicad must first assemble the set on each request, and then throws it away after each request. It must still iterate over the set. I just iterate over the set because it is always assembled. I save all the masking operations. Want to generate a Gerber for copper layer 4? Just iterate. No masking required. > > funner stuff was the simulated annealing for location of items in the > > vicinity of another. > > ? What would be that for ? hit testing or drc? and why annealing instead > of a circular sweep or similar? Because you can't precalculate a circular sweep. The same as layers is true for locality. Want to know what is close to board item 14951? Kicad compares its geometrical distance to EVERY OTHER ITEM ON THE BOARD, EACH TIME! Using crude integer math none the less. What I do: break the board into cells. When an item is placed on the board it is added to the set of items of the cells which it occupies. Want to know what's close to board item 14951? Use the union of the members of the set of cells a clearance distance from its shape (precalculated when it is placed) and simply iterate over the union. Then do full blown floating point math on this (often empty) set to calculate exact clearances. Performing a union of sets of layers and cells you can find what is close on adjacent layers without masking a without integer math calculations. Performace: way faster. Improvements over 100 fold. Memory footprint: somewhat larger. But lots of memory is much cheaper than more faster processors. --brian -- Brian F. G. Bidulock� The reasonable man adapts himself to the � bidul...@openss7.org� world; the unreasonable one persists in � http://www.openss7.org/ � trying to adapt the world to himself. � � Therefore all progress depends on the � � unreasonable man. -- George Bernard Shaw � ___ 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] Experiments and considerations for more layer
- Original Message - > From: Lorenzo Marcantonio > To: Kicad Developers > Cc: > Sent: Tuesday, September 3, 2013 8:51 PM > Subject: Re: [Kicad-developers] Experiments and considerations for more > layer > > On Tue, Sep 03, 2013 at 03:41:26AM -0600, Brian F. G. Bidulock wrote: >> Mid-term in the wrong direction. Kicad is like that... > > Look. I have this board due to fabrication for the end of month. > I simply can't implement the whole object model in time *and* do the > board layout to produce it. > > It's a human resource allocation problem :D it's a temporary solution > but *it works*; the optimal solution is not useful if it's not available > for use. > > The kicad object model is not perfect (and anyway everyone has its own > idea of perfect model), but kicad itself is not exactly small. Probably > only you and me know exactly how many time a layer type is > used/iterated/converted in pcbnew:P > > Also if you remember even my type cleanup was partially rejected > becaused they wanted to keep layers as 'simple integer'. And if was > actually a little more than a typedef. A mergeable layerset > implementation would require a full layer class and other objects (as > you said, correctly), but I simply don't think that would be accepted by > the 'steering commitee' of kicad:P I don't like, too, the asymmetry > between the board layer structure (renameable) and the module one (the > 'standard english'). Going generic requires a pervasive layer container > (call it stackup or whatever) and layers would then coordinate with > their own container, or something like that. > A down side to keeping things manageable (such as merging components into the PCB) would be that there has to be a mapping which KiCAD enforces for the integer layer ID and the usage. That is certainly possible and when implemented I suspect the biggest nuisance would be to people who use custom layers - but even that can be addressed by reserving a block of IDs which KiCAD will never use in the main tree. Time is certainly the biggest thing; it would be great if we had corporate sponsors so people could dedicate their time to the code. I have so much free time that I haven't even been able to implement some rather simple features on the VRML export. Oh well, at least I managed to fix some simple bugs in the VRML code all those months ago when we moved to nanometer units. It would be a great shame if Brian's work didn't eventually merge back into the main tree; I suspect that staging the changes would be at least one full time job though. I was thinking of what minimal implementation of IDF3 import would be of use in KiCAD and I didn't realize that Brian had implemented enough new features to support all of IDF3 and much more. - Cirilo ___ 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] Experiments and considerations for more layer
On Tue, Sep 03, 2013 at 04:38:13AM -0600, Brian F. G. Bidulock wrote: > You don't need list of layers: just from and to--a pair. How do you fit mask, silk and other technical layers in a range? I agree that it would work for copped layers. But IMHO the 'right' solution would be to have a pin object containing it's instances for each layer i.e. Pin 1 Pin 1 on front Pin 1 on inner 1 Pin 1 on inner 2 Pin 1 on back Pin 1 on silk front Pin 1 on mask front Pin 1 on mask back Pin 1 on assembly front Pin 1 on assembly back That would allow you to have 'true' padstacks. Vias of course could remain range based (unless you wanted to personalize via by layers, that could be overkill) -- 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] Experiments and considerations for more layer
On Tue, Sep 03, 2013 at 03:35:16AM -0700, Cirilo Bernardo wrote: > That may be the case, but personally I would have preferred to treat that as > being a different component with its own footprint, even if it ultimately > refers to the same part number on the BoM. So many copies doesn't make much > sense to me - not even for a few hundred components. That's a design decision which AFAIK was taken at the birth of pcbnew. I don't think is a bad one because in practice it works fine (yes, gencad output has repeated the same part forever, but never had a problem with that). The instantiated vs copied issue is old like IT, I think:P files can be copied or linked... even in OOP there are class based systems and prototype based systems. Both have their good and bad qualities. Ideally kicad modules would be shared with copy on write (i.e. automatically define a new footprint on modification). Like memory on fork. To be implemented in our copious free time :D -- 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] Experiments and considerations for more layer
On Tue, Sep 03, 2013 at 03:41:26AM -0600, Brian F. G. Bidulock wrote: > Mid-term in the wrong direction. Kicad is like that... Look. I have this board due to fabrication for the end of month. I simply can't implement the whole object model in time *and* do the board layout to produce it. It's a human resource allocation problem :D it's a temporary solution but *it works*; the optimal solution is not useful if it's not available for use. The kicad object model is not perfect (and anyway everyone has its own idea of perfect model), but kicad itself is not exactly small. Probably only you and me know exactly how many time a layer type is used/iterated/converted in pcbnew:P Also if you remember even my type cleanup was partially rejected becaused they wanted to keep layers as 'simple integer'. And if was actually a little more than a typedef. A mergeable layerset implementation would require a full layer class and other objects (as you said, correctly), but I simply don't think that would be accepted by the 'steering commitee' of kicad:P I don't like, too, the asymmetry between the board layer structure (renameable) and the module one (the 'standard english'). Going generic requires a pervasive layer container (call it stackup or whatever) and layers would then coordinate with their own container, or something like that. In short, I perfectly agree with you but I don't think is feasible to propose such a big change (which is mostly a management issue). I almost got lynched when I proposed switching to enums from #defines.. (reason: you have to type the containing namespace, too) > If you consider gcc-specific features a standard... int64_t is ISO C++, not gcc. long long is a gcc extension, but AFAIK gcc is the only target for kicad on all platforms. > converted back. std::set was used to represent an arbitrary set of I tought about std::vector, std::set<'int'> is a little slower but good anyway (would be more useful if layer numbers were sparse). Lack of literals would need the introduction of a quantity of predicates, but it's doable. Many of these predicates are already there, anyway... > funner stuff was the simulated annealing for location of items in the > vicinity of another. ? What would be that for ? hit testing or drc? and why annealing instead of a circular sweep or similar? -- 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] Experiments and considerations for more layer
Lorenzo, On Tue, 03 Sep 2013, Lorenzo Marcantonio wrote: > I do not agree on that. Everything that's related to a pad need to be > masked. Unless you add a list of layers, which is just another > (less efficient) representation for a bitmask. Or esplode the pad in > multiple instances to represent a padstack (that would be the cleanest > solution, given some backpointer to correlate them). > > But of course that would be a massive modification. You don't need list of layers: just from and to--a pair. --brian -- Brian F. G. Bidulock� The reasonable man adapts himself to the � bidul...@openss7.org� world; the unreasonable one persists in � http://www.openss7.org/ � trying to adapt the world to himself. � � Therefore all progress depends on the � � unreasonable man. -- George Bernard Shaw � ___ 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] Experiments and considerations for more layer
- Original Message - > From: Lorenzo Marcantonio > To: Kicad Developers > Cc: > Sent: Tuesday, September 3, 2013 8:26 PM > Subject: Re: [Kicad-developers] Experiments and considerations for more layer > > On Tue, Sep 03, 2013 at 04:21:59AM -0600, Brian F. G. Bidulock wrote: >> 5000 module descriptions to extract the 5000 pieces of placement >> data is the horror of kicad's internal representation. > > There is a reason for components being copied and not instantiated. > > Often you need to 'tweak' a component, slimming or fattening a pad, or > removing unusing fixture holes. > > So your 5000 capacitors are not necessarily all the same! > > -- > Lorenzo Marcantonio > Logos Srl > That may be the case, but personally I would have preferred to treat that as being a different component with its own footprint, even if it ultimately refers to the same part number on the BoM. So many copies doesn't make much sense to me - not even for a few hundred components. - Cirilo ___ 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] Experiments and considerations for more layer
Lorenzo, On Tue, 03 Sep 2013, Lorenzo Marcantonio wrote: > On Tue, Sep 03, 2013 at 04:21:59AM -0600, Brian F. G. Bidulock wrote: > > 5000 module descriptions to extract the 5000 pieces of placement > > data is the horror of kicad's internal representation. > > There is a reason for components being copied and not instantiated. > > Often you need to 'tweak' a component, slimming or fattening a pad, or > removing unusing fixture holes. > > So your 5000 capacitors are not necessarily all the same! But they are the same. Only an fool copies something 5000 times in preparation for the never occuring eventuality of modifying one of them: the code to copy when modification is demanded is trivial. But it is an apt indication of the pond-scum maturity of the code base. --brian -- Brian F. G. Bidulock� The reasonable man adapts himself to the � bidul...@openss7.org� world; the unreasonable one persists in � http://www.openss7.org/ � trying to adapt the world to himself. � � Therefore all progress depends on the � � unreasonable man. -- George Bernard Shaw � ___ 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] Experiments and considerations for more layer
On Tue, Sep 03, 2013 at 03:41:26AM -0600, Brian F. G. Bidulock wrote: > a layer number is a copper layer or not. For things like holes, range > comparisons are done mostly and bitmasks are useless. For non-copper I do not agree on that. Everything that's related to a pad need to be masked. Unless you add a list of layers, which is just another (less efficient) representation for a bitmask. Or esplode the pad in multiple instances to represent a padstack (that would be the cleanest solution, given some backpointer to correlate them). But of course that would be a massive modification. -- Lorenzo Marcantonio Logos Srl smime.p7s Description: S/MIME cryptographic 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
Re: [Kicad-developers] Experiments and considerations for more layer
On Tue, Sep 03, 2013 at 04:21:59AM -0600, Brian F. G. Bidulock wrote: > 5000 module descriptions to extract the 5000 pieces of placement > data is the horror of kicad's internal representation. There is a reason for components being copied and not instantiated. Often you need to 'tweak' a component, slimming or fattening a pad, or removing unusing fixture holes. So your 5000 capacitors are not necessarily all the same! -- 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] Experiments and considerations for more layer
Cirilo, On Mon, 02 Sep 2013, Cirilo Bernardo wrote: > Hi Brian, > > It looks like an awful lot of work you've done there. Has any of > it made its way back into the main tree? None. I hear you guys might have got internal units done after three years. > I'm also interested in knowing the extent of the work you did with > IDF. A number of people on the users' list have said that they need > IDFv3 import since their clients send them IDF files. I'm convinced > now that IDF export is also essential; some of my clients have sent me > PCB mechanical data as IDFv3 which I then import into SolidWorks and > tweak. Although I still plan to use FreeCAD to create actual > mechanical assemblies which can be sent to mechanical people in STEP > format, IDF is far more compact even though no fine details are > possible and a number of people have told me they only want IDF and > nothing more. I roughed out IDF2, IDF3 and even the oft-unused IDF4. The major problem was with representation within kicad. The BoardOutline, RouteOutline and even PlaceOutline was easy enough, but the RouteKeepout, ViaKeepout, PlaceKeepout, PlaceRegion, Electrical, Mechanical, DrilledHoles, Notes and Placement sections were unrepresentable given than kicad considers all these things in 2 dimensions and on two layers silk-front and silk-back. I considered getting some of the 3D shapes from the VRML files for each module, but with no model for 3D keepouts and keepins they could not be tested for proper placement. kicad could not even represent a simple non-plated mechanical hole, far less the way what IDF needs it. I don't even want to talk about the thermal (see section 3.6.10). Parsing and generating the file format is easy enough. The problem was that when your look into kicad for where to store or retrieve the data for the format, it simply isn't there and the internal model is insufficient for simply adding it in the baby-steps incrementation fashion that its maintainers prefer. Even where the data is there, it is usable. If you have 5000 1pF 0402 ceramic capacitors, IDF describes these 5000 capacitors once and refers to the description 5000 times with placement data. Kicad repeats the data for each an every instance of a board item in its file and internally, there are 5000 full module descriptions for each capacity resplendent with comingled placement data. Matching 5000 module descriptions to extract the 5000 pieces of placement data is the horror of kicad's internal representation. The biggest deal?--in kicad components have no height, all fit within their silk, never overlap or protrude, never pass through or into the board, generate no heat, an, as above, are all considered unique. Basically anything that IDF supports that SPEECTRA DSN doesn't support is unrepresentable. Most of what SPEECTRA DSN does support is still unrepresentable in kicad. Read section 5.6 on keep-out layers for some notes on my trials and tribulations. I really wish gEDA wasn't such an emacs clone. --brian -- Brian F. G. Bidulock� The reasonable man adapts himself to the � bidul...@openss7.org� world; the unreasonable one persists in � http://www.openss7.org/ � trying to adapt the world to himself. � � Therefore all progress depends on the � � unreasonable man. -- George Bernard Shaw � ___ 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] Experiments and considerations for more layer
Lorenzo, On Tue, 03 Sep 2013, Lorenzo Marcantonio wrote: > On Mon, Sep 02, 2013 at 08:55:31PM -0600, Brian F. G. Bidulock wrote: > > that's another 26 (or more) layers. Still think 64 will be > > enough? > > I said it was a mid-term solution. Mid-term in the wrong direction. Kicad is like that... > > BTW, long long is part of the C standard and excluded from the C++ > > standard. Good luck with Windows (it doesn't support it in C++). > > int64_t is in the standard. And mingw supports long long on windows > anyway... If you consider gcc-specific features a standard... > > The best approach is to make the layer a full class and only use > > accessor functions, or overload the bitwise logical and arithmetic > > operators. I did that, but nobody was interested at the time. > > If you re-read my first message that would be the long term plan anyway. > How did you represent literals? What about the missing compiler > folding? These things are used a lot, there could be performance > implications. If you take a look, most bitmask comparisons are determining whether a layer number is a copper layer or not. For things like holes, range comparisons are done mostly and bitmasks are useless. For non-copper layers, most comparisons are identity comparisons. I used a simple pair (m_class and m_index) for a layer identifier. A pair of layer identifiers for vias and such . The index is -1 for back, 0 for front, and 1 through 2^31-1 for internal layers. The layer class was an enumeration (Copper, Dielectric, ...). A layer pair is a simple std::pair of layers. Checking whether a item is on a copper layer is as simple a comparing its m_class to LayerClass::Copper, just as fast as a masking operation: faster than int64_t mask on 32-bit archs. For conversion a const int& constructor for LAYER_ID converted from the old 32-bit #defines. An operator int() conversion operator converted back. std::set was used to represent an arbitrary set of layers with operator| operator|= operator& operator&= operator< operator>, etc. overloads. For performance, a small set of often used methods perform much better than little inline operations in untold thousands of places. This was necessary not just to add layers, but to represent concepts (such as etched resistance layers, 3D keepouts for IDF, hole filling, plating and finish layers, and many other things) that kicad is incapable of representing: thus it is incapable of generating proper GenCAD, GenX, Offspring output for anything but hobby boards. My old branch from three years ago should still be on launchpad. Look in include/class_layer*.h there is lots of inline documentation. The funner stuff was the simulated annealing for location of items in the vicinity of another. --brian -- Brian F. G. Bidulock� The reasonable man adapts himself to the � bidul...@openss7.org� world; the unreasonable one persists in � http://www.openss7.org/ � trying to adapt the world to himself. � � Therefore all progress depends on the � � unreasonable man. -- George Bernard Shaw � ___ 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] Experiments and considerations for more layer
- Original Message - > From: Brian F. G. Bidulock > To: Kicad Developers > Cc: > Sent: Tuesday, September 3, 2013 12:55 PM > Subject: Re: [Kicad-developers] Experiments and considerations for more > layer > > Lorenzo, > > While your thinking about additional layers, consider the other > layers discussed here: > > http://www.openss7.org/docs/NOTES.pdf > > namely, > > dielectric layers > resistance layers > plating layers > hole filling layers > keep-out layers > via plugging layers > contacts layers > peelable mask layers > finish layers > heat sink layers > coating layers > probe layers > fixture layers > > that's another 26 (or more) layers. Still think 64 will be > enough? > > Check section 2.6 (Layers) on page 13 for definitions of these > layers. > > BTW, long long is part of the C standard and excluded from the C++ > standard. Good luck with Windows (it doesn't support it in C++). > > The best approach is to make the layer a full class and only use > accessor functions, or overload the bitwise logical and arithmetic > operators. I did that, but nobody was interested at the time. > > --brian > > -- Hi Brian, It looks like an awful lot of work you've done there. Has any of it made its way back into the main tree? I'm also interested in knowing the extent of the work you did with IDF. A number of people on the users' list have said that they need IDFv3 import since their clients send them IDF files. I'm convinced now that IDF export is also essential; some of my clients have sent me PCB mechanical data as IDFv3 which I then import into SolidWorks and tweak. Although I still plan to use FreeCAD to create actual mechanical assemblies which can be sent to mechanical people in STEP format, IDF is far more compact even though no fine details are possible and a number of people have told me they only want IDF and nothing more. - Cirilo ___ 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] Experiments and considerations for more layer
On Mon, Sep 02, 2013 at 08:55:31PM -0600, Brian F. G. Bidulock wrote: > that's another 26 (or more) layers. Still think 64 will be > enough? I said it was a mid-term solution. > BTW, long long is part of the C standard and excluded from the C++ > standard. Good luck with Windows (it doesn't support it in C++). int64_t is in the standard. And mingw supports long long on windows anyway... > The best approach is to make the layer a full class and only use > accessor functions, or overload the bitwise logical and arithmetic > operators. I did that, but nobody was interested at the time. If you re-read my first message that would be the long term plan anyway. How did you represent literals? What about the missing compiler folding? These things are used a lot, there could be performance implications. -- 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] Experiments and considerations for more layer
Lorenzo, While your thinking about additional layers, consider the other layers discussed here: http://www.openss7.org/docs/NOTES.pdf namely, dielectric layers resistance layers plating layers hole filling layers keep-out layers via plugging layers contacts layers peelable mask layers finish layers heat sink layers coating layers probe layers fixture layers that's another 26 (or more) layers. Still think 64 will be enough? Check section 2.6 (Layers) on page 13 for definitions of these layers. BTW, long long is part of the C standard and excluded from the C++ standard. Good luck with Windows (it doesn't support it in C++). The best approach is to make the layer a full class and only use accessor functions, or overload the bitwise logical and arithmetic operators. I did that, but nobody was interested at the time. --brian -- Brian F. G. Bidulock� The reasonable man adapts himself to the � bidul...@openss7.org� world; the unreasonable one persists in � http://www.openss7.org/ � trying to adapt the world to himself. � � Therefore all progress depends on the � � unreasonable man. -- George Bernard Shaw � ___ 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] Experiments and considerations for more layer
On Mon, Sep 02, 2013 at 08:53:45PM +0200, jp charras wrote: > After reading mails about layers, I am happy you have *actually* the > same opinion as Dick about the fact non copper layer names cannot be > changed: I agree in avoiding renaming tech layers which have a special function (like mask and silk). However user draft only could be usefully renamed *if* some kind of merge is handled. Which is difficult (and you agree on that). What I asked in the past was a user-seen only 'cosmetic' change at the board level (i.e. on *this* board ECO1 is a keepout, but for all the world it's still ECO1). In short only changing the user visible name (the module editor would *still* show ECO1). > There are very non trivial issues if they are renamed, because a > footprint lives in a footprint library, therefore outside a board, > and layer names live in a given board, and differs from a board to > an other board. Exactly what I meant. However extra 'customizable' layers would be useful only if allowed in module (for example for keepouts), so that limitation would make useless the extension (the no board edge in module rule is already a nuisance for people doing card edges and similar things). > Therefore, as you said, how to match a renamed layer in a board, > with a renamed layer in a footprint, many times created by an other > guy, for an other board? (example: ECO1 name top_courtyard in a > board, and ECO1 renamed silk_screen_aux in a footprint) Some kind of runtime translation would be needed, which is difficult to do. Some kind of layerset object handling the conversion would be needed and a lot of thing would need changes (apparently trivial example: when instantiating a component the library layers would need to be translated to the board one *and then back around* from the board to the library editor). The layers in a layer set would be allocated on an as-needed base and then the various entities would be 'moved' to the right layer. It's actually more difficult than it seems (also it's a *very* invasive modification) > And what about board merging ?. Same algorithm as before (in fact each module would be a 'board' in itself). I agree it would be a mess to implement, but I don't see another way to do it. > Note: Copper layers can be renamed because pads know only 3 cases: > top layer, bottom layer, or all layers, which do not create issues > relative to copper layer names, or copper layer count. > From this point of view, Pad stacks are a serious issue, when > defined in libraries. Defining a pad stack in a library doesn't make a lot of sense, the pad stack is on the final board... from the library side I would only define attributes for: - Component side - Inner layers (could be usefully divided in 'plane' and 'signal', since we have the attribute for the specctra exporter). - 'Other' side Rationale: on the component side there is the capillary joint (for THT), on the other side there is the main (wave) joint. Clearance in inner layer is often different (for technology reason), and somebody likes to handle planes differently from signal layers (no idea why... aren't they pressed in the same way at the end?) In short the same, say, connector could be used in various stackups, and it isn't possibile to specify in the library 'on inner 2' since it could be a power plane, or a signal layer or maybe even not exist. Inner pad removal is yet another 'controversial' feature. These should be pad-by-pad modification issued on the instanced footprint, not on the library source (when editing a pad in the board a full copper layer mask could be edited for that, for example; ideally each layer should have its pad parameters but the current data structure can't handle that) Padstacks aside, I looked over how Altium handle the thing (more knowledgeable user can correct me): - Copper: Top+Bottom+30 inner signal layer; we have 14, enough for now:P 16 planes (we don't handle them) - Silk, solder, paste: Top+Bottom (obviously!) - 'Drafting' layers: 32 mechanical layers, pairable (like adhesive) - Drill drawing and drill master: we generate it on the fly during plot - Keep out layer: we do it with zones (more or less) - Multi layer: strange thing... I think it is an internal artifact for handling thru vias, can't see another good use for it. All of the 'generic' things are done with the mechanical layers, it seems... the tutorial has a screenshot of the spectacular Board Layers & Colors dialog (that thing is *huge*), so their 'mechanical' layers cover our: adhesives, drawing, comments, eco1, eco2, assembly, courtyard and so on. The 3D models is stored aside... AFAIK the courtyard as a special layer is more a Mentor-only concept (and it's mostly for human consumption, even if a DRC could be usefully done on it). If I get it correctly, what Brian is asking for is the support for the Altium 'mechanical' layers. From what I reckon from the doc these are handled by number and named/paired at the board level
Re: [Kicad-developers] Experiments and considerations for more layer
Le 02/09/2013 13:47, Lorenzo Marcantonio a écrit : On Mon, Sep 02, 2013 at 12:13:07PM +0100, Brian Sidebotham wrote: Actually, I think I want to change my answer a bit. Because as I hinted, I don't need more layers, I need better layer versatility. I want to be able to rename layers (Already achievable!), but I also want to be able to Well... *not*, you can only rename copper layers because Dick said so. And threatened to well... don't remember exactly but probably most painful if somebody suggested to do otherwise. Something about how he preferred to read the board file or such. Read the list archives, I forgot the details. So ECO1 remains ECO1, even if you use it for mechanical clearance. All I really want to be able to do is assign names and properties to layers. How KiCad arranges most of these layers within it's 32 layer limit is not really my concern. Only the copper layer stack order is important, and we already had identifiers for these in the new file formats so that we can select all copper layers (regardless of the number of layers in the current design). There are non-trivial issues when merging board or inserting a module with a different layer usage, in that case. Nothing unmanageable but a complex thing nonetheless... I think this has merit as opposed to simply fixing the number of layers to a higher number and then assigning static layer numbers specific uses. It would be much more versatile to have the additional properties for each layer and to let KiCad fit them however it sees fit into the maximum number of layers it can handle. Something like that was already proposed in the past. We would need a layerset container for that to work, containing pairing and stuff. That's because a board uses a layerset but the modules could use another one. The current situation is: the board uses 'the user layerset' i.e. the one with renamed copper layers and the rest of the world uses the 'standard english' layerset; since there is a 1:1 relationship and the indexing is the same there is nothing to do to switch between them; the situation would change with your proposal. Also, that copper layers are 16 and consecutive in numbering is *not* an easy thing to change (there are lot of for FRONT to BACK loop inside, requiring consecutive ordering), unless we do some heavy operator overloading on the layer types. So at the moment we have - Copper front + 14 inner + bottom (fixed and not easily changeable) - Board edges (very special) - Special technical layers (needing ad hoc code to handle): mask, silk, paste, (assembly, courtyard). Silk is actually special because it has custom plotting rules. Paste and mask have the enlarging rules. Courtyards could have a DRC check and assembly has a special plotting rule, too (the 'reference to origin' one). - 'Other' layers: the adhesives have nothing special, other that they are listed in the pad dialog. Drawing, comments and ECO are, by design, user layers. Leaving aside the 'specials' and copper layers, you could generalize and parametrize all the other layers (adding them to pads and pairing, in other words). Given that 64 layers are easily available that should make you happy (without touching the copper layer relationship/ordering). In short, adhesives, drawing, comment and ECOs would be 'user defined layers' and the current situation would be a useful default or something like that. Of course that would need a *huge* UI rework (a new stackup dialog and dynamic generation of other layer lists) and provision for merging etherogeneous layersets (maybe even a bigger work). More layers is certainly a serious enhancement, and mainly courtyear layers. After reading mails about layers, I am happy you have *actually* the same opinion as Dick about the fact non copper layer names cannot be changed: There are very non trivial issues if they are renamed, because a footprint lives in a footprint library, therefore outside a board, and layer names live in a given board, and differs from a board to an other board. Therefore, as you said, how to match a renamed layer in a board, with a renamed layer in a footprint, many times created by an other guy, for an other board? (example: ECO1 name top_courtyard in a board, and ECO1 renamed silk_screen_aux in a footprint) And most of tech layers having a special meaning, renaming them is very dangerous. Just remember the lot of issues due to layer names translations. Obviously, unless you have a *very good* idea, I know only 2 way: - Do not accept the tech layer renaming (This is what Dick made) - Accept layer renaming, but do not accept use of tech layer in footprint, for layers which can be renamed (currently does not exists in Pcbnew). I'll be happy to know other ways. Renaming layers like silkscreen, or solder paste, is something like renaming a board.kicad_pcb to board.ps, send it to your PS printer, and expecting it will be printed. And what about board merging ?. No
Re: [Kicad-developers] Experiments and considerations for more layer
On Mon, Sep 02, 2013 at 12:13:07PM +0100, Brian Sidebotham wrote: > Actually, I think I want to change my answer a bit. Because as I hinted, I > don't need more layers, I need better layer versatility. I want to be able > to rename layers (Already achievable!), but I also want to be able to Well... *not*, you can only rename copper layers because Dick said so. And threatened to well... don't remember exactly but probably most painful if somebody suggested to do otherwise. Something about how he preferred to read the board file or such. Read the list archives, I forgot the details. So ECO1 remains ECO1, even if you use it for mechanical clearance. > All I really want to be able to do is assign names and properties to > layers. How KiCad arranges most of these layers within it's 32 layer limit > is not really my concern. Only the copper layer stack order is important, > and we already had identifiers for these in the new file formats so that we > can select all copper layers (regardless of the number of layers in the > current design). There are non-trivial issues when merging board or inserting a module with a different layer usage, in that case. Nothing unmanageable but a complex thing nonetheless... > I think this has merit as opposed to simply fixing the number of layers to > a higher number and then assigning static layer numbers specific uses. It > would be much more versatile to have the additional properties for each > layer and to let KiCad fit them however it sees fit into the maximum number > of layers it can handle. Something like that was already proposed in the past. We would need a layerset container for that to work, containing pairing and stuff. That's because a board uses a layerset but the modules could use another one. The current situation is: the board uses 'the user layerset' i.e. the one with renamed copper layers and the rest of the world uses the 'standard english' layerset; since there is a 1:1 relationship and the indexing is the same there is nothing to do to switch between them; the situation would change with your proposal. Also, that copper layers are 16 and consecutive in numbering is *not* an easy thing to change (there are lot of for FRONT to BACK loop inside, requiring consecutive ordering), unless we do some heavy operator overloading on the layer types. So at the moment we have - Copper front + 14 inner + bottom (fixed and not easily changeable) - Board edges (very special) - Special technical layers (needing ad hoc code to handle): mask, silk, paste, (assembly, courtyard). Silk is actually special because it has custom plotting rules. Paste and mask have the enlarging rules. Courtyards could have a DRC check and assembly has a special plotting rule, too (the 'reference to origin' one). - 'Other' layers: the adhesives have nothing special, other that they are listed in the pad dialog. Drawing, comments and ECO are, by design, user layers. Leaving aside the 'specials' and copper layers, you could generalize and parametrize all the other layers (adding them to pads and pairing, in other words). Given that 64 layers are easily available that should make you happy (without touching the copper layer relationship/ordering). In short, adhesives, drawing, comment and ECOs would be 'user defined layers' and the current situation would be a useful default or something like that. Of course that would need a *huge* UI rework (a new stackup dialog and dynamic generation of other layer lists) and provision for merging etherogeneous layersets (maybe even a bigger work). -- 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] Experiments and considerations for more layer
On 2 September 2013 10:39, Lorenzo Marcantonio wrote: > On Mon, Sep 02, 2013 at 10:30:47AM +0100, Brian Sidebotham wrote: > > I could really do with more layers too. Although when I say *more* > layers, > > I mean that I could really do with dedicated assembly and courtyard > layers. > > Exactly what I have done... probably for your same reasons, too. > > > The assembly layer needs the reference field on, as you say, at the > > insertion point of the component as well as a physical bounding box; This > > should flip when the component is flipped. > > Exactly, I added the courtyard front/back and assembly front/back, > because this time I have a dual sided assembly. > > Drawing on assembly without the ability of turning off the silk > however is painful. Well, the whole module editor become painful when > you don't draw only on silk top. > > Actually, I think I want to change my answer a bit. Because as I hinted, I don't need more layers, I need better layer versatility. I want to be able to rename layers (Already achievable!), but I also want to be able to change a layer to mechanical, or non-copper if that's what my design requires. 32-layers is really more than enough for almost any board manufacturable. All I really want to be able to do is assign names and properties to layers. How KiCad arranges most of these layers within it's 32 layer limit is not really my concern. Only the copper layer stack order is important, and we already had identifiers for these in the new file formats so that we can select all copper layers (regardless of the number of layers in the current design). So a layer in a module could just be a name that is then assigned to a layer "number", or bitfield positon inside KiCad. Along with some properties in the PCB KiCad would know whether this layer is paired with any other layer and whether the layer is copper or not. I think this has merit as opposed to simply fixing the number of layers to a higher number and then assigning static layer numbers specific uses. It would be much more versatile to have the additional properties for each layer and to let KiCad fit them however it sees fit into the maximum number of layers it can handle. Perhaps I've not explained this too well, it is more a brain storm rather than anything else - but it appears to stack up well against forever increasing the width of a bitfield integer. But there would be plenty of things to think about with regards to spelling differences and abbreviations, etc. of layer names. Some sort of equivalence between layer names in modules and PCB layout might be needed. Best Regards, Brian. ___ 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] Experiments and considerations for more layer
On Mon, Sep 02, 2013 at 03:45:23AM -0700, Cirilo Bernardo wrote: > Using IDF also gives us another method of specifying the board outline, but > to be honest the specification has severe defects; for example, arcs are not > correctly constrained so for any arc specified in IDF there are 4 different > ways to draw the arc if we assume a circular arc; for elliptical arcs there > are an infinite number of ways to draw the arc and every single one will > conform to the standard as written. AFAIK IDF is generally used only from ECAD to MCAD, even if it's designed to work both ways. The IPC standard will explicitly add a 'mechanical outline' layer for IDF generation and most probably provisions for attaching a STEP model. However it isn't out yet, but the pattern calculator already generates it (on screen, I don't have licenses for the CAD exporters). I see two problems generating IDF3: 1) correctly finding polygon loops (more or less like for the SPECCTRA board border) and 2) height values; AFAIK the eagle people hack the line width to represent height; a similar special arrangement could be done for the 'body model outline' layer, used for IDF generation. As for the arcs, well, we should fix before the 90 degrees limitation (and do anyone actually use elliptic arcs?) > Nice work Lorenzo. As for how many layers we can ultimately use, I imagine at > least twice as many as the copper layers in a pathological case thanks to > things like 'no route' areas underneath ICs. But with 64 layers total I think > we'll be safe for a long time. We can't raise the copper layer number without breaking things (i.e. renumber layers); IMHO whoever needs to use more than 16 coppers probably should use something more advanced than pcbnew at the moment :P We need *at least* a more complete padstack model to correctly handle modern HDI assemblies... at least different antipads (call them clearances, if you want) for internal layers and even more control for thermals. And of course a script for fanning out BGAs :P The layer increase project (started more than a year ago, IIRC) is more to enable more auxiliary/technical layers (courtyard, assembly, mechanical and electrical clearance to name few), and maybe more user comment layers. -- 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] Experiments and considerations for more layer
On Mon, 9/2/13, Brian Sidebotham wrote: Subject: Re: [Kicad-developers] Experiments and considerations for more layer To: "Kicad Developers" Date: Monday, September 2, 2013, 5:30 PM On 2 September 2013 10:02, Lorenzo Marcantonio wrote: At last I tried to broke the 32 layer barrier in pcbnew. Needed the assembly and courtyard on both sides, so the ECO are not enough. Also they need to be flippable, too. Result: succesful, learnt things that could be useful later. [snip] -- Lorenzo Marcantonio Logos Srl Hi Lorenzo, I could really do with more layers too. Although when I say *more* layers, I mean that I could really do with dedicated assembly and courtyard layers. The assembly layer needs the reference field on, as you say, at the insertion point of the component as well as a physical bounding box; This should flip when the component is flipped. Thanks for spending the time investigating it, because I'll sure be glad of any work that goes into supporting these layers. Best Regards, Brian. = While we're on the topic of layers, is anyone interested in IDF3.0 import/export? I was thinking of implementing it since I'll have a little free time in the next few months. If I implement it I'd like to draw regions on a top and bottom 'mechanical keepout' layer. Alternatively I guess I could create a hatched region or some such on the silk layers but I'd rather not pollute the silks. The IDF specification allows TOP, BOTTOM, or BOTH specifications for the keepout; there is also a height (0 = absolutely nothing can go there, >0 means max. height of components) but I don't see how height restrictions can be supported in KiCAD nor is it the responsibility of the ECAD to handle this. I see the mech. keepout as merely a reminder to the layout designer that there are mechanical restrictions within certain regions; it is the responsibility of the mechanical drafter to provide all relevant information in other documents. Using IDF also gives us another method of specifying the board outline, but to be honest the specification has severe defects; for example, arcs are not correctly constrained so for any arc specified in IDF there are 4 different ways to draw the arc if we assume a circular arc; for elliptical arcs there are an infinite number of ways to draw the arc and every single one will conform to the standard as written. Nice work Lorenzo. As for how many layers we can ultimately use, I imagine at least twice as many as the copper layers in a pathological case thanks to things like 'no route' areas underneath ICs. But with 64 layers total I think we'll be safe for a long time. - Cirilo ___ 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] Experiments and considerations for more layer
On Mon, Sep 02, 2013 at 10:30:47AM +0100, Brian Sidebotham wrote: > I could really do with more layers too. Although when I say *more* layers, > I mean that I could really do with dedicated assembly and courtyard layers. Exactly what I have done... probably for your same reasons, too. > The assembly layer needs the reference field on, as you say, at the > insertion point of the component as well as a physical bounding box; This > should flip when the component is flipped. Exactly, I added the courtyard front/back and assembly front/back, because this time I have a dual sided assembly. Drawing on assembly without the ability of turning off the silk however is painful. Well, the whole module editor become painful when you don't draw only on silk top. > Thanks for spending the time investigating it, because I'll sure be glad of > any work that goes into supporting these layers. IMHO time should be spend thinking about a generic layer solution; at the moment sadly there is too much UI code (form definitions, too) with the layer list embedded. For now at least it solves the problem and opens a medium-term solution for expandibility. Going over 64 layers has significant consequences for the code base, however (do we really need it?). -- Lorenzo Marcantonio Logos Srl smime.p7s Description: S/MIME cryptographic 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
Re: [Kicad-developers] Experiments and considerations for more layer
On 2 September 2013 10:02, Lorenzo Marcantonio wrote: > At last I tried to broke the 32 layer barrier in pcbnew. Needed the > assembly and courtyard on both sides, so the ECO are not enough. Also > they need to be flippable, too. > > Result: succesful, learnt things that could be useful later. > > First, the huge LAYER_NUM/LAYER_MSK work I done previously was in the > right direction. Once I coerced the compiler to use 64 bits for the > mask, it worked flawlessly (yay!). First trouble: in 32 bit arch that > would be a long long int (or int64_t), on 64 bit arch simply a long int > (still int64_t). Handling it as an enum (by the standard) make the > compiler choose these types. Cue printf format issues and related > warnings. New C++ has a "class enum LAYER_MSK : uint64_t" to force the > choice but it also put the enum values in the enum namespace, so you > have to type LAYER_MSK::FRONT_LAYER instead of simply FRONT_LAYER. > Technically useful, but hugely unconvenient. > > 90% of the modifications had to be done in the layer include and > pcbcommon source (obviously). The flipping thing is there too, worked at > the first try(of course, that meant recompiling 90% of pcbnew:P) > > On the UI side: most painful the stackup dialog; I'm not a wxformbuilder > expert but at the end the fastest thing was to hand edit the xml! That > dialog would be a lot of fun to generate dynamically IMHO. Also the > layer bar needed the obvious add, but nothing painful. Side note: the > layer bar is *not* scrollable, so lots of layers could be an issue, > there. The pad box would need change if we wanted pads on some new > layer, of course (but these would be probably 'special' technical layer, > anyway, so they would need special code). > > Other (minor) issue: the layer chooser (used for example in the module > editor) works with a range and the code relies on it to exclude the > board edges from the selection. That broke adding new layers (since the > edge is not anymore the last). The 'right' way to fix it would be using > a mask instead of a range (I keep the range broken, for now:D) > > Other side issues: the module editor would really need better layer > control, especially for visibility. Ideally the layer sidebar could be > grafted to it but I fear it relies on a board (for showing the user > names instead of the standard names). Also layer control for text fields > in modules would be very useful (the file format already handles it and > IIRC there are not many things to change in the rest of pcbnew). > Semantic for the 'show text front/back' would need clarification > obviously. > > Didn't try a plot yet, but I think it wouldn't need changes, except for > special layer handling (example: the assembly layer show references on > the insertion point and not on the silk position, and maybe has pad > forced on). As special layer semantics I wouldn't put it in 'work to > make more layer available'. > > That would work fine up to 64 layers, which is the double of the > previously available number. After that there is a *big* problem, on the > C++ side: literals and efficiency. If I have a supported integer type, > the compiler can fold expressions and enums/defines work fine. However, > using something like std::vector uses objects, not integers. So, > a thing like LAYER_FRONT|LAYER_BACK can't be compiler folded anymore. > > Also, what are LAYER_FRONT and LAYER_BACK? static constant objects? > temporary objects on the stack? Maybe the new literal syntax defined in > the new standard will help, when the time will come. > > -- > Lorenzo Marcantonio > Logos Srl > > Hi Lorenzo, I could really do with more layers too. Although when I say *more* layers, I mean that I could really do with dedicated assembly and courtyard layers. The assembly layer needs the reference field on, as you say, at the insertion point of the component as well as a physical bounding box; This should flip when the component is flipped. Thanks for spending the time investigating it, because I'll sure be glad of any work that goes into supporting these layers. Best Regards, Brian. ___ 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] Experiments and considerations for more layer
At last I tried to broke the 32 layer barrier in pcbnew. Needed the assembly and courtyard on both sides, so the ECO are not enough. Also they need to be flippable, too. Result: succesful, learnt things that could be useful later. First, the huge LAYER_NUM/LAYER_MSK work I done previously was in the right direction. Once I coerced the compiler to use 64 bits for the mask, it worked flawlessly (yay!). First trouble: in 32 bit arch that would be a long long int (or int64_t), on 64 bit arch simply a long int (still int64_t). Handling it as an enum (by the standard) make the compiler choose these types. Cue printf format issues and related warnings. New C++ has a "class enum LAYER_MSK : uint64_t" to force the choice but it also put the enum values in the enum namespace, so you have to type LAYER_MSK::FRONT_LAYER instead of simply FRONT_LAYER. Technically useful, but hugely unconvenient. 90% of the modifications had to be done in the layer include and pcbcommon source (obviously). The flipping thing is there too, worked at the first try(of course, that meant recompiling 90% of pcbnew:P) On the UI side: most painful the stackup dialog; I'm not a wxformbuilder expert but at the end the fastest thing was to hand edit the xml! That dialog would be a lot of fun to generate dynamically IMHO. Also the layer bar needed the obvious add, but nothing painful. Side note: the layer bar is *not* scrollable, so lots of layers could be an issue, there. The pad box would need change if we wanted pads on some new layer, of course (but these would be probably 'special' technical layer, anyway, so they would need special code). Other (minor) issue: the layer chooser (used for example in the module editor) works with a range and the code relies on it to exclude the board edges from the selection. That broke adding new layers (since the edge is not anymore the last). The 'right' way to fix it would be using a mask instead of a range (I keep the range broken, for now:D) Other side issues: the module editor would really need better layer control, especially for visibility. Ideally the layer sidebar could be grafted to it but I fear it relies on a board (for showing the user names instead of the standard names). Also layer control for text fields in modules would be very useful (the file format already handles it and IIRC there are not many things to change in the rest of pcbnew). Semantic for the 'show text front/back' would need clarification obviously. Didn't try a plot yet, but I think it wouldn't need changes, except for special layer handling (example: the assembly layer show references on the insertion point and not on the silk position, and maybe has pad forced on). As special layer semantics I wouldn't put it in 'work to make more layer available'. That would work fine up to 64 layers, which is the double of the previously available number. After that there is a *big* problem, on the C++ side: literals and efficiency. If I have a supported integer type, the compiler can fold expressions and enums/defines work fine. However, using something like std::vector uses objects, not integers. So, a thing like LAYER_FRONT|LAYER_BACK can't be compiler folded anymore. Also, what are LAYER_FRONT and LAYER_BACK? static constant objects? temporary objects on the stack? Maybe the new literal syntax defined in the new standard will help, when the time will come. -- Lorenzo Marcantonio Logos Srl smime.p7s Description: S/MIME cryptographic 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
