Re: [Kicad-developers] Do Not Fit

[Oliver Walters]

>
> 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.walt...@gmail.com> 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
>
___
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] Do Not Fit

[Larry Doolittle]

On Thu, Sep 19, 2019 at 03:41:41PM +0200, ja...@veith.net wrote:
> pls allow some comments to Olivers do not fit suggestions.
> ...
> „Do not fit“ components are nothing else than changed value properties of
> components. E.g. variant A has no R100 and value of R100=DNF, variant B with
> R100=1k, variant C with R100 =4k7.

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.

https://github.com/SchrodingersGat/KiBoM

  - Larry

___
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] Do Not Fit

[ja...@veith.net]

pls allow some comments to Olivers do not fit suggestions. We recently 
stumbled accidently above Kicad after quarrels with commercial tools and 
found its push & shoove capabilites are a remarkable and motivating 
feature.


Experience shows, that the „do not fit“ feature is much more complex. 
Unfortunately PCB do not have interface standards for contract assembly 
and soldering in comparison to Gerber for etching or CNC drilling. 
Therefore cooperation with non black belted contract manufactureres is 
always painful. For this reason, we run our own SMD pick & place machines.


„Do not fit“ components are nothing else than changed value properties 
of components. E.g. variant A has no R100 and value of R100=DNF, variant 
B with R100=1k, variant C with R100 =4k7. Shure this decision is in the 
responsibility of the design engineer. To decide this inside schematic 
will end up in complex variant manager tools. Variants become instances 
of schematic. This raises more questions what beginners hardly 
understand. Finally we recognize that variants are not only a question 
of assembly but of component purchasing, stock keeping and so on. This 
leads to the blueprint V6 library format discussion what is much more 
complex.


I dont offer contract assembly and all designs are own and drawn by 
diffrent CAD. After struggling years with Excel BOM and insufficient CSV 
macros like many other contract manufacturers, we started 
https://sourceforge.net/projects/cad2board/ Up on today Qt is only 
compiled and tested for windows, cannot read Kicad input and output 
format is limited to our Heeb pick & place machines  (today ATN 
innoplacer Berlin) So is of little consequence for Kicad but solution 
works comfortable here. We have complex variant managers but do not use. 
Variant decisions are executed at latest possible moment. Eg. the reel 
with CPU crystals run unexpected empty and there are a few more boards 
to populate. It is one click to take out this component from project 
temporarily without saving and continue assembly if I decide to complete 
the few crystals by hand while board testing. Same way we manage all 
variants and „DNF“ components permanently inside pick2place project 
files. They can be merged any time with updates from full size BOM. To 
understand Olivers efforts: The disadvantage of this solution is a 
possibly inaccurate schematics not representing all details of any 
specific variant.


Happy routing
Janvi

___
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] Do Not Fit

[Wayne Stambaugh]

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.

Cheers,

Wayne

