On Thu, Oct 22, 2009 at 5:34 PM, andrew99037a <[email protected]> wrote: > > Note snipped history for these comments.... > > I have a serious gripe about the whole alignment thing as far as eeschema is > concerned, as well as some comments on cut and paste, X's etc.
Hmmm, missed your X's and cut'n'paste comments. Maybe another email? > > 1) there is no need to have ERC to fix alignment issues as far as I am > concerned. I agree that ERC shouldn't "fix" anything. However, ERC can and should report a few cases where the human might misinterpret the connectivity unless he looks very closely. > Alignment issues for this case are defined as pins/wires that look connected > but are not. THIS IS A BUG in the editor. Before flaming please read on. > There are conventions as to how schematics look. The basic conventions are > that lines which T are connected, and lines which cross are not, EXCEPT, when > there is a filled junction. A more obvious, but not explicitly stated rule is > that things which look continuous ARE continuous. We use a grid for > schematics. The grid is symbolic, not physical, so there is very little > reason to mess with it. Your position, while absolute, is not unreasonable. I have found that it is possible to make schematics which look good and which are connected in an intuitive fashion. It is also possible to create things that are not like that. Whether that means the editor is buggy or not is not my call, but it is my personal responsibility to ensure that things that I use eeschema for are correct, so since I just started using kicad a few weeks ago, and, since it was new software to me and I am an untrusting soul by nature, I decided to write my own verification on what the editor does. It allows me to check that things that look a certain way to me are, in fact, a certain way. I have made this software available at kipy.org, and you can use it or not, as you see fit. > While there are good reasons for allowing non-manhattan geometry, there are > NOT good reasons for allowing off-grid geometry. Actually, non-manhattan geometry should be used in very few cases (perhaps 4 diodes in a bridge rectifier). It is computationally harder to determine connectivity with a lot of non-manhattan geometry, and since I seldom use or need it, I certainly did not optimize my software for it. (In fact my software will complain about non-orthogonal lines and explain that it is only checking their endpoints.) > Thus the point of ERC is MOOT. It should be impossible to create, and thus > impossible to ERC an alignment issue. The fact that other programs (like > orcad) didn't fix this is not justification to allow this annoyance to > continue. Yes, there are quite a few UI things in kicad I don't like, either, but for my purposes it is head-and-shoulder above all the alternatives. Unfortunately, I'm not really a UI hacker or a C++ hacker, so I'm not prepared to fix those things. I did make a "new user report" in the developer's group right when I got started, which I hope the developers find useful, but since I am not prepared to fix things which I theoretically could fix (since source has been given to me), I am also not prepared to complain bitterly about them. In any case, I probably still would have written my ERC, because I always check pretty much everything I can, and the library/schematic file format for eeschema is very amenable to this sort of checking. > There are lots of implications to this, such as wiring past a component > automatically places a junction etc. In my experience these behaviors are > expected, and thus fine.... the alternatives are not expected and cause > problems. > > 2) > As for the other ERC issues, The general "ERC" problem is an unbounded one. > As mentioned, there are voltage limits, termination, io direction, etc. To > have everything checked is impossible, as it requires knowledge about the > function of the components, so its important to allow enough flexibility to > let people do the basic stuff easily ( which I think includes the basic IO > stuff only, and no fanout), and then allow hooks for the rest. I agree to a large extent. The ERC I have done in the past was very much board-specific. However, I'm trying (developing offline right now) to make these hooks a bit more general purpose and easier to use. > Otherwise, it just gets insane in a hurry. Yes, the checking should allow the user to check whatever he wants, and help him to enforce additional design-specific rules, but should not force any particular checks on him. In fact, I find the current eeschema checking (which requires a power flag on certain nets) not all that helpful and somewhat distracting. Best regards, Pat
