No it does not.
OP wants some kind of auto grid switching or setup of different grids for different area’s of the PCB. And I can see that this would boost productivity on complex PCB’s with lots of fine pitch footprints and different pitches.
On the other hand. Glenenglish is presumably quite new to KiCad. He signed up for this forum less then a week ago, and is apparently considering to switch from altium to KiCad. I don’t know how strictly altium works with grids. In KiCad, the interactive router is quite happy with pushing tracks off grid (As long as it still conforms to the design rules). I don’t know how altium handles this or if he is familiar with the way KiCad handles this.
In KiCad, the grid is also not a very important thing. Sure, if it fits on the grid KiCad makes use of it, but if the grid does not align with a footprint (Metric / inch / banana units issues, etc) then KiCad’s interactive router just routes the tracks and the via’s off grid.
I am guessing that half the problem of this thread does not even exist, but is a result of his inexperience with KiCad, and a natural wish for his attempt to use KiCad in the same way as his old software.
Read it carefully: I said “somehow” not “completely”.
For some of us the use of the correct grid is essential to route a BGA. It seems you do not have any experience in this field.
With the right grid the vias fall exactly in the center of the square made by four pads.
Anyway, I’m not in this forum to quarrel with anybody. I give a solution for a problem, maybe not the ideal solution for the OP. It is up to him, or anyone else, to follow my advice or not.
Pedro, I think that a remebered origin for a each grid would be an intermediate step and probably quite doable. The software just has to remember what the origin was for each grid. So one extra bit of information stored.
So when you change grids, the orign changes to what was the user last set for that grid.
That improves that for the moment.
Continuous region specific grids is ideal, for sure. But can’t have everything. (per my post #3 in this topic with the greyscale image of it in real time) . I can imagine continuous local grids on the display would be quite a headache for the the programmer. it would take an extra coordinate abstraction layer.
Sure, it would be an improvement, still not perfect if you need two different origins for the same grid.
I was talking about what can be done now.
Another solution could be to be able to define different grid origins and choose any of them the same way as the fast grid switching.
With user defined grid + origin you could have two different origins for the same grid. Even now you can define a named custom grid which is identical to an existing one. You would just add different origins to them.
Basically, you need a different grid only while working on or around a particular footprint. The rest of the PCB doesn’t matter at that time, so:
Have many identifiable grid origins (assignable hotkeys?) each with a different user selected grid associated, that can be placed in strategic positions on the PCB (including a footprint pad) so whenever the appropriate hotkey is selected, the associated grid, referenced to a particular grid origin covers the whole working area.
You still need different grids (each with own origins) . Example : 0.1mm overall grid, and 0.4mm grid for 0.8mm BGA, and 0.325mm grid for 0.65mm BGA and 1.27mm grid for 2.54mm BGA connector.
Currently I have ALT1 and ALT 2 assigned to grid selection, they just need to remember their grid origin. That’s a start …5 would cover mot people I think it if the number was hard coded. You need one for each BGA (or BGA connector- I use BGA connectors also) … I usually have not more than 4 BGAs… Simple enough to program - the big step is getting a ready a compile evironment , sync with the git repo environment going . There will be something written up on that exactly what is required, and all the dependencies which is the tricky bit. I’ll find out what environment the developers are using.
HI JMK, was replying to other posts . gettin a bit hectic now!
yes, would work on most complex cases . Need to be able to change grid while routing ( in a perfect world) …As once you are in the outer row of the BGA, there is transition then to the fine grid, as life is hectic around the outer rows. In KiCads case, probably need to terminate routing at the edges. and then change grid and tyhen restart routing.
I was thinking:
While leaving the BGA, key another grid origin hotkey that has been previously located somewhere (which changes the grid to whatever), to attach a couple of caps. on the way, then key yet another hotkey to enter another BGA.
Virtually uninterrupted track drawing with the mouse. Other hand keying hotkeys as you draw?
As an example; this BGA below would require three grid origins to use.
One for the surrounding PCB (assigned to a discrete component somewhere) , one for the outer pads (assigned to an outer pad) and one for inner pads (assigned to an inner pad).
All that would be needed for this feature (ha, ha, not much to ask for ) is a bunch (maybe a dozen or so) of Identifiable Grid Origins with assignable hotkeys and grids.
Indeed. What part is that ???, I have not seen BGA footprints with a offset inner and outer grid,
Altium can do overlapping grids in a priority… Just sayin’. But that’s fairly advanced
**Again, I suspect that simply storing the origin for each grid in use would be enough, and being able ot hotswitch while routing. No real need right now for grid regions but does need to go into the ‘list’.
I also had a similar nuance; we learn from mistakes.
Now, to verify the compatibility of the selected BGA in KiCad, I compare its dimensions and pad layout with the technical description in the component datasheet. Additionally, I ensure that the grid settings in KiCad meet the accuracy requirements for placement.
) is a bunch (maybe a dozen or so) of Identifiable Grid Origins with assignable hotkeys and grids.
