kicad-developers team mailing list archive

[Oliver Walters <oliver.henry.walters@xxxxxxxxx>]

>
> I understand your frustration but I'm currently working on the new file
> format so I am not interested in adding a new feature to the current
> schematic file format.  This feature is already rolled into the new
> schematic file format.  I should have most of this work complete by the
> end of the year so it makes no sense to divert resources from the new
> file format development to test and maintain the proposed changes to the
> current file format.  The current file format is frozen permanently so
> that we can focus on the new format.
>
>
Wayne, thanks for your prompt feedback on this. Can I ask, does the new
format support simple "DNF" marking or full variant support?

Nobody in this thread has yet mentioned KiBoM, which has this
> kind of capability.  It has its quirks, to be sure, but I would
> recommend investigating it first, before starting to write something new.
>
>
I actually wrote that tool (many moons ago) to fill the gaps of KiCad
assembly management. I would love to see some if its features integrated
into KiCad directly.



On Thu, Sep 19, 2019 at 8:47 PM Oliver Walters <
oliver.henry.walters@xxxxxxxxx> wrote:

> Hi all,
>
> Almost a year ago now I suggested a feature addition, allowing for marking
> parts in the schematic as "DO NOT FIT"
>
> https://lists.launchpad.net/kicad-developers/msg38415.html
>
> I had made a lot of progress towards feature completion, however was told
> at the time that such a feature would not be accepted.
>
> A year later, and after a lot of frustration of  sending the wrong files
> out for manufacturer due to confusion about which parts are fitted, I'd
> like to raise the issue again.
>
> Currently parts are marked as "DNF" by setting a special field in the BOM
> and checking for this with a special export script.
>
> However, I feel (and I'm sure many would agree) that this information
> should be integral to the schematic representation itself. Some other EDA
> packages achieve this quite well.
>
> I presented a way to achieve this without breaking backwards compatibility
> with the file format.
>
> If the "new" file format is still far in the future, can this feature be
> considered again?
>
> Cheers,
> Oliver
>