If you are this “hung up” on the single term “pitch” in KiCad, be forewarned that it was much worse in the past; and you are very likely to find a new term to “irk” your sense of how KiCad uses terms.
Meanwhile, the rest of us just deal with the quirks, and enjoy the really cool things that KiCad does EXTREMELY WELL.
Hello, Sprig:
OK—I can understand that you think I am ‘hung up’ on a single term. I can live with that criticism, though I think it misses the point. And, it is not like I don’t appreciate that KiCad is both very cool and very powerful. I am, in fact, quite impressed by what I have seen. And I think, as a newbie, I have made rapid progress getting to know it---- so, the GUI and documentation is certainly good!
On the other hand, I’m trying to do what I can (as a new member of the KiCad community) to point out some things that (as a newcomer to KiCad), I have found to cause…well…head-scratching and knitted eyebrows. I can imagine that things were worse in the past, but they didn’t get any better by the users not discovering bugs, inconsistencies and so forth, then working with the developers to improve the product. Seems to me that, with V5 about to be released, this is a good time to speak up.
By way of summary,
From the workflow, it is clear that Eeschema, Footprint Editor, and PcbNew are modular.
Each of these modules has an orthogonal coordinate system, and ‘grid’ dimensions. It is now pretty clear to me that these coordinate systems may, in fact, be largely or wholly independent of those in the other modules that they share data with.
It is definitely confusing (to a newcomer) when a single module (PcbNew) has more than one ‘grid’ system associated with it. And, that confusion is compounded when indistinct terminology is used. In this particular instance, long-time users might understand that “grid” means one thing in one context, and something else in a different context — but a newcomer would not. Indistinct language steepens the learning curve!
I accept that a degree of contextual understanding will always be required. But my philosophy is, simply, that we have a rich language and a vast vocabulary, so there is no need to make learning more difficult than it has to be by drawing from a shallow pool of words.
No it doesn’t. And bold caps does not make something true.
Given that no one else has ever had a problem with this term, I suggest that in this case it is not a problem with KiCad. I hope you are not going to quibble over the use of every term in KiCad, otherwise it is going to be a long and arduous journey.
Bobc:
Thank you for your comments. I really don’t intend to quibble endlessly. Rene Poschl has already pointed out that I reached the wrong conclusion there (which is something I did not dispute!) and Rene admits that there is a source of confusion here. I have already asked Rene to elaborate on what he means by a “user” grid, as there certainly seems to be two distinct and active “grids” in PcbNew, and both would seem to be under the control of the user…
If some consensus is reached that it’s confusing, I can change that, if a good alternative is proposed. However, it’s normal in any technical documentation or any other non-fiction prose, or actually in all produced human language, that you can add additional qualifications to words to disambiguate. There’s not just one word, there are two phrases: “grid pitch” and “pad pitch”. They are clearly two different things, at least for me.
NOTICE: what I say next should be true for KiCad future version 5. I remember seeing situations where mouse movement didn’t snap to the currently selected grid, but I don’t remember if it was in v4 or in some nightly builds.
I don’t understand. There’s only one active grid in pcbnew, the one selected. There are possible preselected values and then the possibility to define the values precisely yourself. Only one of the possible grids are selected at one time. The grid values you defined manually yourself is called “user grid”. The currently selected grid is the grid where the cursor snaps to. I doesn’t affect the items which were positioned or edited before the current grid was selected. It’s effective when you move or edit items with mouse (or with keyboard arrow keys in WYSIWYG manner). Then the movement of the item snaps to the current grid.
But not everything hits the current grid. The internal coordinate system of pcbnew is based on nanometers. That’s the absolute smallest defined distance of two things in KiCad. Anything can be set to that coordinate system e.g. with the Properties dialog of an item, regardless of the current or previous or future grid. Is this the other grid you’re referring to? If something is imported from e.g. other software, it must be fit to this internal coordinate system. If the other software had smaller coordinate system “pitch” (the smallest value between two defined points), the imported coordinates must be rounded to the nearest nanometer value. If the other coordinate system “pitch” was more coarse, the values will fit without conversion.
As far as I know, the pcbnew coordinate system’s smallest possible distance is never referred to as “pitch”, and the absolute fixed coordinate system isn’t reffered to as “grid”, but I may be wrong.
Kicad has some pre defined grids. But in ecad programs it makes sense not to limit the user to some set of pre defined grids.
So has been introduced another user set-able grid. The user grid.
The user grid is extremely useful. As kicad is more or less a direct cad program. Without the console where you can enter relative coordinates.
Weird grid spacing are very useful for footprint creation. Have a look at my new tutorial to see how this can be done: Tutorial: How to make a footprint in KiCad 5.1.x (From scratch)?
I recall on v4 that when in the new canvas (OpenGL/Cairo, now called Toolset in the recent nightlies) when just moving the cursor around (nothing being moved, not traces being routed, etc) the cursor wouldn’t snap to the grid. This was evidenced in the coordinate readout in the bottom, making setting the local coordinated right on a grid point difficult. At some point the new canvas started snapping to the grid even when just mousing around. (I thought there was a setting for that, but I think the setting I was thinking of was me being able to turn the cross hairs to always show.)
This conversation makes me realize that the grid snap can’t be turned off, or at least I couldn’t find how to do that on the recent nightly I’m running on this machine. I always use grid snap so I hadn’t noticed before. I suppose if one really wants to “turn of grid snap” they can set the user grid to 1nm and then use that to emulate that effect.
“grid must be >= 0,001mm”
Another one of those arbitrary restrictions in KiCad…
My assumption there would be it related to the maximum zoom level currently implemented, again arbitary, but I can understand a dev one day drawing a line in the sand and saying “you cant even buy this tolerance without a military budget”
Or it might even be related to some gerber format limitations. After all it does not make sense to build kicad to be more “free” than the main output format will be. (this of course might already be an outdated restriction but having such a restriction build in at one point makes it hard to remove it as you will not be sure if there is not some part that heavily relies on that restriction.)
To help clarify what I mean by ‘the existence of two grids’ in PcbNew, this image should help:
Here, we see a grid (dots at grid intersection points), with the open dialogue box showing the so-called User Grid setting.
The visible grid is set to 50 mil (0.050 inches).
The “user grid” is set to 1 inch.
Functionally, I can easily understand that the Footprints of the components can be moved (using the Grab command) and that they will snap to a location on the dotted layout grid nearest to where the mouse button is released. That’s all very intuitive.
But that still doesn’t explain the need for the existence of the “user grid”, and why the “user grid” has dimensions associated with it.
As I mused / tried to relate in an earlier posting: if the “user grid” is a mechanism for setting the location of the Origin for a user-based coordinate system (and possibly for defining the Axes [directions] of a User Coordinate System) that would be an understandable function [i.e., understandable in the context that every CAD system defines an untouchable coordinate frame and measuring system, and that the positional values seen by the User are simply the mathematical transformations of that untouchable internal system. So, some users may want or need to redefine ‘which way is up’ and so forth].
But at this time, to me, the underlying purpose and function(s) of the ‘User Grid’ of PcbNew are not clear, whereas the visible (dotted, layout) grid’s purpose is very obvious.
There is only one grid. That grid has a multitude of preset dimensions that can be chosen, or you can select “User Grid” which is nothing more than custom dimensions that are applied to the grid. The user grid, or “custom” grid, allows you set the dimension for each axis independently.
Does that help?
I propose an easy to make experiment. Set the custom grid to lets say x=1, y=5
right click -> grid -> user grid. What do you observe?
I see that this has no observable effect whatsoever; the visible grid (dots) are in the same location, and the snap-to functionality is exactly the same.
Did you really do all the steps i described above? Because i use kicad now for a long time and it always worked like i described above.
Make a screenshot of the full window (such that i can see your top toolbar. There is a drop down menu for grid selection there. It must read “user grid” such that changing something in the dialog you show takes any effect.) You also need to know that you need to press ok in the window you currently opened to see the effect of changing something in it.
The zoom level might also play a role. Kicad hides sub-divisions of the grid if it gets too dense.
Editing the “User Grid” dimensions in that dialog box does not select the user grid, it only sets it’s dimensions. You then need to select “User Grid” as @Rene_Poschl illustrated above.
Ah-HA!
OK, I get it now. I didn’t properly understand the instructions, and up until now I had not noticed that User Grid was in fact one of many choices from within the {right mouse-click menu} Grid Select menu. I think this screen shot (with captions) illustrates this succinctly:
The user defined origin works for any grid. Including “KiCad’s predefined, square grids”
Thanks for that clarification.
The dialog box for the User Defined Grid includes a dialog for setting the Origin. So, it seemed that this origin would be linked only to the User Defined Grid, and that all others would be keyed to some ‘universal’ origin.
I can now see that, not only is the Origin not linked to the User Defined grid but that the Origin can be set on-the-fly by choosing Place…Grid Origin from the drop-down toolbar. So the Origin dialog within the User Defined Grid menu is merely a shortcut.
I should note that I’ve also discovered that there can only be one Origin: If you are using one of the non-User-Defined grid systems and alter the Origin, it changes the setting previously made within the User Defined grid dialog. From that perspective, it’s a bit confusing to have that origin-setting shortcut within the User Defined Grid dialog box.
I observe that moving the Origin doesn’t appear to affect the X, Y and dx, dy readouts at the bottom of the window
. I was expecting that shifting the origin would have precisely that effect.
So, that begs the question: How does shifting the Origin affect the process of laying out the board? Or, posed another way, When and why would I want to shift the Origin? Does it affect the Gerber-file outputs??
