I’ve been using Eschema for some time and find it very useful but am having a lot of difficulty with creating a layout.
There are several errors which are either poorly displayed of not signalled at all other than by silent failure of the operation.
One particular problem which is preventing me from finishing this layout is tracks refusing to go where I put them.
On some components, the tracks starts and follows the cursor in an apparently normal way but I cannot anchor a corner by clicking. The track is still redrawing from its starting point. After some time I noticed that when I click to start the track there is an error in the status bar. “Track near pad”. Duh, I want a track ON the pad, that’s why I clicked.
There are similar problems when trying to link some components or creating vias.
It seems that this is some kind of conflict with layout grids in mm round numbers ( like 0.05000 mm ) and component footprints created on inch based units ( mils ) .
The show stopper is that I can’t find out what I need to do get kicad to realise that this is near enough get it to do what I want.
There is a secondary issue here that a lot of these errors are fatal errors and a discrete and momentary message at the periphery of vision is not sufficient notification.
So my first question is how do I get around this problem and get inch components to work on a mm gird ?
I have created another thread about visibility of error messages, I’d like to keep this one to solution to the specific problem of getting tracks to link to slightly off grod components or how to get them on grid.
Well I did start from a rat’s nest but in the week that I’ve been battling with this now, I can not promise that one or two of these components have not been added or removed / readded in attempts to get some sanity out of it.
I’ve got 80-90% placed and have done a lot of tracks by hand, most of which seem to be where I wanted them after much fiddling.
After what you said it sounds like I only know half my troubles. Probably the tracks I think I’ve got right are not even connected in the way I intended.
I did not realise kicad was still in alpha development stage
It seems like the footprint editor is using inch based units ( whether you chose to display that as an odd number of mm or a nice round number in mils is irrelevant ). Contrariwise, the layout editor is natively in mm .
This rather confused set up means that there is always a mismatch of pad positions and track layout for non trivial components.
They will not be, but it is not as bad as you may think…
You can remedy that, by clone of the connection in SCH, and then import NET.
I think PcbNew is smart enough to use the NET into, and existing tracks, and merge into a valid design (one that passes DRC ) - ie you do not need to re-route anything, just ‘phase-lock’ the SCH.
There is always some mix of inch and mm in most PCB designs.
The DRC in PcbNew considers a trace-end point anywhere inside a PAD, as connected, so it is tolerant to the grid-jump issues that may occur.
Thanks, that is what I would expect but does not seem consistent with all these errors and refusal to link tracks up. Could you explain that contradiction, I don’t seem to be following what you have said.
OK, I have recreated the NET file in Eschema , re-imported it into PCBnew and it fixed the problems. Effectively it is able to lay a track onto an existing net link but not to add one to the layout.
I have now managed to place the remainder of my tracks and complete the layout, Many thanks.
If this part of the functionality never works, perhaps it should be disabled until it does ! I’ve wasted days screwing around thinking I must be doing something wrong when in fact I was trying to use a totally non existent function which seems to work but never does.
Perhaps the cursor should be a no-entry sign until it is over a net which it can deal with. Certainly something should be done to make it obvious that this is not an implemented feature. This is an unnecessary cause of frustration and a huge time waster .
Oh dear, I spoke too soom. I deleted a segment to reroute it and now it won’t let me put if back.
It is showing one net line in white representing the need for another link ( it’s in the gnd ) so now one half of the circuit has no ground and PCBnew is showing this link is missing but won’t let me add it.
I’m back to the "two tracks close " or “track near pad” crap however I try to link them.
Even if I try to lay a track down along the line it is indicating with the net , it won’t let me do it . WTF?
Whatever the problem it is seeing, these obscure error messages are no help in find out what the origin of the problem the program is objecting to, is.
You sound like you don’t treat the schematic as the master for the netlist, but instead add tracks in pcbnew where you see fit…
Is that correct?
If so, disable DRC and be a happy kid, but don’t blame KiCAD for not taking care of your netlist anymore.
And don’t expect any filled zones to work properly either.
Good luck.
PS: after you’re done goofing around with that kind of ‘work-flow’ and wasted enough time (and maybe manufactured boards) you might want to reconsider not treating the schematic as the master source for the netlist.
The proper way is to change tracks/connections in eeschema, re-create the netlist and reload it in pcbnew, then do the layout or change it.
That’s how KiCAD rolls and works.
PPS: I’ve got metric and imperial footprints as most others here and I have no problems useing proper netlists from the schematic master to connect to pads of footprints in either imperial or metric grid as pcbnew snaps to them when they’re near and I’m on the correct net (or start from one).
[quote]
PPS: I’ve got metric and imperial footprints as most others here and I have no problems useing proper netlists from the schematic master to connect to pads of footprints in either imperial or metric grid [/quote]
Thanks guys. That was a misinterpretation of the unhelpful messages appearing at the wrong time and not saying what the real problem was. It appeared that the misalignment was the problem causing kicad to complain with an error that a track was “near” a pad when I was intending it to be ON the pad.
No, there were a couple of components which I did not have proper footprint for so they we not connecting up when I imported the net. I thought I could add tracks manually.
Allegedly this does not work with DRC on , despite there not being any design rule that mentions net sync. I guess you just have to know. This relates to the other thread I opened about the insufficiency of the error msgs. I’ll deal with that there.
So after all that I still have this obscure error where it won’t let me place a track even if I try to follow the path indicated by the remaining net line.
It is producing the same errors as before but because it does not show a msg relating to what the error is, it is a guessing game to work out what it thinks is wrong.
Annoyingly, I did have it completed and then deleted a segment to improve its routing and now it won’t let me put it back.
If some you vets can see what the problem is that would be most helpful.
So how did you get the footprints into pcbnew then, if not via cvpcb (or the schematic)?
Do you now have problems with these footprints or with others that have proper symbols in your schematic?
Ratsnest lines in legacy mode can be deceiving… did you check the net names of the pads that you think are connected by the ratsnest line? Are they equal?
There is also an option to show net names on tracks… switch it on to see what you got.
To me also helpful is to switch pads into outline mode (left tool bar) to see what kind of track-mess I have produced
I said I did not have proper footprints, not that I had no footprints. Pin numbers did not match up so they did not get connected. I still had a footprint which I thought I could connect by hand.
Net names are on and all these lines are marked gnd. It still refuses to let me join them together.
You could post the design, for others to check.
Is DRC on or off ?
If DRC is on, you could try drag of the GND segments (D in OpenGL) to see if another segment is lurking underneath
Usually Rats -> Trace is no problem on trace-replace aspect.
You could raise an enhancement request - or vote on the ones likely already there…
Adding the ability to add-connection(NET) in PCB seems easy enough to do, and other CAD tools can do this.
Sometimes you do need free-copper-lines and a no-net trace is how PcbNew manages this.
Other CAD tools have Copper and Lines entities, where they plot the same, but differ like this
Tracks : Are part of NET, and are can Shove/Route
Copper : Fixed lines, visible to Pour and DRC, but no Shove
2D Lines : Fixed lines, invisible to DRC and Pour. Use care as you can short anything to anything !!
Those are separate data base entities.
However, adding the ability to add-connection in PCB is not a silver bullet, and somewhat kicks the can down the road.
If you do add a NET name in PCB side, and manually add nets, DRC will pass, but the next NET import now is unsure what to do.
It will want to delete your net name, and assign the SCH dummy single-node net name, as it seeks ==.
You could patch that, with a prohibit switch, but now SCH cannot disconnect any pin you may want changed, via sch.
Fundamental problem is, you cannot have two masters of NET process.
What they could do, is raise the distinction between NET [] 0 lines and NET ValidName Num, maybe with two buttons.
A single “Add tracks and Vias” is a rather poor name to apply, as what you can actually do is two quite distinct things
Route & reroute with Shove existing (rats) NETs
Add Free (unconnected) traces with Net name “”, that give no NET connectivity.
Add of NET [] 0 is similar * (but not exact clone of) other tools Add Copper.
This carries no SCH net information, and is usually used for cut lines or pour splits etc.
It does not allow you to ‘connect’ to a pin, as a pin does have NET information (even if a single node net)
I see the ends of net 0 do not shove, but inner segments will shove (in other tools all nodes in copper are fixed)
A new Add Connection / NET RealName would allow you to freely connect pins with DRC, with the caveat that a new NET import is likely to delete that ‘patch’,
However, I would still like to see this new Add-Connection feature in PcbNew, as there are some Adapter Board type designs that really do not need a SCH.
In those cases, a PCB side NET export feature could allow other tools to check integrity. Other tools could safely add to such a NET file.
It also allows version checking of NET info, on no-sch PCB designs.
I have a few lines of Python that can export NET info from PCB, for non-sch flows.
How did the Pin Numbers not match up ?
You can edit the footprint to a TMP_LIB, and then replace one/all in the design.
KICad PcbNew allows multiple pin 3’s for example, so you could take a SO-8 fet, and duplicate 1,2,3 as needed.
Yes, thanks. Once I realised the issue was not having some of the nets present, I fixed up footprints and the pin numbers ( I think all pin names and numbers were a tilda IIRC ). Once the nets were present it all cleared up.
On the final ground problem, I noticed a couple of segments were not named GND, removed them, re-imported the net file and it all fell into place. I was then able to connect all the gnd segments. One of the problems of kicad magically trying to merge the net file and the changes that have been done in PCBnew.
Even though the connections were correct, once they had a name other than GND, kicad was not prepared to connect a GND track to them.
