The origins of 6.0 (pun intended)

[Jeff Young]

There have been some discussions in bug reports and on forums regarding the various origins.

We currently have a file origin, which is fixed. It's absolute value is somewhat immaterial as most board houses will use the edge cuts to position the footprints. Essentially all it does is tell us where to draw the page boundaries and page frame.

We also have a drill origin, which is user settable. I suspect this is mostly legacy, as most manufacturers are happy enough without one. But conceptually one could make an argument that it should set the origin for /all/ file values, not just drill file values. This is probably a low value change.

We also have a grid origin, which is user settable. Conceptually we think of this as just a grid origin, but many of our users think of it as the editing/display origin (which, to be honest, makes more sense).

When locations are edited through the UI, they are presented relative to file origin. There's no particular value in this, while there would be /considerable/ value in presenting them relative to the grid origin.

One bug report suggests adding textboxes for grid-relative positions to the existing textboxes for file-relative positions. I believe this would be a mistake as it just complicates the UI and the file-relative positions have little value to the user.

For 6.0, I would recommend we change the GUI positions to grid-origin-relative.

I can also see an argument for changing the file positions to drill-origin-relative, but I'm ambivalent about that.

[Seth Hillbrand (sethh)]

I'm in favor of a single origin in the UI that controls all position values/offsets. And no ability to separately set the drill origin. In NC drill generation, we can have a checkbox that allows the drill hits to be referenced to either the absolute (file) origin or the relative (UI) origin.

[eelik (eelik)]

For whoever is interested about those discussions...

Here is one relevant user forum thread: https://forum.kicad.info/t/pcbnew-grid-origin/10755

And here the first post in a dev mailing list thread: https://lists.launchpad.net/kicad-developers/msg35763.html (has also a link to a bug report).

[Reece Pollack (reece-pollack)]

I've been using a patch series I developed to change the display origin (and only the DISPLAYED origin) to be the Aux Origin. I've attached a zip file containing the patch series for discussion purposes. They are in no way ready for wide distribution so I haven't ticked the "This attachment contains a solution" box.

Unfortunately, commit 0c2f9b1 "Keep circles controlled by radius" causes a relatively minor conflict that I haven't bothered to resolve yet, so these patches will only apply cleanly to this commit:

    3a8a718 A pesky bug, this one is. (Said in best Yoda impression.)

[Reece Pollack (reece-pollack)]

As can be seen in my patch series, I started with Grid Origin relative coordinates but found this to be problematic.

Consider the situation where you want to place a series of holes/vias/whatnot in a line on a specific spacing. It's easiest to set the grid origin to be the first such object and the grid spacing to the specified spacing, then all following objects fall on the grid. However, doing so changes the displayed origin of every other component, and getting the grid origin back to its original location is a pain.

Using the Aux Origin, this is not a problem. You can manipulate the grid origin all you want and none of the other displayed components change. The infrastructure for maintaining the Aux Origin is already in place, and accessing the origin value isn't too difficult.

Having done my latest project with Aux Origin as the origin for all displayed and entered coordinates has proven to be a great benefit. I strongly recommend this behavior be adopted either as a standard or as a user-selectable option.

Now if we could just make the Y-axis increase toward the top of the screen... (on my list but lower priority).

[Reece Pollack (reece-pollack)]

I've updated my patch stream to the latest upstream master (2cb65f9) for anyone who wants to experiment without having to go back 42 patches. It has literally 5 minutes of testing on it but it looks correct at first blush.

[eelik (eelik)]

It looks like that the original purpose of the Grid Origin is to set a grid offset, not to set an "origin" per se. It's the one point which always hits the grid, or the grid always hits it. Therefore, if the Grid Origin is set as the coordinate origin, is it possible that someone soon asks how it would be possible to set the grid offset independently from the grid origin?

Also, the Grid Origin is presented in the UI so that it seems convenient to change it often. But many users would probably like to set the board origin once (to some important footprint or to a corner of the board outline, for example) and keep it there. Grid Origin can be changed even accidentally. It would be good to at least ask for confirmation if the coordinate origin is changed.

How about letting users set the actual coordinate origin? As far as I can see setting the coordinate origin would be identical and logically same as moving everything else. It's now possible to move everything else except the print page frame, or is there something else? The page frame feels like a fossil anyways. If we can get rid of that, what would prevent setting the coordinate origin anywhere, possibly implementing it as just moving everything else?

The "Grid Origin" could then be renamed as "Grid offset reference point" or something else more descriptive (or more ambiguous, depending on how you think about it), which wouldn't distract users to think it's an actual origin.

[Tomasz Wlostowski (twlostow)]

