Warnings are just that, a warning it's up to the user to heed or ignore. Nothing sweeping about that.
Modify the rules, to be done with care as I pointed out, and I do agree that most of the rules should be left alone. Unspecified pins are set to generate a warning all the time - so as they are unspecified then I think it's reasonable to use them for a special purpose - the rules being reset is a bit of a pain however. Exception lists... sorry to say this but that's clumsy, long winded, and not obvious to the untrained eye. It may well be necessary for some projects and I can see it's use (I do hope you have suggested that the error output of the ERC is usable as an input) . For most uses I think that the addition of some "user" pin types would solve many of these problems. Assigned on a per-project basis, and you simply tag an existing pin with a user type and then specify what it connects to. a user pin connection would over-rule the standard ERC Just my 2pennyworth :-) Andy On Fri, 3 Jul 2009 05:46:16 -0700 Werner Almesberger <[email protected]> wrote: > Andy Eskelson wrote: > > Ignore the warning a carry on. > > I think it's dangerous to make users ignore warnings or errors. > It's very easy to miss a genuine one if you're already expecting > some non-zero amount of complaints. > > > Modify the rules so that the warning is not generated. > > That's rather sweeping as well. Furthermore, the rules get reset > each time you run eeschema, so the workflow would get rather > messy. > > I wouldn't care so much about unspec pins, but it's also fairly > common to spread a high-current output over multiple pins, and > this also gets us conflicts. A similar case would be multiple > power sources in a serial or parallel configuration. > > One solution may be to have a list of known exceptions that are > then ignored. I just posted a proof of concept implementation to > the kicad-devel list. > > An example of such an exception file is here: > http://svn.openmoko.org/trunk/gta02-core/gta02-core.erx > > Using component references and pin numbers gives use very fine > granularity. I.e., one can silence precisely the one error that's > not an error, without affecting anything else. > > - Werner > > > ------------------------------------ > > Please read the Kicad FAQ in the group files section before posting your > question. > Please post your bug reports here. They will be picked up by the creator of > Kicad. > Please visit http://www.kicadlib.org for details of how to contribute your > symbols/modules to the kicad library. > For building Kicad from source and other development questions visit the > kicad-devel group at http://groups.yahoo.com/group/kicad-develYahoo! Groups > Links > > >
