Hi Oliver, > > > I think we need to fit this in with the existing PCBNew Attributes stuff > (“attr” in the file format). We currently have through-hole, SMD and > virtual (the later being similar to DNF/DNP), but a lot of folks have found > that too limiting for various reasons. I suspect this means we need > user-defined attributes, but I’m not sure how many “system-defined” ones > we’d also want to support. >
I did consider this, but I don't think that we can overload the SMD / THT / virtual attribute with a DNP attribute. Setting a component as DNP doesn't mean that (for e.g.) it is *not* a SMD component. It just means that it should not be loaded. DNP is an *extra* attribute it does not replace the loading type of the component. Perhaps something like "(attr smd dnp)" could work? Allowing advance specification of the attributes in Eeschema would be a > nice enhancement. But due to file format changes (on at least the PCBNew > side) it would have to wait for 6.0. > > Cheers, > Jeff. > > > On 25 Nov 2018, at 04:38, Oliver Walters <[email protected]> > wrote: > > A feature I feel has been missing from KiCad is the ability to mark parts > as "DNF" (Do Not Fit) so they are excluded from assembly files (BoM / PnP / > etc). > > Many of the existing BoM tools (including mine) offer "hacks" to get > around this shortfall by having a special field assigned to each component, > for example. > > I have a branch working towards such functionality and am looking for some > feedback. > > I consider this preliminary work towards full support of assembly > variants. However this will need to wait until the new file format to be > properly implemented. So for now, only DNF status is presented. > > Here are the features I have implemented so far: > > *A. Schematic components can be marked as "DNF" * > > A new checkbox in the component editor allows part fit to be deselected. > By default all components are selected. (UI placement not final, just for > demonstration). > > <image.png> > > Note that when rendered in the schematic, DNF parts are denoted by > appended text after the RefDes field. > > Altium denotes DNF parts with a large red cross - I think that greying out > DNF parts would look quite nice. > > *B. DNF part status is saved in the .sch schematic file* > > If a part is DNF , then the component line in the .sch file is appended: > > <image.png> > > Parts which *are* fitted do not get updated - to reduce file changes. > > As far as I can tell, this file change is fully backwards and forwards > compatible. Old versions can open the file and simply ignore the DNF > parameter. So perhaps this can be pushed into production before 6.x branch > as it won't break any schematics. > > *C. Fitment status saved in exported netlist file* > > The fitment status of each component is saved to the exported netlist file. > > <image.png> > > So all this at least allows fit / DNF status to appear to the BOM tools. > > What's left? > > *1. PCBNEW* > > DNF status should be pushed to PCBEW, because: > > > - Don't show 3D models for parts which are marked as DNF > - Don't export DNF parts to the PnP files > - (Eventually) ability to switch between assembly variants in PCBNEW > > However, this would require a file format change to the .kicad_pcb file, > and this does not have the same opportunity for version compatibility that > the simpler .sch files do. > > I can make this happen, but I'm guessing it has to wait for the 6.x branch. > > A simple example of how this could be included in the file: > > <image.png> > > *2. Multi-Unit Parts* > > If you mark one unit of a multi-unit part as DNF then *all* other units > should be marked as DNF too. > > Question: How (from SCH_EDIT_FRAME context) do I find all the components > that are the same master component as a given sub-part? > > *3. Better Display of DNF parts* > > I'd like to add a "greyed out" display for DNF parts in the schematic > viewer. > > *4. Nomenclature* > > In the files I have used "DNF" or "fitted" - what should the accepted > nomenclature be here? I've seen DNF / DNP / NC and other examples used. I'd > like to get some clarity on what I should use going forward. > > As I said above, I'd like to move this on to support a full assembly > variant management system but I feel it's best to wait until new file > formats. Until then, some feedback on the items above would be great. > > Thanks, > > Oliver > > _______________________________________________ > Mailing list: https://launchpad.net/~kicad-developers > Post to : [email protected] > Unsubscribe : https://launchpad.net/~kicad-developers > More help : https://help.launchpad.net/ListHelp > > >
_______________________________________________ Mailing list: https://launchpad.net/~kicad-developers Post to : [email protected] Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
