Can anybody tell whats the red cross which is blue marked in the picture down there?
At first I thought its the origon of the grid but when I changed the origon of the grid there came a white one which looks a bit different.
Best regards
It’s the auxiliary axis origin. You don’t have to care about it; there are some plotting options etc. which use it if you want to (but you don’t).
Thanks, but shouldn’t than the start or beginninmg of this line has the same point as the origon (0/0)?
You mean the grid origin? It’s not the coordinate origin. You can’t change the coordinate origin in v5. The grid origin is just the starting point for calculating/drawing all grid points for the currently used grid.
1 Like
In KiCad Y coordinate rises toward down.
If you generate gerbers without placing that red cross than you will have negative Y coordinates in gerbers and other production files. It is probably not a problem for no one except my brother. When I recently gave him (to check as usual) gerbers of my first KiCad PCB he was very surprised why I suddenly after 20 years working at positive coordinates moved to negative.
If you place that red cross to left and down of your PCB you will get gerbers without negative coordinates.
Red and white crosses. There are 2 additional “origins”.
The auxiliary axis, used as origin for the output files, like the drilling file. In my system is a red cross.
The grid origin, in my system a white cross. It sets an offset of the grid origin, relative to the absolute origin. The absolute origin is the (0,0), top left corner that cannot be changed.
With this grid origin the coordinates don’t change but the different grids start now from this point.
Example: If I set the grid origin at absolute coordinates (5.5 , 5.5) mm and now I choose the 1 mm grid, I will move the cursor in 1 mm steps, from 6.5 to 7.5, 8.5 mm etc.
1 Like
It need not to be top left corner.
I am used to set 0,0 point inside my PCB if there is some symmetry to help write for example mounting holes coordinates. When I didn’t found in KiCad the way to write X,Y coordinates relative to point set by then I have decided that under KiCad I will have my PCBs around absolute 0,0.
I have noticed only one not important problem with it. I have defined in page layout the XY axes (lines from 0,-100 to 0,100 and from -100,0 to 100,0). When 0,0 point is shifted out of right or bottom window border the one line you should see disappears. I’ve just checked in 5.1.5 it is still so.
I was talking about the real behaviour of KiCad, not about what it should be.
I think the user set of the origin is in the V6 roadmap.
In my opinion it should be enough if the auxiliary axis may set also the absolute origin.
I was also talking about real KiCad behaviour (and not V6).
I don’t left 0,0 as top left, but place my PCB around it (modifying .kicad_wks file accordingly).
OK, thanks. I think I got it. Global origin can’t be changed. But for gerbers the auxilary axis are used. (red cross). Besides I hope the coordinate system will be changed in future to normal behaviour (y direction goes to the top).
I have read that plan is to let user select if he wont y rising up or down. What is normal it depends. For graphic screen coordinates I think normal is y rising down, but for mathematics is y rising up.
1 Like
great idea to let users decide!
I submitted a patch set to be integrated into V6 months ago. The patch set necessarily changes a low-level interface common to all KiCad applications, which results in a ripple of changes through all code that uses that interface. This provides full support for user-selectable origins in pcbnew, and latent support in eeschema and gerbview.
Just before these patches were to be integrated one of the core devs objected, saying he didn’t like that eeschema was changed at all. The solution he proposed, function overloading, would have introduced what I consider an unacceptably high risk of breakage, as code using the wrong interface would compile cleanly but would not work properly.
Since then I’ve been too busy with work to attempt to address this. I have a patch set for V5 that keeps me happy for the moment. I’ll probably come back to the V6 issue at some point, but I’m not sure when I’ll get to it.
1 Like
Now when the KiCad development is centralized in gitlab it might be useful to fork kicad and keep your code there. It would be public, easy to find and enhance chances that someone else would look at your code.
I think I have never conciously seen coordinates in eeschema, they just aren’t needed there.
I created a GitLab account earlier this morning but won’t have time to do much with it until the weekend.
Interestingly, eeschema already has internal support for the auxiliary origin, but no user interface to set it. I’d given some thought to how it might be used but, like you, I don’t need absolute positioning in a schematic.
The reason eeschema had changes was that the common interfaces that needed to be changed now require a reference to a new object. A global object or singleton would avoid passing that data as a parameter, but a lot of work by other devs has gone into removing such globals for good reason. Most of the patches in eeschema were limited to passing the reference to the new object down as a parameter, following the pattern used by another core developer when implementing a similar feature.
This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.