Insufficient error notificaitons

Community
1

I have started another thread about a specific problem but this one is about the lack of, or insufficiency of error notification in the circuit layout tool PCBnew.

When adding a track there seem to be several reasons this can fail but errors are either silent or appear temporarily and non intrusively in the status bar on the periphery of the users vision.

I have a component from the library Choke_Toroid_5x10mm_Vertical . When I place it and try to draw a track, it seems to work OK at first but, if I zoom in, I can see that the dot under the cursor is slightly offset from the track.

Now if I click to set a corner, this has no effect. Continued movement in another direction does not provide a corner and starts to redraw the track from the staring point. After much frustration I noticed the msg “Error type 4: track near pad” appears when I click. Unfortunately it disappears as soon as I move the mouse, so the chances of my actually seeing this ESSENTIAL error message are near zero. The only real indication is the failure of the expected behaviour.

It is my contention that this is insufficient notification of a fatal error.

I am not in favour of unnecessary model dialogues but this is not an optional bit of information that the user may wish to ignore. It is a fatal error which requires that he DOES notice it and which REQUIRES some action on his part to continue successfully.

In fact the error here does not occur when I try to make the corner but when I first click on the pad with the track tool. This is the point at which the error should flagged and in a visible and UNAVOIDABLE manner.

There are a number of similar problems when creating vias or trying to link two components or continue or link two track segements.

worse: if I try to do “end track” by doulbe clicking, the track just disappears and NO message is displayed. ( It may technically be there but is invisible in the period of time between the two mouse clicks, even if I’m watching the status bar.

IMO this should be a model error message in the middle of the screen. The user needs to be aware of the error and deal with it immediately to progress with his work flow.

There may be a good case for a warning when placing a component which has off grid pads. This would reduce some guessing as to what “track near pad” actually means. ( I know there is a pad near the track, that is because I put the track tool near the pad and clicked on it : not too helpful ).

Such a message could also point the user to the remedy , whatever that may be. :?

PS end track from context menu also fails silently. Track disappears with no error msg. :frowning:

1 Like
2

I am not really the person that should be giving advice around here but if you are trying to draw traces without using a netlist go into the menu ‘Preferences - General’ and turn off ‘Enforce design rules’

Edit: I have just read your other post. The Design rule checker is just making sure that the pcb layout is not out of sync with the schematic and is doing exactly what it should do.

1 Like
3

Well if it said something more intelligible at the appropriate time and in a VISIBLE manner that may be a useful feature.

The current situation give NO indication this has anything to do with design rule checking being in sync with the net and the error is so poorly displayed ( even when it is displayed at all ) that it was a day before I even noticed it.

I have two design rules defined relating to track size and clearance. Where is this rule about being in sync?

How is the user supposed to get from 'track near to pad" to understand that the real problem is that the track is not part of the current net? ( If indeed that is the cause of this error ) .

The point of this thread is that the error messages are insufficient. I think you have underlined that point. Thanks.

4

How is the program supposed to know that you’re not just trying to place a track to close to another track from a different net, but instead trying to actually connect two foreign nets with each other?
I’m pretty sure even I as a human wouldn’t be able to do that even if sitting right next to you…

If you want to skip eeschema and omit the netlist part - fine - disable DRC in the options.
If not and you got a schematic, then the program will help you to match the layout with the actual circuit you’re trying to design…
?!?

1 Like
7

That’s not quite true

I know what I meant even if I didn’t quite say it :slight_smile:
I just wanted to point out that trying to lay a non net trace with the Design rule checker enabled produces the result that the o/p was talking about.

8

That was essentially my problem during my earliest fumblings with KiCAD. Somehow I got the default spacing, as well as trace width, up around 15 or 20 mils, and DRC prevented me from placing traces ANYWHERE.

I will agree with the original poster that the error message, while accurate, is misleading. I seem to recall some other EDA tool that would allow you to place a track in situations like this, but then sprinkle a bunch of DRC-fault arrows along the trace in an effort to show where you messed up.

Dale

9

I would agree the message is poorly worded.

There are a great many tracks that are ‘near to pads’… :wink:

It is actually a
DRC Clearance violation of dd mm, Trace NetNameZ too close to PAD Name NetNameX

The tool knows all of the information I gave in that message, it should present that to the user,

1 Like
10

agreed, it is too terse. This looks like a basic development msg that was intended to be fleshed out later but got over-looked.

The problem was that I did not realise I was, as far as kicad was concerned, effectively creating another separate circuit and placing it on top of the existing one by trying to attach new track to a pad of the imported net.

Similarly on my final problem with the gnd tracks, I was trying to make legit connection but the existing name was blocking since the track had a net name that was not GND. This is a very different scenario which produces exactly the same kind of messages. The information in the error msg should be explicit enough to enable the user to distinguish these two situations.

My other issue with all this is that it was far too discrete. As I noted initially this is a show stopper and it needs to be flagged with a model dialogue error msg, not something as far away as possilbe from the screen centre where the user’s focus is and which disappears as soon as he moves the mouse or clicks something.

1 Like