I’ve read a bunch of threads on here implying that this feature, as of 2019, was ‘just around the corner’, but I do not understand how, 5 years on, this isn’t possible.
Like in a mechanical CAD program, I want to be able to position PCB footprints (and equally importantly groups!) numerically, but for the life of me, I cannot figure out how. I don’t want relative positioning (which I understand is possible with Shift-M). I don’t necessarily care about being able to set the origin myself (although that would be really nice). I don’t care about being able to choose whether positioning is relative to top/left, center, or any other point (although that would be really nice) as long as it’s consistent. Unless I’m blind, or it’s never come up on the forum (with a pointer to a real solution), there does not seem to be a way to position items and groups consistently, via numeric input, relative to some absolute grid.
I’ve tried using the “Position Relative To > Grid Origin” and it seems to do something vaguely reasonable for single items, but without a way to set the origin, this is actually not very helpful. Try to position a group relative to “Grid Origin” and the behavior is completely different.
Am I missing something here? It seems like absolute numerical input positioning for something that controls the physical position of components on a PCB, and thus how elements like LEDs might line up with a physical enclosure, could be pretty important, so I’m puzzled that it doesn’t appear possible in KiCad.
I’ve looked at the text that goes on the clipboard when copying elements, so I know there is absolute positioning data in the model. Is there really no way to enter absolute positioning through the UI? Or is hand-editing the .kicad_pcb file the only way?
Can someone open my eyes on this one? Or convince me why I don’t need this when I very much feel that I do?
With KiCad V4 I decided to work around absolute 0,0 coordinate (top left sheet corner) to have easy positioning of symmetry holes for example (I have described it several times in the past).
I’ve no KiCad here, and I rarely use numerical positioning but as I remember when pressing E on footprint the window for its editing opens with absolute coordinates among others.
Even I have read KiCad PcbNew documentation last time in 2017 I don’t believe using this ‘E’ is not described in current documentation version.
I am not using numerical positioning as I am working with 0.1mm grid and I have never specified LED or hole positions with greater precision than 0.1mm so I am just placing it using grid.
I’m sorry but I’m getting quite lost in all your texts. About 80% of your post seems to be about explaining things that you don’t want.
I never tried numeric input before, but I guess it can’t be too difficult.
Enable: PCB Editor / View / Show Properties manager. This opens a new pane on the left side of the PCB editor.
Select a footprint (not a pad!). It’s (X, Y) coordinates show up in the properties manager.
Type in some numbers for: Position X and Position Y.
Yup, that worked. just changed position of R4 to (100, 83).
Now try some messin’ about a bit with the coordinate system.
First select the File / Place Origin icon with a long click in the toolbar on the right that folds out the selection buttons (the other is Grid origin
Now place this Drill / Place File Origin near R4. I see it as a red cross with circle, but the location of R4 is still (100, 83).
PCB Editor / Preferences / Preferences / PCB Editor / Origins & Axes / Display Origin: (o) Drill/place file origin and then the position of R4 changed to (-5, 2).
You can also swap direction of axes here. So with this combination you can set a (temporary) zero position, and then directly type in coordinates in the properties window. Is this sort of what you wanted?
You can also edit the properties of a footprint, and type in coordinates in this window. R4 now also shows as (-5, 2) so it follows the coordinate system I have just set up.
I have also been looking a bit for a big spreadsheet like overview of all properties of all footprints. I guess it’s not implemented in KiCad. I mean a sort of equivalent for Symbol Editor / Edit / Pin Table.
After creating a group, you can not set the coordinates of the group via the Properties Manager. Only some very basic properties of a group are visible:
You can enter the group (at which point all elements in the group are selected), and then enter a coordinate for the selection. In this case I moved both resistors to an X position of 6.
This does also on any selection of only footprints (Use the filter in the lower right corner). The Properties manager always works on the selection when a selection is present.
I’m curious what you mean by “enter the group.” I ‘click down into the group’, and then only the thing that I clicked down into appears to be selected, and if I change it’s position in the properties panel, only that element moves. What does it mean to “enter the group” while still having everything in the group selected?
You can only manipulate individual items in a group after a group has been entered. The group is “exited” once you manipulate an object outside of the group, and then all objects of the group are treated as a single entity again.
No, it’s the other way around, read my previous comment again:
For me at least, at the moment the group is entered, all objects in it are selected. I have to create a new selection inside the group to change this.
After a little experimenting, it looks like this works if the items in the group are all the same kind of thing, but if the group includes, say, NPTHs, and footprints, and tracks, and boxes, the only property I can edit is “Locked”.
If I could easily get the size of a group, and I could place it at 0,0 using the RtClick > Positioning Tools > Position Relative To… > Grid Origin feature, then I could bust out the calculator and figure out the numbers to put into a RtClick > Positioning Tools > Move Exactly… to get it positioned with the upper left corner at the origin, and go from there.
I did have some workaround ideas here though… I can put a box around the outside of the group, then I can click down into the group, and get the properties of the box, and calculate the group size from the box’s properties. Still somewhat imprecise, but at least it’d be repeatable.
Another idea I had was to use the Place > Grid Origin and let it snap it to the upper left corner of the box, then work from there to figure out where I am relative to the “native” grid origin, and then Place > Reset Grid Origin to go back to the ‘real’ world.
The bottom line is that all the workarounds I’ve proposed are pretty onerous. I’ve been a software eng for decades, so I know there’s nothing more hated than a “Why don’t you just…?” comment about your software. I even worked on a graphic package for almost a decade, so I know how painful it is to handle grouping and group rotation, etc. – I get it – that said, I must admit it’s a bit of a shock to find that KiCad has comparatively quite advanced features like differential pairs, and microwave shapes but not basic sizing/positioning features of the ilk I’m talking about here.
It is a part of the open source nature of KiCad. There is some leadership in the form of the KiCad Services corporation, and a bunch of developers who have long term contributions. JP Charras, who started the KiCad project over 30 years ago is also still affiliated with the project. But in essence most of the KiCad developers are working on KiCad in their free time and for fun. And they are of course free to choose which features they like to work on and in which order. There is an option to sponsor priority development via https://www.kipro-pcb.com/, and as a nature of the open source project, you can pick up some development yourself (especially if you have a programming background).
If I remember well, the first addition of differential pair routing was sponsored (5+) years ago by the Raspberry foundation. Addition of groups is very recent in KiCad’s history, and therefore groups do not have many features yet. A group can be created, entered or moved but that is about it, and this is indeed an obvious limitation. This will probably get extended in the future.
The limitation you are bumping into is mostly a limitation of the properties manager itself, and not of groups. (The properties manager is also a recent addition in KiCad). At the moment it simply hides a lot of properties that are not common to all objects in the selection. A logical extension would be to show a separate tree sorted by object type in the properties manager, so you have easy access to for example the X position of all footprints, while ignoring the X position of tracks that are also in the selection.
KiCad is doing very well as an open source project. Development is speeding up over the last bunch of years, donations are increasing, and I’d be very curious to hear more from Seth Hillbrand and Wayne Stambaugh what the progress is over the years for the commercial support for KiCad. For the last few years, there are some 200 issues both opened and fixed each month on gitlab, and with continuously between 1500 and 2000 open issues there is plenty of things to do. The main bottleneck for KiCad is the amount of developers and the hours they are willing to put into the project.
If you want to do some KiCad development yourself, you should start with meeting the people, for example by subscribing to the developers mailinglist. Or you can just have a go at gitlab and start with one of the many minor issues and bring it to a merge request open for review and acceptance.
It is very difficult to use the positioning tools to locate Groups because asymetrical groups have no predefined centroid/anchor and I have not found a way to create a Group Anchor.
Kicad, with some sort of internal magic, seems to create a group anchor for using Positioning Tools, but Kicad does not display this Group Anchor before using the Positioning Tools, so the Positioning Tools function is useless.
The solution to create an Anchor for ANY shaped Group can be found with @qu1ck 's below reply.
The Positioning Tools will only work successfully with a perfectly symetrical Group where the user knows beforehand the Group Anchor location.
To move a Group numerically, it seems the best way is to set up a Grid Origin Point and move one item in the group with respect to this Point. This distance change can be read with the X & Y position at the centre-bottom of your screen. Similarly, dx & dy can be used the same way.
Maui made me afraid of looking at the bigger picture, but jmk’s response made me think about what your final intention is with wanting to position whole groups. The idea behind it, is that it is quite possible that the Replicate Layout Plugin may be a better way to achieve your goal.
Group anchor is assumed to be geometrical center of it’s bounding box. Using that you can manipulate the anchor to be where you want it to be by drawing a large circle with a center at desired position of the group anchor and radius big enough to encompass all the items in the group. That way the center of the bounding box will be where the circle center is and you can use positioning tools predictably.
If you keep the circles on a user layer you can hide them easily.
I’ve been thinking (not easy for me; also possibly dangerous )
I suppose the only other solution for a Group Anchor would be for Kicad to display the Group Anchor when a Group is formed.
Add this feature to the Objects list in the Appearance Manager so it can be assigned a color and also be switched on and off.
Maybe worth a Feature Request?
Any comments anyone?
Its a fairly common workaround in many software. For example Adobe Illustrator users do this all the time because it too does not allow you to specify the center in all cases.
For some use cases you might also want to look at the Place Footprints action plugin. It supports a couple of extra programmatically footprint placement modes (spiral, circular with defined rotation step …). And it can place either sequentialy numbered plugins or same footprints from multiple sheets.
The plugin main intention is for use with Replicate Layout plugins.
… but I do not understand how, 5 years on, this isn’t possible.
This language has irked me a little bit. Those of us who develop KiCad are primarily volunteers. We have a whole load of stuff we’d like to implement because of our own interests, then there is the ongoing maintenance burden of the existing codebase (bugfixes, library changes / upgrades, etc), and then most users have their own wishlist. Where stuff happens is the intersection of time, inclination, and those competing requirements.
The joy with open source software is that you can figure out your favourite missing feature, implement it, and submit a merge request for it.
Don’t stress too much. These posts occur ocasionally
If the OP had thoroughly checked Kicad 8, he would have found the solutions to all but the “Group Anchor positioning” have already been implemented (ref. Paul’s posts).
Oh I am very unstressed. I think it’s just worth reminding people that there’s a reason they’re not paying for open source software, and that there are volunteers that make it possible.
From time to time it happens here some wording be not perfect. KiCad forum is the first international forum I am at. Being here I’m trying to learn to ignore wording and see only information. And information is that someone don’t understand something - it is certainly his problem, not ours.
)