Coordinate origin moving

[Novak Tamas]

I'd like to see a coordinate system origin replace. (something like #593877, but new explanation)
I usually place some components (mounting/technological holes, connectors) based by mechanic CAD design. In pcbnew I drop the component somewhere, then edit it and enter X Y coords by numbers. It is measured from some reference point --e.g. top left corner of the PCB.
Hitting Space for a relative origin is not really usable for this purpose. What I do now
- I hit Space the relativ origin to be on top-left corner, then
- note the dx & dy between origin and rel.origin, and
- manually (pocket calculator!!) add displacements to coordinates from Pro/E to enter X,Y to component data.

When I hit Space for a relative coord system,
- this should be saved to kicad_pcb file
- all component coordinates should be meant from the relative zero, not from the absolute (absolute values will be stored, but displays and numeric inputs are on relative)

[Nick Østergaard (nickoe)]

I don't exactly understand what you want.

Have you tried the move exact feature, which will make you able to move objects relative from their current position?

[Novak Tamas (novak-7)]

To make it (more) clear:
There is a drawing frame in pcbnew, and the origin is somewhere out of the frame on the top left. If I place my board to the middle of the drawing space, then my board top left corner is not (0;0) (it's actually 65.5;67.02mm) . When I got coordinate pairs from Pro/E (3D CAD) e.g. to place a mounting hole at (25; 40mm), I can't directly enter "25" into "Position X" Edit field of "MountingHole-3.2mm" Component, as 25 is from the top left origin not from the top-left of my board. I must enter [25 + 65.5]= 90.5 to find the correct place.

If there was a "origin move" function, I could use the value "25" directly.

[Novak Tamas (novak-7)]

So please put to wishlist the next (I think minor) modification:
Extend the Ctrl+M "Move footprint exactly" function with a radiobutton group with the following options:
- relative move from actual position
- absolut coords of new place
- secondary coords of new place (in space-hit-given coord system).
The new position will be stored in normal absolut coords system, so modification
needed only at move function.
The selection of the above radiogroup should be remembered: no need to set again at next Ctrl+M.

[Cirilo Bernardo (cirilo-bernardo)]

If you are working from Pro/E maybe it's better in the long term that we implement the IDF importer; can Pro/E create an IDF file? Otherwise if you can export a list of the positions you can use a spreadsheet to calculate the coordinates for the KiCad pcb.

I can't comment on modifying the behavior of Ctrl-M; I'm not familiar with that part of the code.

[Chris Gibson (chris-w-gibson)]

I think a neater solution would be to have two positions in component properties: One absolute, and one relative to the grid origin. Perhaps slightly challenging to agree the exact functioning.

[Novak Tamas (novak-7)]

@Cirilo: I can't image importing IDF, as mecha CAD model contains injection moulded plastic part, not the PCB+components. The order is:
i mechanic (inj.moulding plastic) designer defines space for electronic components based on our discussion (connector placement, mounting hole placement, room/height needed for particular components)
ii electr.designer makes PCB with component models, then exports PCB to WRML
iii mechanic imports WRML to CAD to check if all fits. If not, ii and iii repeating.

If plastic parts should be displayable somehow (making sections?) that would be fine, but it is a too long way to go.

[Novak Tamas (novak-7)]

@Chris: I think having/storing two positions at each component needs a lot of modifications.
Now we have the hit-space relative position. Displaying both coords (abs and rel) on the status bar is already done. If one could reset relative position (out of going to absolute 0;0 and hit space again...shift-Space or Ctrl-Space?), an easy solution would be:

All displayed and manually entered coords to be represented as relative position. (This can be always done: if rel.position is not set, then it's 0). The original absolute coords can be stored with no modification. Adding relative dx, dy values happens only when editing/displaying x,y (or r,alpha) values.
Maybe dx,dy should be saved to kicad_pcb file to be reloaded at next run.

[Novak Tamas (novak-7)]

@Chris... one more thing: I think grid origin and the relative coord system are to separate, independent things. One can be set at "Dimensions - Grid - Origin", the other is by hitting Space.

[Matthijs Kooijman (matthijskooijman)]

Also remember that there is also the "auxiliary axis origin", which AFAIK is only (optionally) used as the origin when output e.g. gerber files.

[Evan Shultz (evan-shultz)]

+1

I'm new to KiCad but not to PCB design, and am quite impressed with the power of KiCad for a FOSS tool! That being said, it is hard to exactly place a footprint which is often needed to mate with a mechanical part.

Typically, I see the lower left corner of the board being used as a reference point for DXF/IDF/IDX import/export and component placement. This means that manual calculation, mentioned above, is required. Or when using Move Exactly the part needs to be placed twice: the first to set a reference and the second using Move Exactly to get the final location.

IMO, the relative origin ("space bar") is useful when checking dimensions but it's not helpful for placement. A workaround would be to enhance the Move Exactly command so that it can place with respect to the relative origin. This could be as simple as a "From reference origin" checkbox on the Move Exactly dialog. While I mention this as a workaround for this particular issue, I think that's a great feature that's worth it's own wishlist item.

While the page layout origin can be changed, that's a hurdle that I expect many users won't discover and certainly won't like. And even if the page layout had an origin elsewhere, that origin won't apply for all board sizes and shapes.

Allegro and PADS allow the origin to be moved and, as I understand the issue, a moveable origin seems the best solution in KiCad as well.

FYI: Yes, Pro/E can import and export IDF. Even better, it can handle IDX (similar to IDF but with change/reject control and incremental addition).

[Omer bayram (omerbayram)]

The same wish here as well. @evan-schulz seems to define the problem nicely.

If the board is mating with a mechanical part, footprint placement with coordinates is a must.

I have just started using KiCAD, and I'm a long time Altium User. I'm loving the KiCAD experience so far. It's very elegantly designed, simple and easy to use. I believe I'll stay being a user for long time.

User defined origin selection is definitely very important. When the PCB needs to match with a mechanical design, you need to place a lot of footprints and vias with exact coordinates. Having the origin at the edge of the board (or at the center for circular boards) is a huge help. Most of the time, you want the origin of the mechanical design and the PCB design to be same, so that you can easily see placement coordinates for footprints and vias.

I thought "Grid Origin" button, at the right-hand side toolbar in Pcbnew, does user defined origin, but it doesn't seem to be doing anything. Maybe a button similar to this can define a user defined origin. Then all absolute coordinates will be relative to this new user defined origin.

[Wayne Stambaugh (stambaughw)]

The "grid origin" is not the same as the "origin for drill and place
files" which is what I believe you are referring to. You want to use
the "origin for drill and place files". Actually this is the origin
used for all plotting and fabrication outputs. The set "grid origin"
hotkey is 'v' which may be what you are experiencing. This happens to
me frequently. The red target is the indicator for "origin for drill
and place files" and the grey target is the indicator for the "grid
origin". Both origins can be the same point but they don't have to be.
This allows for flexibility when using the grid for footprint placement.

On 11/11/2016 2:41 AM, Omer bayram wrote:
> The same wish here as well. @evan-schulz seems to define the problem
> nicely.
>
> If the board is mating with a mechanical part, footprint placement with
> coordinates is a must.
>
> I have just started using KiCAD, and I'm a long time Altium User. I'm
> loving the KiCAD experience so far. It's very elegantly designed, simple
> and easy to use. I believe I'll stay being a user for long time.
>
> User defined origin selection is definitely very important. When the PCB
> needs to match with a mechanical design, you need to place a lot of
> footprints and vias with exact coordinates. Having the origin at the
> edge of the board (or at the center for circular boards) is a huge help.
> Most of the time, you want the origin of the mechanical design and the
> PCB design to be same, so that you can easily see placement coordinates
> for footprints and vias.
>
> I thought "Grid Origin" button, at the right-hand side toolbar in
> Pcbnew, does user defined origin, but it doesn't seem to be doing
> anything. Maybe a button similar to this can define a user defined
> origin. Then all absolute coordinates will be relative to this new user
> defined origin.
>

[Omer bayram (omerbayram)]

@stambaughw: I haven't plotted the fabrication outputs for my first design in KiCAD yet, but I will make sure to use "origin for drill and place files" function, so that gerber files will have correct origin. Having the flexibility to define a separate origin for fabrication outputs is definitely a useful feature, especially for panelized PCB designs.

I believe I didn't explain my problem clearly. When I set a new origin for the grid, using "Grid Origin" (white circle with a cross), it doesn't seem to help me with the footprint placement. I expected to define footprint positions based on this new defined "Grid Origin", but even after I set a new "Grid Origin", the footprint position coordinates are still relative to the old origin, which is at the top left corner of the layout sheet. So nothing seems to change for footprint placement, after using "Grid Origin" function. Maybe, I can not see how "Grid Origin" is helping me for footprint placement.

My expectation was,
- I define a new origin at (100.00,100.00 relative to old origin),
- I open footprint properties of R1,
- I enter (0.00, 5.00) to position coordinates of R1
- R1 goes to (0.00, 5.00 relative to new origin) (100.00, 105.00 relative to old origin)

This way, I would be able to place all my footprints, vias, board edges etc. relative to user defined origin. Exact position placement is necessary for PCB designs, which needs to match with mechanical designs or with other PCB designs (pin connections etc.).

Of course, user defined origin is not a must. There are workarounds for this, like imagining your own origin and calculating every coordinate by adding/subtracting your imaginary origin's coordinates, or deleting layout sheet and using the already defined origin (which is what I'm doing right now). I believe that a user defined origin would be the neatest solution to this.

Maybe, the reason why I expect user defined origin is because I've been using it in Altium. I'm not expecting KiCAD to be the same as Altium, and I wouldn't like KiCAD if it were. So I'm trying to keep and open mind for new solutions, but for this case I can't think of a better solution than user defined origins, for PCB designs which needs to match with other mechanical/PCB designs.

[Evan Shultz (evan-shultz)]

@Omer
"Maybe, the reason why I expect user defined origin is because I've been using it in Altium." And every other PCB tool I've ever used or demoed going back a few decades. Plus the complaints and questions about this KiCad behavior (just search for this topic online).

KiCad's decision to not follow convention by providing the features/behavior that users expect when migrating to KiCad is unfortunate. And because the current behavior is unintuitive, new users are also caught off-guard.

8 subscribers to this bug and a bug heat of 54 confirms that KiCad is not meeting users' expectations/desires, even if there are workarounds within the current KiCad tool. While I'm incredibly impressed by KiCad overall, this is is one example where a change is easily justified and warranted.

[Wayne Stambaugh (stambaughw)]

On 11/11/2016 12:06 PM, Evan Shultz wrote:
> @Omer
> "Maybe, the reason why I expect user defined origin is because I've been using it in Altium." And every other PCB tool I've ever used or demoed going back a few decades. Plus the complaints and questions about this KiCad behavior (just search for this topic online).
>
> KiCad's decision to not follow convention by providing the
> features/behavior that users expect when migrating to KiCad is
> unfortunate. And because the current behavior is unintuitive, new users
> are also caught off-guard.
>
> 8 subscribers to this bug and a bug heat of 54 confirms that KiCad is
> not meeting users' expectations/desires, even if there are workarounds
> within the current KiCad tool. While I'm incredibly impressed by KiCad
> overall, this is is one example where a change is easily justified and
> warranted.
>

This confirms KiCad does not work the way you expect it too not that
KiCad is not meeting users' expectations. Whether that is good or bad
is debatable. You should never make this kind of assumption when moving
between tools. This doesn't apply to just KiCad. I'm not opposed to
changing the behavior of the either the grid or plot origins but it's
something that would have to be discussed.

[Robbert Lagerweij (rlagerweij)]

I had a crack at this problem and came up with the attached solution to this.

The patch adds a radio box to the move exactly dialog in pcbnew which allows selecting a reference point for the move. The default behavior is to use the current position as a reference point which is as it was before this patch. The other 3 options are sheet origin, user origin and grid origin. The last chosen reference point is saved and becomes the default for any subsequent moves.

This version of the patch uses the center for any non-modules, i.e. moving a text object “LOL” moves the middle of the “O” over the chosen coordinate. For footprints it moves the top leftmost pad to the chosen coordinate, the center of the pad for through-hole footprints and the top left point of the pad for SMD.

Does this make sense to everyone? I’m open to changes on this behavior.

[Robbert Lagerweij (rlagerweij)]

Here's a screenshot of the dialog.

[szymon (szymon123)]

For me it looks good, however it require to test it during drawing real project.
Only drawback I see for now, it is impossible to check what is component position against current user origin. At least old Protel had this function, but otherway, if I want to clone some dimension, reference point not important when both components use same reference point (but how about two diffrent boards opened in two concurrent aplication?)

I have another idea to discuss, how about implement this feature in normal edit window.
When user type number move to position relative to sheet origin (like in old way).
When user type #+number or #-number, use user origin
When uset type $+number or $-number, use grid origin
When user type @+number or @-number, use previous position (just move relative to previous position).
After reopening the window should show numeric value relative to sheet origin.

It would be nice to store the history of movement like expression 0@+2#-1 but this will impact lot of modules in the app.

I FEEL WE ARE REINVENTING THE WHEEL, WHY CAN WE RECALCULATE POSITION OF ALL COMPONENTS WHEN CHANGING THE REFERENCE POINT?

[Novak Tamas (novak-7)]

@Robbert very promising, many thanks!! I actually do have a live drawing project, but can't test it yet as I'm on Windows and don't dare to recompile with your patch. Do you know when this patch will be contained in Windows nightly build?

@szymon
"I see for now, it is impossible to check what is component position against current user origin."
If you have user origin set, you can see those coordinates on bottom status line (right to absolute coords). If you invoke moving the component by pushing M, cursor jumps to pick point (anchor or the middle of a pad) and user coord can be read.
AFAIK what you can't do is reading coords relative to grid origin.

[Wayne Stambaugh (stambaughw)]

On 1/5/2017 4:37 PM, Robbert Lagerweij wrote:
> I had a crack at this problem and came up with the attached solution to
> this.
>
> The patch adds a radio box to the move exactly dialog in pcbnew which
> allows selecting a reference point for the move. The default behavior is
> to use the current position as a reference point which is as it was
> before this patch. The other 3 options are sheet origin, user origin and
> grid origin. The last chosen reference point is saved and becomes the
> default for any subsequent moves.
>
> This version of the patch uses the center for any non-modules, i.e.
> moving a text object “LOL” moves the middle of the “O” over the chosen
> coordinate. For footprints it moves the top leftmost pad to the chosen
> coordinate, the center of the pad for through-hole footprints and the
> top left point of the pad for SMD.

I like this solution except for the footprint coordinate position. I
would prefer that the footprints be moved relative to the 0,0 point of
the footprint rather than the upper left most pad. I often use the
center of footprints for locating them so I would have to calculate the
delta between the center and upper left pad which would defeat the
purpose of relative moves. I would also be fine with adding another
option to the list use the footprint center rather than the upper left
pad. If you decide to implement it this way, please make it clear to
the user how the footprint is going to be positioned.
>
> Does this make sense to everyone? I’m open to changes on this behavior.
>
>
> ** Patch added: "origin.patch"
> https://bugs.launchpad.net/kicad/+bug/1460460/+attachment/4800569/+files/origin.patch
>

[Novak Tamas (novak-7)]

It's a very nice feature to pick the footprint at its anchor or at the middle of a pin (whichever is the closest) when hovering over the footprint.
On the other hand when footprint is referenced any other way (e.g Ctrl-M) having the option of "footprint center or upper left pad" picking point would be even more flexible...or it should simply be grabbed at its anchor (picking the closest pin to the actual cursor position seems to be erratic).

[Robbert Lagerweij (rlagerweij)]

I'll see what the easiest way is to find the 0,0 location of the component, although I think this may give unexpected results if footprints are not built up around that anchor in the same across libraries. I'll also look at adding the option to select an anchor although the layout of the dialog may not look as clean. I could add dropdowns instead of radio boxes.

I also really like the idea of szymon above to allow references to different origins in all coordinate textboxes by adding a letter prefix, although it is a separate issue from this dialog.

[Robbert Lagerweij (rlagerweij)]

I created a version of the patch which uses the component's stated position but it seems that indeed not all components are built up in the same way. For instance the DIP8 footprint is built from the top left pin but the SOIC8 is built from the center.

It seems like I may have to run through the pins of each component and determine the mid-point between them to get consistent result across libraries.

Is the center of the component what is commonly used as an anchor in the industry?

[Novak Tamas (novak-7)]

Anchor is important:

- when you rotate footprint it rotates around the anchor. If anchor is very far from its body, footprint seems to be teleporting away:))

- a blue line points to the owner footprint (to its anchor) when moving value or reference.

IMO calculating a center is not a good idea, as there are unsymmetrical components and their center will be undefined. E.g. pins won't snap to any grid when calculated center does snap to grid.
Let placing the anchor be the responsibility of footprint designer.

[Evan Shultz (evan-shultz)]

KLC 6.3 and 6.4 (https://github.com/KiCad/kicad-library/wiki/Kicad-Library-Convention) state the anchor position, and explains why what you saw for DIP8 and SOIC8 are correct. And as stated above, there are lots of exceptions and you can't count on the anchor position to be the same for every footprint type (in addition to old footprints that don't adhere to KLC anyway...).

As an avid user of KiCad, thanks for your work, Robbert!

[Robbert Lagerweij (rlagerweij)]

Here is a version of the patch which uses the footprint anchor as a reference.

Maybe some people can try this and if there is a clear wish for a drop down to allow other anchor options, I'll code that up.

[KiCad Janitor (kicad-janitor)]

Fixed in revision e57c962336973a834ad2619682680e135f012146
https://git.launchpad.net/kicad/patch/?id=e57c962336973a834ad2619682680e135f012146