On 9/19/19 9:21 AM, Dino Ghilardi wrote:
> +1 on this
> 
> I usually work-around the problem setting the component value to "NM" or
> "Not mounted" or "Don't mount" , but this is sub-optimal and needs more
> work to update the bom and the place files.
> 
> The only suggestion I have is to make translatable or configurable the
> shown string on the schematic and layout printed/plotted files (I mean
> the files that are intended to be read mostly by humans): may be in
> different countries the DNF or NC or NM have a different meaning.
> 
> 
> This "do not fit" flag would be a solution simpler than fully implement
> the "assembly variants" (with a single schematic where "don't fit"
> components and even the component value value depend on "assembly
> version"), but it would make life easier on a lot of projects.
> 
> The full "assembly variants" implementation would probably require
> changing the file format having a list of values for every component and
> a list of allowed variant, so this seems in the far (far) future (but
> may be I'm wrong).
> 
> Once the "don't fit" information is available both to pcbnew and
> eeschema, future (and indipendent from this) developments could also
> have "big red ugly cross" over dnf components in the assembly drawings
> (or something like that), graying-out the DNF components in eeschema etc...
> 
> On 19/09/19 12:47, Oliver Walters 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
>>
>> ___
>> Mailing list: https://launchpad.net/~kicad-developers
>> Post to : kicad-developers@lists.launchpad.net
>> Unsubscribe : https://launchpad.net/~kicad-developers
>> More help   : https://help.launchpad.net/ListHelp
>>
> 
> 
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp

___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] Do Not Fit

[Dino Ghilardi]

+1 on this

I usually work-around the problem setting the component value to "NM" or 
"Not mounted" or "Don't mount" , but this is sub-optimal and needs more 
work to update the bom and the place files.


The only suggestion I have is to make translatable or configurable the 
shown string on the schematic and layout printed/plotted files (I mean 
the files that are intended to be read mostly by humans): may be in 
different countries the DNF or NC or NM have a different meaning.



This "do not fit" flag would be a solution simpler than fully implement 
the "assembly variants" (with a single schematic where "don't fit" 
components and even the component value value depend on "assembly 
version"), but it would make life easier on a lot of projects.


The full "assembly variants" implementation would probably require 
changing the file format having a list of values for every component and 
a list of allowed variant, so this seems in the far (far) future (but 
may be I'm wrong).


Once the "don't fit" information is available both to pcbnew and 
eeschema, future (and indipendent from this) developments could also 
have "big red ugly cross" over dnf components in the assembly drawings 
(or something like that), graying-out the DNF components in eeschema etc...


On 19/09/19 12:47, Oliver Walters 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

___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp




___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] KiCad Services Corporation

[Wayne Stambaugh]

Seth,

Best of luck on your new endeavor.  This will be a great service for
users who have shied away from KiCad due to the lack of commercial
support.  Professional designers cannot use that as an excuse any more.
 I think this will be a win for you personally and for the project.

Cheers,

Wayne

On 9/18/19 4:45 PM, Seth Hillbrand wrote:
> Hi KiCad Folks-
> 
> I wanted to publicly give people a heads up about the formation of the
> KiCad Services Corporation (KiPro), a Kicad-specific support company. 
> We started in June with a soft-launch and have found a significant level
> of interest (hooray!).  We're now fully operational and looking forward
> to contributing more to KiCad going forward.
> 
> We've had a few questions from people in our community and I'd like to
> openly address them here.  
> 
> Q: What does KiPro do?
> A: We provide support contracts for companies that rely on KiCad.  These
> are non-public bug reports and support tickets for companies and
> professionals working on proprietary designs or who need guaranteed
> support levels.  Companies can get their questions answered and bugs
> fixed without needing to publicly disclose their designs.  We also offer
> dedicated feature development.
> 
> Q: Any relation to WIT (the company that employs Wayne Stambaugh)?
> A: Not at this time except that we are both working toward the same goal
> of open-source hardware development models.
> 
> Q: Does KiPro share resources with KiCad?
> A: We do not take donations from KiCad or CERN.  We look forward to
> providing funding to support KiCad activities in the future.
> 
> Q: Will KiPro divert resources from the KiCad community?
> A: While some businesses may choose to purchase a KiPro support
> subscription instead of donating through CERN, this is likely to be a
> minority as the KiPro subscriptions and contracts are payment in return
> for services and not donations.  Additionally, the KiCad Services
> Corporation is chartered to support the free and open development of
> KiCad, so funds in excess of operating expenses are used to support
> full-time developers, testers and documentation writers.  It is our goal
> for the additional KiCad awareness and activity we provide to increase
> the total level of charitable contributions KiCad receives through CERN.
> 
> Q: Does KiPro or its clients direct KiCad development?
> A: No.  All bug-fixes and documentation developed by KiPro employees
> will be submitted as patches to the appropriate mailing lists for public
> discussion.  Any feature development will be proposed and outlined on
> the kicad-developers list and be agreed to by the lead developer team
> prior to our work.  We serve as an intermediary and accelerant to
> businesses looking for specific KiCad features, ensuring that features
> are both inline with long-term KiCad development as well as
> incorporating feedback from the broader community.
> 
> Q: Is this a non-profit (501(c)3) organization?
> A: No.  KiCad Services Corporation is a California Corporation with the
> mission to advance the development and uptake of the KiCad software
> package as an open source system.
> 
> 
> Please feel free to raise any additional questions or concerns you might
> have and I'll do my best to address them.
> 
> 
> Regards-
> 
>   
> 
> Seth Hillbrand
> 
> Chief Technologist
> 
> KiCad Services Corporation
> 
> Twitter Twitter     LinkedIn 
> LinkedIn
>  
> 
>               
> 
>   +1 530 302 5483  | +1 212 603 9372 
> 
>   www.kipro-pcb.com 
>   Davis, CA
> 
> 
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp
> 

___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

[Kicad-developers] Do Not Fit

[Oliver Walters]

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
___
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