Circuit symbols and PCB components not on grid

[nytechaudio]

I’ve been using KiCad 4.06 (Windows and Linux) for about a year now and I’ve recently upgraded the windows machine to 5.1.2 and I’m having a problem with schematic and PCB symbols moving “off grid”

Heres a screenshot of a PCB to show what I mean.

In this example all the components apart from the hole were imported via netlist and placed on a 1mm grid and all the PCB design tools worked as normal.

After saving and re-opening the PCB layout all the symbols and tracks seem to shifted sligtly “off grid” although the edges and the hole (A symbol added in PCB layout) remain on grid. (look at the cross hair cursor which should be on the pot central pad).

Moving an “offset” component snaps the crosshair (and the component to grid but on placing it somewhere else it goes off grid again.

Anyone got any ideas ? I can do some troubleshooting but I need to know where to look.

The affected PC is running windows 7 64 bit with an Intel I7 processor and NVidia GForce GT710 graphics adaptor.

Thanks in advance for any help resolving this

[Rene_Poschl]

I assume you are confusing symbols and footprints in your text. Or do symbols in the schematic move as well? What is the difference between footprints and symbols?

---

Additionally: did you double check that the coordinates of the parts changed? It might be that this is a rendering issue. (Maybe the grid dots are rendered at the wrong position.) I am ´mainly asking this because the tracks seem to still attach correctly which they would not really do if the footprints really moved around.

[paulvdh]

I do not understand what’s happening.
If I understand you correctly you put everything exept the mountingholes (and outline?) on a 1mm grid, while your screenshot shows the reverse.

As Rene said, the pads seem to line-up nicely with the THT pads of the components, and it’s impossible for us to compare your screenshot with what it should have been.

It seems you have a Linux box with an older KiCad versrison which does not have your grid problem.
Can you compare your board (or an older backup) between those 2 versions?

It’s also possible you have shifted the grid itself.
You could have done this with the grid Icon with the red dot in the lower right just above the caliper measurement tool: or from the menu:

Pcbnew / Place / Grid Origin.
Pcbnew / View / Grid Settings.

Another possibilyt is that you somewhere in the past moved the whole board by dragging a box around it, and i that process lined up the board in a different way then you were used to.

@nytechaudio

Moving an “offset” component snaps the crosshair (and the component to grid but on placing it somewhere else it goes off grid again.

When you move stuff, the cursor does not only snap to the grid, but also to tracks and pads (including the original location of the Footprint / pad you try to move).

The cursor also tends to snap to the center location of components, which may also lead to confusion.

If you make tracks / zones / pads transparent with the icons on the left it’s also easier to see what you’re doing.

If you think the footprint have moved relative to the board outline or holes, then measure the distances with the “measure tool”, and compare with an older backup.
You can also look at absolute coordinates of stuff from the coordinates in the status bar at the bottom of the PCB:

[nytechaudio]

Hi guys - Thanks for the quick reply.

Obviously some bad descriptions on my part so I’ll try to clarify the situation.

This project was created entirely in 5.1.2 but some of the symbols (Circuit symbols) used were created in 4.06 but appeared to re-map into the new version of Eeschema with no problems. No problems laying out the components, drawing the circuit diagram or creating the net list

No problem at all importing the netlist into PCBnew and laying out footprints onto 1mm grid. Board outlines and the mounting holes (footprints added directly in Pcbnew - Not on the Eeschema netlist) also snapped to grid properly. Also no peoblems attaching tracks to footprints. Everything worked as expected.

Saved project and re-opened the following day. Board outline and holes (footprints added in Pcbnew) are still properly on grid. However all the footprints imported via netlist have moved off grid and the tracks seem to have moved with them.

I checked the co ordinates of one of the offset components by trying to add a track which successfully snapped to the pad center (off grid) and assuming that the footprint has moved the smallest distance its original co-ordinates would have been X=165 Y=91 (mm) the footprint pad is now sitting on X=165.1 Y=91.44
I tried the measureing tool (after I found it and got the same result. the footprint seems to have moved by 0.1,0.44. All the footprints and tracks seem to have moved by the same amount (apart from the four mounting holes)

I dont think I’ve moved the grid because the board outline and the four holes are still in the correct places and on grid.

Likwise I dont think that I’ve accidently moved the entire layout with a select box because the mounting holes would have moved as well as its impossible not to select them and select everything else.

Here is a screengrab with the fills made transparent and the crosshair on the nearest “on grid” point to the centre of pad 1 on the pot VR201. The grid spacing is 1mm. Hopefully this will be a bit easier to see.

I haven’t tried to open this project in my earlier version pf KiCad yet but I will try that tomorrow to see if it will open. I have opened a couple of older projects in the later version with no apparent problems but I’ve not saved them in the new version and tried to re-open them yet. I will try that in the next couple of days.

Thanks once again for the help!

[Rene_Poschl]

Could it be that you positioned the footprint center on grid and are now checking the pad centers? Because having one feature of a footprint on grid does not guarantee that any of its other features is on the same grid. (Your description seems to fit that assumption.)

[nytechaudio]

Hi Rene - Nothing on the footprint (including the centre) seems to be on grid.

If I open the component in the footprint editor then pad one is on grid which is what I’m used to.

To try and make life easier I’ve made a very simple project to see what happens and its turned up some interesting observations.

To cut down on the variables I created a simple circuit of four resistors in a square.

I used one component, the “R” component from the “devices library” and added the “R_Axial_DIN0207_L6.3mm_D2.5mm_P10.16mm_Horizontal” footprint.

I then copied the symbol three times, arranged them as shown and joined the dots

Finally I renumbered the components and created a netlist - No problems so far

This is where it starts to get interesting!

Opened Pcbnew and imported netlist and immediately clicked to drop all components.

All four components are off grid!!
Nothing has been saved at this point so the save and open part of the issue I reported earlier is a red herring!

I then added the same footprint manually into the layout and its correctly on grid for pad 1.
heres a screenshot

The “extra” footprint is the one marked “Ref” above R3

The first thing I noticed is that the pin numbers for the “correct” extra footprint are larger than the ones for the components imported via netlist.

Is it possible that the netlist import is looking at a different footprint? (my V4 libraries are still intact but all moved to a completely different directory)

If I open either footprint in the footprint editor it opens correctly with pad one on grid but with the larger pad numbers.

Does this help or make things worse?

[SembazuruCDE]

@nytechaudio

Opened Pcbnew and imported netlist and immediately clicked to drop all components.

All four components are off grid!!
Nothing has been saved at this point so the save and open part of the issue I reported earlier is a red herring!

I then added the same footprint manually into the layout and its correctly on grid for pad 1.
heres a screenshot

It is expected that after importing a netlist (or updating the PCB from the schematic) that the newly imported footprints will be moved. Not knowing the code, I have no clue if there is any attempt to put new components on any sort of grid, but I wouldn’t expect it. Maybe I have different expectations than you.

Try moving R1 and R2. This should snap the centroid to the grid (for THT footprints, the centroid is probably the center of pin1). Then save and reload. If then R1 or R2 have fallen off grid and/or R3 is now on grid then you might have found a bug. Otherwise on your board you may have accidentally done something that messed with your grid and just don’t remember.

@nytechaudio

The first thing I noticed is that the pin numbers for the “correct” extra footprint are larger than the ones for the components imported via netlist.

This is because the netlist resistors have net names on all the pins. The extra footprint you loaded manually doesn’t have any nets assigned to the pins. The pin numbers are larger because there is more room for the number without the net name taking up space there.

[nytechaudio]

@SembazuruCDE

Try moving R1 and R2. This should snap the centroid to the grid (for THT footprints, the centroid is probably the center of pin1). Then save and reload. If then R1 or R2 have fallen off grid and/or R3 is now on grid then you might have found a bug. Otherwise on your board you may have accidentally done something that messed with your grid and just don’t remember.

Selecting R3 (off centre) does indeed snap to the centroid on pin 1 and repositioning snaps the footprint correctly to grid.

If I save the PCB and reload, the moved footprint remains on grid and the remaining off grid footprints remain off grid.

[roboya]

Hello!

I might have the same problem.
I’m using 5.1.4, and I’m working in metric. Yesterday, the PCB I am working on was exactly on grid, and I could for instance add vias which were exactly aligned with 0.5mm pitch chip pads.
This morning, I reopened the file, and I found out that everything is shifted by -0.05 on x axis, and -0.2 on y.

Usually the smallest grid I use is 0.25mm, so I guess this shift is not the result of a bad move, otherwise it would be a multiple of 0.25.

But there is more than that. I found out that the problem is not a shift of the routing in the grid, but a shift of the grid itself. As you can see, the cursor on the left of the green traces is exactly on the grid (which is basically the idea of the grid). The grid is 1mm, as shown on top. But the grid display shows X = 110.05, and Y=49.20.

Does anybody know how to fix this problem? I’m not sure it’s the same problem as above, but anyway it looks similar.

I thought about shifting everything by (0.05, 0.2) but in this case, the data display will still not reflect the current position.

I’m using 5.1.4 (stable version) on Windows10.

Thanks for any hint.

Pascal

[jos]

You migh have accidentally pressed S which sets the grid origin to where ever the mouse pointer happened to point at.

• Just point at a meaningful grid reference and press S.
• There is also an icon on the right hand side a bit down. Does the same.

[Sprig]

Does anyone know if this issue is known by the developers? This is or was an issue with the recent builds on both Linux and Windoze.

The affects are related to how PcbNew now assigns a new grid when moving Footprints. With me running Windoze, and my friend running Linux, and using different versions, including stable releases, the results of moving parts around was vastly different between the releases.

The biggest annoyance was that parts set on a mm/in grid would not center on the opposite grid once the grid was changed. The second annoyance was that in some versions both mm and in grids were active to place the part on, but the second grid was not shown unless using lines for grids (dots and crosses grid markings did not visually show that both grids were active).

This appears to have been fixed, whether intentionally or not, on nightly 5.1.x builds on both the OS mentioned above.

I’m using kicad-5.1-jenkins-382-x86_64 and my friend used a virtual box with Jenkins 385 (I think, I know I’m close). In both these versions the previously existing grid placement issues were fixed. As mentioned above, it was fixed as well with the Linux nightly my friend used; although I don’t remember exactly what version of the Linux distribution.

A reminder that while it may not be a good idea to use a nightly build, sometimes important things get fixed in them that remain broken in the stable builds.

A second note is that I had a board fabbed, at OSHPark, with this placement issue affecting one of my through-hole terminal screws. The good news is that this issue is only a fraction of a grid setting off and normal design tolerances allowed the terminal screws to be mounted just fine.

Terminal screws are fairly large parts. If a design is pushing the edge of really small parts with really tight board manufacture specifications, then I would recommend that the placement of those parts be double checked before sending the files out for fab.

[roboya]

Hello!

Thanks for your reply. I found about it in the meantime, but I didn’t know the ‘S’ trick Now what I don’t understand is why the coordinates XY are not set to 0. If I decide that this particular point should be my absolute reference, then it should set the coordinates to 0. So basically it’s called “set the origin point to for the grid”, but it doesn’t really do it. What would be good is a way to set my absolute topleft corner (or board center or any other specific point) to (0,0).

NB: I’m aware that with space, I can have some local coordinates. The problem is that it doesn’t alter the grid
offset. To be more accurate, what I typically want to do is this:

I’m using a metric grid, so if I leave it as is, there is no way to have equally spaced traces between 2 holes so everytime, I have to set the grid to 0.127 and centered exactly in the middle of 2 holes.
If I do that with the local coordinates (space), it doesn’t change the grid offset, as my connector is not necessarily on a 2.54 grid because my setup is metric. So what is made with the

So, what I would suggest is:

1. One way to REALLY set the global grid origin (possibly with S). From that point, the origin would remain (until changed)
2. One way to have a local grid, but this grid should also be set (possibly with space)
   Unlike the current space bar change, which keeps the grid as is, it shoudl place the local origin of the grid to the current point, and should also be able to set any specific point as the grid origin. Example: one IC is off-grid, but I want to set the local grid starting at the center of the chip.

Pascal

[jos]

Enter set grid origin mode (by S or mouse).

When the mouse pointer then gets very close to a pin/geometric shape a circle with a cross shows up indicating dead center of that item. Left click and that is your new electrical grid origin metric or otherwise.

This (0, 0) origin anywhere is work in progress for the next major release.

In the meantime the ingenious good old space bar 0,0 fills in brilliantly.

[roboya]

Hello!
Thanks for your reply.

Well, I don’t think it fits brillantly otherwise there would be no work in progress on the issue. But I agree that there are some workarounds, that allow the user to move the grid, etc…
Space allows to set a local 0 origin, but doesn’t allow to put that origin out of the grid.
I think the idea of global 0, local 0 is fine. “set the grid origin point” leads a bit to confusion, as grid and origin are 2 different matters.

And a quick way to switch between 2 grids (I would appreciate 0.125 / 0.127) would be great.

Pascal

[jos]

In Pcbnew under ‘View | Grid Properties…’ you can mess around with some quick access grid settings.
I use Alt+1/2 very frequently.

Unfortunately this setting is not exactly intuitively placed to find easily.

[Piotr]

@roboya

But I agree that there are some workarounds

I modified the page layout to not have the frame but to have the X/Y lines crossing at absolute 0,0 point and design my first KiCad PCB around 0,0.
I found that my X/Y lines from page layout disappears when I am at negative positions and zoom (or shift) to the moment that 0,0 point is out of screen. I reported it as a bug. In meantime I replaced them with two lines at Margin layer.

[nytechaudio]

I seem to have started something here! Apologies for that

I’ve been using workarounds for the last couple of months to get around the issue (which for me is interchangability of projects between different platforms) and knowing that people are working to resolve the issue are what makes “open source” projects so important

I’m just posting this to thank everyone who has contributed to the post and to the developers who are trying to fix the problem.

One of the greatest strenghts of “community” generated software is that problems are delt with rather than buried behind secrecy or ignored.

Well done to the whole community and all the developers. KiCad has made some pretty dramatic improvements to usibility over the last couple of years and has become a very powerful tool for both hobbiests and professionals and we the users must do whatever we can to support the developers as they do a great service to us all.

Thank you all!

[eelik]

What values do you see when you open View->Grid Settings? What happens to the footprint grid alignment if the values weren’t 0/0 and you reset them?