HI
How can I set up a local grid ?
for example-
My PCB is all 0.1mm except under my 0.635mm BGA where I need the grid to be 0.3175mm
Cartesian local grids would be enough.
Polar (circular) is nice but there might be other ways to do this in the few use cases.
The feature There is no feature implemented to switch to different local grids depending on the working area.
You just have to manually switch the grid from 0.1mm <â>0.3175mm.
If you often switch between two grid values look at the hotkey for âFast grid1â â âFast grid2â.
thanks .
OK problem with the fast grid 1 and fast grid 2 is that the origin needs to be different !
IE The board origin for âdefaultâ grid. and the origin for the âunder the BGA gridâ needs to be different.
Local grids need to have local originsâŚ
yeah I have been trying ALT-1 ALT-2 (the default grid change keys).
Iâve often got 3 or 4 custom grids per board.
Here is what the local grids looks like, complete with local origins
the coarse grid under the fpga dramatically improves routing productivity.
This one isnt so bad a 0.1mm main and a 0.4mm BGA grid for a 0.8mm BGA
However the problem comes when you get a 0.65mm BGA, it is not a multiple of the 0.1mm external grid
and thus routing in the 0.65mm BGA requires 0.325mm local grid and is a mess with an external , non sub integer grid.
Are you sure about this:
I use the grid mostly for visually aligning footprints. For all routing purposes I fully trust on the Interactive router to apply the design rules (and therefore also clearances). As a result, tracks may not be perfectly in between pads, but that is not a significant issue.
For me, stopping to fiddle with irrelevant details was a significant productivity boost.
âAs a result, tracks may not be perfectly in between pads,â
but⌠if they are not perfectly between the pads, they wont go⌠you wont make clearance.
.or if they do, theyâll cause a problem with some other trace you expected to route. Also, placing vias between the balls, they must be placed bang in the middle, there isnt scope to have them off be > 0.
ANyway, still experimenting
While I need local grid regions (not switched)
I think a more simple developer workaround for this would be :
When user changes grids, store grid specific origin with alternate grid
and, need at least 3 or 4 grids, currently ALT1 and ALT2 are available.
I have never used BGA butâŚ
If clearance allows only to go perfectly between than when routing track it will go perfectly between.
So when routing that other trace the first one probably will simply be shoved.
If there are lots of possibilities, and you are routing say, 784 balls, then the finer grid, which the tool will take if it can , just because you didnt keep your mouse running as smooth as you might have done, if you were going slow, that becomes a major PITA. a few extra seconds and keystrokes and mouse movements required to fix it, here and there and 784 balls later at a 10% deviation rate is time and effort. Coarse grids are essential for high productivity and reduce workload and thus better concentration.
For large, complex designs, the focus is heavily on productivity and ease of use / reduced user fatigue.
This seem like a useful feature.
If you wish it to be included in Kicad, create a âFeature Requestâ on Gitlab.
Go to Help > Report Bug and start your topic âFeature Requestâ. By selecting âissuesâ on the LHS you may read a few issues to see the style used for reporting.
I think there was an icon to set the grid origin in previous versions. I have not pre-v4 nor v4 installed in my computer anymore.
Iâm sure I did it easier. In v7, go to view->grid properties and manually set the grid origin to the desired value.
To know the coordinates of the desired value, select the route tracks tool and place the cursor on the pad you want.
The snap to pads option must be set: Preferences->PcbEditor->Editing options->Magnetic Points
Now, you know what to do. Choose a grid one half or one quater smaller than the distance between pads.
I also think it is useful. I am only trying to imagine the best way of doing that task having not local grids.
Two fast switched grids could help (only help, not solve) if they could have separate origin. Having only common origin I would probably locate it in the BGA footprint center (what I assume is positioned in globally used grid) and I would be switching between grids depending if I am under BGA or out of it. Of course it not works if you route track between two BGA footprints 
(until they are positioned to have their centers in both grids).
Thereâs already an open issue tracking this feature request. You can upvote it here: Context-specific grids for Eeschema and Pcbnew (lp:#1840545) (#2483) ¡ Issues ¡ KiCad / KiCad Source Code / kicad ¡ GitLab
Maybe the simplest way to integrate custom grid/origin to the current KiCad paradigm would be to allow attaching a custom origin to grids which already can be customized.
â>
This wouldnât need large changes to the UI and existing workflows, and possibly it would be simple in implementation.
This might need per project grid settings to be really useful â two projects hardly have identical ideal places for local grid origins.
Taken a bit further, maybe also grid override settings could be attached to custom grids.
It needs to go beyond that, there also needs to be a way to specify a bounding region for a grid. Having multiple global grids is fine but it doesnât address all the same problems that local grids do.
Thatâs certainly true, but at least then the grids could be changed easily for âlocalâ and âglobalâ purposes. Start routing from BGA: change to a custom grid B. Continue outside it: change back to grid A. As far as I can see, the original poster tries to find an easy way to set the grid origin for certain grid as a workaround for the lack of local grids. Binding the origin to the custom grid is quicker than setting the origin again each time when the grid is changed.
Not necessarily. If a bunch of hotkeys (OP apparently wants 6 or so) can be assigned for specific grid settings, then switching between grids can be done quite fast on the fly. But using the courtyard for those grid limits is probably better.
Jut had an Idea for an âauto gridâ setting. The idea is that KiCad calculates a grid offset and pitch depending on cursor location. If it is within a courtyard, then it sets the grid to align with the pads of that particular footprint. Combine that with a setting of how many grid points you want for the pitch between two pads, and you have an easy to setup and use grid system.
Is there enough merit in this idea to make a feature requests for it?
Sometimes QFP (and similar) packages are rotated (often 45 degrees) because it makes more efficient use of the area reserved for routing tracks. I have used this a few times myself. A few years ago this was a bit difficult to use. KiCad was too aggressive with trying to align tracks on the grid. But itâs also improving. Connecting to such off grid pads works a lot better then it used to. If a local (or custom) grid itself can be rotated to align with such footprints.
Or bring back the set origin grid icon on the right panel below the set coodinates origin as it once was located.
I guess you mean Drill / Placement origin.
The Icon for the ânormalâ grid is still present in the right toolbar. The toolbar icons with a black triangle in the lower right corner have a foldout function. If you do a long click (hold Left mouse button for approximately 1s) then the menu folds out and you can choose one of the other icons to appear. For the grid origin, you can switch between the icon for either the visible grid or the Drill/Place grid origin.
Thanks for the tip. Then it is easier to change the grid origin (as I thought it was before).
It takes some more clicks than switching the grid resolution, but it solves somehow the OP needs.