I don't understand the point of the whole discussion. Can't we simply add a feature that recalculates all coordinates when a new coordinate system origin (can be made equal to grid origin) is changed? This way, there's no need to modify any input/output code and the coordinates in the PCB files are always in sync with what the GUI shows.

-- my 5 cents
Tom

[Jeff Young (jeyjey)]

OK, based on feedback so far I've got a new proposal:

1) we leave the grid origin as it is
2) we rename the aux (aka drill) origin to the "board origin"
3) internal positions (and therefore file and GUI positions) are relative to the board origin

[Wayne Stambaugh (stambaughw)]

I agree for the most part. There are distinct coordinate origins that
make sense to me. One origin is used when placing objects and routing.
The other origin is used for plotting. I don't see how a single origin
makes sense let alone the difference between absolute and relative
coordinates so I think this needs be well defined before we attempt to
implement anything.

Wayne

On 5/28/2018 3:32 PM, Tomasz Wlostowski wrote:
> I don't understand the point of the whole discussion. Can't we simply
> add a feature that recalculates all coordinates when a new coordinate
> system origin (can be made equal to grid origin) is changed? This way,
> there's no need to modify any input/output code and the coordinates in
> the PCB files are always in sync with what the GUI shows.
>
> -- my 5 cents
> Tom
>

[CeDeROM (cederom)]

Nice discussion folks. I also would find it useful to have global origins for file storage and export to become standard compliant and dont mess anything, but some kind of local origins for "dusplay" too that would help me a lot with complex mechanical structures or precision components placement inside a local board from its corner or middle point..

Any kind of user/local/board origin would help me to easily set zero point and then position stuff according to that zero point.. we don't really have to modify anything where the "real zero" is.. its just about relative positioning around a specific point (origin)..

[Mariusz (mariusz-ciszewski)]

Similar topic:

https://bugs.launchpad.net/bugs/1773638

[Mariusz (mariusz-ciszewski)]

This od similar:
https://bugs.launchpad.net/bugs/1770897

[eelik (eelik)]

twlostow said:
"Can't we simply add a feature that recalculates all coordinates when a new coordinate system origin [...] is changed?"

That's basically what I said - that moving the coordinate origin is equal to moving everything else. That, of course, requires everything else (including the print page frame) to be movable.

"(can be made equal to grid origin)"

The grid origin has a function of its own. Now it's possible to keep the coordinate origin but offset the grid so that the points which would otherwise be unavailable become available as grid points. If you have the grid origin in (0 , 0) you can't access (0.5mm , 0.5mm) etc. with 1.0mm grid. If you set the grid origin to (0.5 , 0.5) you can access each 0.5xN points with 1.0mm grid. That's why I asked in the previous comment: "if the Grid Origin is set as the coordinate origin, is it possible that someone soon asks how it would be possible to set the grid offset independently from the grid origin?"

How useful the current grid origin behavior is to each user, I don't know. Setting the grid origin may have also unwanted effects if the user doesn't understand what it does. In any case, I bet this is the same as for every other existing KiCad feature: there certainly are people who use that feature and even more who misuse it in some unanticipated ways for their benefit and get angry if you remove it.

[Sylvain Munaut (tnt)]

Am I missing something or would just letting the user set the origin anywhere in the page layout editor be enough (instead of just the 4 corners atm) ? (I know it would for me). Or just move the worksheet in the layout / schematic editor.

That would be fully compatible with the current situation and all this would really do in the end is to change where the worksheet is drawn on screen.

I mean really I'd want the coordinate in the file to match what I see in the UI (I do edits the files manually some time).

[eelik (eelik)]

@Sylvain - that's what I said in comment #6. Having a fixed coordinate origin/printable page combination is just weird. I have proposed elsewhere that the "worksheet" (= printable page) could be completely configurable, i.e. could be drawn as a box with non-fixed size. It would make zooming/panning for printing very easy (which is now very difficult). And as I said in comment #6, moving the coordinate origin is logically the same as moving everything else (including the worksheet).

In that way we would get rid of the complicated "visible coordinates different than internal coordinates" UI and implementation (for which Reece has unfortunately done much work - I'm sorry, Reece, if I'm correct and if it could have been made simpler. I just don't see a good reason for this further complicatedness which comes with the two different coordinate systems, internal and visible).

[Mariusz (mariusz-ciszewski)]

So generalny speaking what's the easiest? What's could to give us chances to see (and set) components location based on a previously (manually) placed (local?) PCB origin?

[KiCad Janitor (kicad-janitor)]

KiCad bug tracker has moved to Gitlab. This report is now available here: https://gitlab.com/kicad/code/kicad/-/issues/2148