← Back to team overview

kicad-developers team mailing list archive

Re: Could we make the arrows on EESchema ERC have a color that stands out better?

 

I suggest that the ERC topic in the users group should be looked at a little as well. There was a quite long post which went through a lot of rationale behind ERC. Its good input and it shows what users are worried about.  

ERC's purpose is to find problems which the source engineer or draftsman might miss. There are lots of such problems, and you are never going to get them all. You can read the posts on the kicad users group to see how far people will go to get more "coverage".  

There are also problems which are not related to the circuit, but rather tothe "drafting", and these are more insideous, since they can exist in a state where no "electrical" rules are "broken".

In my opinion, the drafting related problems should be classified as BUGS in the editor. I will give some examples, and why they are SO bad.

1) Off grid connect/noconnects. I've made several coasters in my career because of this one. For whatever reason, developers of several packages, including ORCAD, which is responsible for the majority of them, don't get this right. While there is a tenuous rationale behind being able to draw an angled wire, I have yet to see any reason to allow random off grid stuff. Every time i've seen it, its been the result of a bug, and AWFUL to fix it. Note that this DOESNT mean that the sheet scale needs to stay fixed, Its fine to say zoom the sheet smaller so I can fit more onto an A size page. But it does mean that being able to change the wiring grid to 1 mil from 100 in the middle of a schematic is just insane. 

2) There are defined conventions for how schematics look. For better or worse the rules are what we all expect when we look at a schematic printed onpaper. T junctions are ALWAYS connected, and X junctions are NEVER connected, except when there is a solid filled junction. The editor should enforce this. Unfortunately you can't be trivial about this one because there are the special cases.....

Consider:
2 wires which overlap.... this requires code to discover this at click time and short the nets, and remove the offending segment(s).

a wire which overlaps a pin (co-linear). This can be a judgment call sinceits convenient to wire over the top of components sometimes, but hey its something to consider. unfortunately, if you suggest that the wire doesn't connect, then you have to remove a visible part of the wire, otherwise you violate conventions.

2 pins which touch (co-linear), unfortunately are REQUIRED to connect. this means that you have to be able to handle the case of zero length wires, as well as the case where a wire crosses at that point. Odd but then you HAVE to put a junction there, and you have to prevent the user from being able to delete it too.... Odd eh?

2 pins which overlap (co-linear), seem to also fall in this category, except that it creates an even worse problem, because pins are not really wires,and so there becomes an issue with one of the above... lots o ways to view this one, but since its less common than the others, I've seen people call this an instant little red flag error...  

All of these need to be "live events" that happen as you click. Otherwise, again you violate the expected behavior.  

I also agree with the original poster that all flagged errors should be easy to find. A great error i got was the one about annotation being needed for "C?" True, but not really so helpful a message... A big red circle, and/or a live list of errors would make more sense.


















Follow ups

References