Someone I was working with changed the grid size in Eschema for some of the projects I work on. So the symbols are not “on the grid”.
Yes, I know I can change the grid size, and try again. But then I’m stuck working up close to match the components perfectly to one another or they don’t connect.
Sure, i can try my best to get them “on the grid” and then change the grid size back up. But this has proven to be quite difficult because just one pixel off and it’s not on the grid. This results in the possibility of never being able to connect the components together.
There must be some way for me to fix this? Any advice? I’ve seen some discussion about going into the text files. Any advice on that? Are there any python scripts i can run to “Snap All to Current Grid Size”. Honestly, I would be fine if it breaks the entire schematic. I’ll go around fixing all the components to make sure they are connected. But having to take the time to zoom in and perfectly align them is frustratingly annoying.
KiCad currently has no automated way to snap to grid. Knowing this limitation is one of the reasons why i never ever switch to any grid different to 50mil while in eeschema.
And i hope we do not need this feature in the future as i really prefer snap to pins instead of a hotfix feature that allows putting stuff back onto the grid.
There is no easy way. I have put back to 50 grid some symbols many times, but they were at a 25 grid, so not easy but not hard.
Another approach is editing the .sch file and changing the coordinates of all components.
I don’t know if your schematic has a big number of components though.
The lines to be modified begin for F0 for the symbol itself
F 0 “U1” H 5650 2500 50 0000 C CNN
Here, x=5650 y=2500
The other fields, like names, reference are Fx.
Good luck!
Don’t you ever move text using finer grids? I find 50 grid too coarse for positioning text. Of course changing grid size opens up the possibility of mistakes, so I just now tested Eeschema with the nightly build which is installed on my Win10 computer.
I purposefully used 2 mil grid to place a symbol off of 50 mil grid. Then changed the grid back to 50 and when I moved it, it immediately snapped to grid. I do not remember whether the stable release version worked this easily, but this was quite easy. I guess you may need to move or drag the symbols back to grid individually.
Version 5.99.0-1137-gcc47062b1
Application: KiCad
Version: (5.99.0-1137-gcc47062b1), release build
Libraries:
wxWidgets 3.0.4
libcurl/7.66.0 OpenSSL/1.1.1d (Schannel) zlib/1.2.11 brotli/1.0.7 libidn2/2.2.0 libpsl/0.21.0 (+libidn2/2.1.1) nghttp2/1.39.2
Platform: Windows 8 (build 9200), 64-bit edition, 64 bit, Little endian, wxMSW
Build Info:
Build date: Mar 23 2020 21:57:36
wxWidgets: 3.0.4 (wchar_t,wx containers,compatible with 2.8)
Boost: 1.71.0
OpenCASCADE Community Edition: 6.9.1
Curl: 7.66.0
Compiler: GCC 9.2.0 with C++ ABI 1013
I can not remember ever needing a different grid to 50 mil in a schematic. One of the reasons might be that i design highly hierarchical which means my sheets are quite empty.
I acknowledge that the current situation is in no way ideal. Especially as the hotkey “n” changes the grid and is easily used on accident.
Tested it in v5.1.5 and yes this is how it behaves here as well.
Full Version: 5.1.5-1.fc30
Application: Eeschema
Version: 5.1.5-1.fc30, release build
Libraries:
wxWidgets 3.0.4
libcurl/7.65.3 OpenSSL/1.1.1d-fips zlib/1.2.11 brotli/1.0.7 libidn2/2.3.0 libpsl/0.20.2 (+libidn2/2.0.5) libssh/0.9.3/openssl/zlib nghttp2/1.40.0
Platform: Linux 5.5.10-100.fc30.x86_64 x86_64, 64 bit, Little endian, wxGTK
Build Info:
wxWidgets: 3.0.4 (wchar_t,wx containers,compatible with 2.8) GTK+ 3.24
Boost: 1.69.0
OpenCASCADE Technology: 7.4.0
Curl: 7.65.3
Compiler: GCC 9.2.1 with C++ ABI 1013
That’s actually funny one.
At first, was surprised you say it snaps to the grid once switched to more coarse grid, my experience was different (Pre-5.1.6).
Well. If I MOVE a symbol (m), it snaps to more coarse grid.
However if I DRAG a symbol (g) it follows my current grid step, but snaps off-grid.
Both should behave identically IMO.
I am not sure here. Drag leaves stuff attached so one could argue that this tool would be used to modify stuff that is off grid on purpose. (If drag snaps to grid then you might get a result where all wires are on a strange angle -> the only solution is then to break the wire so move might be the better option to begin with)
This information was VERY helpful. The only way i was moving symbols around was to highlight and then drag. This was my workflow.
The key is to instead hover over a symbol and hit “M” for move. You can go around hitting M on all symbols and it will “snap” the hovered item onto the current grid.
Then the only challenge at that point is that this doesn’t work on the wires or blocks. So I’m going around deleting the wires and redrawing them after snapping the symbols to the grid using the above method. Then when I drag a block, I must be sure that the grid size is set to the correct size (50 mils seems right). And the block will stay on the grid.
My only wish here is to somehow snap a block to the grid. Maybe in the context menu on right click after highlighting a block, choose “snap to closest grid” or something. It might create a mess, but then I wouldn’t need to redraw the wires, assuming the hotfix worked for wires. Or maybe wires can have a “snap wires to grid” option. Just spit balling. I figured it out at least with your help. Thank you all!
OR. A feature that would automatically snap wires to the closest pad within 50% of whatever grid size you are on. Then you can simply get it “close enough” and it will snap to it.
As mentioned, it is too easy to change the grid size. It would be prudent in eeschema to have a popup warn of the risks and complexity of fixing the problem.
Or just make it more difficult to change the grid.
