Hello!
It looks to me as thought the gap between pads is 0.370mm and the trace + two clearances is 0.375mm, the trace just goes through sometimes by chance or rounding error.
No, as explained above, it’s not the case. According to paulvdh, the rounding is within nanometers. And here, I have set the pad diameters to 0.89. The reason is that with 1.27 - 2 * clearance - trace width would be 0.895. And I made it slightly smaller to leave room for rounding, concretely spoken 5000 nm.
Pascal
There is no bug I can see. It looks much like a rounding error problem.
You have no room for any.
Have a look at this screenshot, where I zoomed in between pads 2 and 4 after pushing a trace from pin 1 or 4 through.
At the moment the yellow guard line touches your red trace you have a violation of the design rules and KiCad will not route the trace with the default settings.
As you can see the grit dots on the PCB are at 10 micrometer.
You have an estimated less than 5% of that, so much less than a micrometer for rounding errors. But estimation is unreliable because KiCad does not draw a true circle but a polygon.
Followup:
While I do not consider it a bug, I do understand that it would be anoying if the default design rules do not work nicely with the default symbols in the default libraries.
So I went back tho Eechema, hovered above the offending connector and pressed "f"ootprint.
It does not seem to be a default footprint in the V5.0.2 libraries, or I’m doing something wrong. I have not used KiCad V5 much yet and are not well versed with the new library management and other changes yet.
Hello!
Indeed, it’s not a standard component. The reason is that I needed smaller pads in order to be compliant to the PCB maker rules. So the pads’ diameter is 0.89. I use a lot of these small pitch connectors which are very handy if you want for example, a JTAG connectors which is less than 10 mm high and doesn’t take a quarter of your board surface.
In the meantime, I managed to route from the pins when using a smaller grid (0.01). But I still think it should be possible to do that without altering the grid. It’s a topological problem, and I don’t know how complex the implementation can be, but the software should evaluate whether there is space or not between the pins, independetly on the grid size. After all, the software I was using before had a really shitty interface but did this nicely, so I don’t think it’s beyond the technology.
Pascal
Just an addendum if somebody has a similar problem:
I just tried again and if I set the pad diameter to 0.89mm I can draw a 0.125mm trace straight through with no problems. If I set a fine grid it seems to be easier to do.
If I leave the pads at 0.9mm dia. then I have to set the track clearance to 0.122mm before the trace will go through.
This is something that is right on the edge of whatever tolerances the router is working to and probably outside of what it should theoretically be working to, but it is still infinitely small compared to the tolerances the board manufacturers work to…
Edit: errrm, it looks as though my reply was aimed at paulvdh, it was meant to be a general comment to everybody
Oops, I had not realised the pitch of your components. I thought I was working with a default 0.1" IDC header here 
With all that zoom capabaility you loose track of the real size of things on your computer screen.
If you’re using custom sized components, then you are responsible for ensuring that you have a fitting combination of rules.
As I said before fiddling with grid is no substitute for having a decent set of design rules.
I wanted to give you some guidelines for (slightly) adjusting the default width of traces with:
[edit] Forget the assert failure below. It is not reproducible after saving the project in KiCad V5.0.2 and restarting KiCad [/edit]
Pcbnew / Setup / Designrules, but then I bumped into something that could be a real bug:
ASSERT INFO:
…/src/generic/grid.cpp(1307): assert “(row >= 0 && row < GetNumberRows()) && (col >= 0 && col < GetNumberCols())” failed in SetValue(): invalid row or column index in wxGridStringTableBACKTRACE:
[1] wxGridStringTable::SetValue(int, int, wxString const&)
[2] wxGrid::SetCellValue(int, int, wxString const&)
[3] wxEvtHandler::ProcessEventIfMatchesId(wxEventTableEntryBase const&, wxEvtHandler*, wxEvent&)
[4] wxEventHashTable::HandleEvent(wxEvent&, wxEvtHandler*)
[5] wxEvtHandler::TryHereOnly(wxEvent&)
[6] wxEvtHandler::DoTryChain(wxEvent&)
[7] wxEvtHandler::ProcessEvent(wxEvent&)
[8] wxWindowBase::TryAfter(wxEvent&)
[9] wxEvtHandler::SafelyProcessEvent(wxEvent&)
[10] wxMenuBase::SendEvent(int, int)
[11] g_closure_invoke
[12] g_signal_emit_valist
[13] g_signal_emit
[14] gtk_widget_activate
[15] gtk_menu_shell_activate_item
[16] g_closure_invoke
[17] g_signal_emit_valist
[18] g_signal_emit
[19] gtk_propagate_event
[20] gtk_main_do_event
[21] g_main_context_dispatch
[22] g_main_loop_run
[23] gtk_main
[24] wxGUIEventLoop::DoRun()
[25] wxEventLoopBase::Run()
[26] wxAppConsoleBase::MainLoop()
[27] wxEntry(int&, wchar_t**)
[28] __libc_start_main
[29] _start
Failed assertions are never a good thing. But because I opened a KiCad V6 schematic from the 'net in KiCAd V5.0.2, I’m not sure if it’s worth looking into further.
I can continue though after the failed assertion.
So I changed the track widths from 0.125mm to 0.124mm and after that you can easily route traces between your pins.
If you do not want to make the traces any thinner, you can make the pads smaller or reduce the clearances.
How did you make your design rules? It seems that you have calculated them in such a way that everything added together results in 0.0nm room for tolerances, or it might just be a coincedence, but it is not a bug of KiCad that it fails to route between those pins with those design rule settings.
I just set a coarse grit, and experimented some more.
I can still route the 0.124mm trace between the pins. The Interactive router in KiCad is smart enough to place the traces off grid. It only needs that extra single micrometer.
Even on a 1mm Grit it still works properly.
Hello!
I’m sorry about all this mess. I wanted to make smaller pads instead of narrower traces. And I found out that although my calculation above (0.89mm) was right, my setting was 0.895mm and indeed it gives 0 margin and everything depends on rounding.
Fixed now. You can ignore the “bug”, it was just my mistake. Sorry for your time.
I have to correct all my footprints now.
Pascal
One thing I am finding (rightly or wrongly) if I can get a trace put down, then sometimes I can edit it more effectively by toggling between drag free angle mode and drag 45 degree mode. Does this make any sense?
I just want to add a general comment about interactive router. If it seems that it’s not intuitive sometimes it’s because it’s not a silver bullet, just a heuristic that tries to guess your intentions and takes a lot of circumstances into account (nearby pads, tracks, clearance and other design rules). It’s not perfect and to some extent the amount of guessing it does can be tweaked in settings but there will always be a point where it doesn’t guess right.
In that case just help it out by adding one more “fixed” point of the track to indicate the direction you want to go. Basically the shorter your segments are the higher are the chances that the router will do what you want.
For example, It doesn’t seem to want to thread a track between two pads? Lead the track close to a point between them and click, hover mouse on other side of the gap and more likely than not it will thread the track.
Most of the time it is so good at guessing the right intentions that I can’t imagine going back to using full manual routing.
This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.
