Hello, as the title says, copy-pasting schematic blocks between 2 different instances of KiCad (not just 2 schematic sheets of the same instance, which works fine) results in some symbols getting placed off-grid in the pasted block, even though the grid is the same between the two instances.
It happens when pasting into a schematic sheet in KiCad v7, from either a v6 or v7, different instance.
To what do you have Preferences > Preferences > Schematic Editor > Display Options > Snap to Grid set?
There are three choices, best to normally keep that set to “always” in the Schematic Editor and hold the “CTRL” key down when you wish to move something Off Grid with your mouse.
To get the offending block back on grid, highlight that block, right mouse click for “Selection”, then choose “Align Elements to Grid”.
I have it set to “Always”.
Yes, I use “Align Elements to Grid” when this happens.
It does happen quite frequently though, so I’m just pointing out the possibility of a bug.
Oddly, when this happens, not all symbols in the pasted block are affected - only some of them end up off-grid.
If anyone has encountered the same / or can reproduce it, great.
For more context if that matters:
I haven’t struck that problem … yet.
There also doesn’t seem to be any reports on Gitlab.
Application: KiCad Schematic Editor x86_64 on x86_64
Version: 7.0.7-7.0.7~ubuntu22.04.1, release build
Libraries:
wxWidgets 3.2.1
FreeType 2.11.1
HarfBuzz 6.0.0
FontConfig 2.13.1
libcurl/7.81.0 OpenSSL/3.0.2 zlib/1.2.11 brotli/1.0.9 zstd/1.4.8 libidn2/2.3.2 libpsl/0.21.0 (+libidn2/2.3.2) libssh/0.9.6/openssl/zlib nghttp2/1.43.0 librtmp/2.3 OpenLDAP/2.5.16
Platform: Linux Mint 21.1, 64 bit, Little endian, wxGTK, cinnamon, x11
Build Info:
Date: Aug 13 2023 23:14:49
wxWidgets: 3.2.1 (wchar_t,wx containers) GTK+ 3.24
Boost: 1.74.0
OCC: 7.5.2
Curl: 7.88.1
ngspice: 38
Compiler: GCC 11.4.0 with C++ ABI 1016
Build settings:
KICAD_SPICE=ON
About half year ago I have reported something like that. When I had one symbol (terminal block) in grid and texts (describing terminal block pins functions) off grid and selected that all then when I tried to move that block, it was caught (linked to cursor) by a point being off grid and I could place that block only with that point in grid so terminal block symbol landed off grid. There were no way to catch that block for point in grid. At the same time I had no such problems if I selected bigger part of schematic - I could move it not loosing grid.
I spent some time trying to create this fault, but to no avail.
I did notice that the cursor grabs the anchor of the left most symbol for pasting, so I deliberately placed that symbol off grid before copying.
The result was that symbol was still off grid, but the others in the selection were still on grid when pasted. 
I am having a lot of “off grid” problems lately but I have not been able to pinpoint the cause. I will look into if it may be caused by copy/paste.
One reason for encountering more grid problems is simply because ERC nags about it, while it did not do that previously. (And when ERC nags about it, it does not mean there is even a (real) problem)
Another reason is that the KLC recommends a 100mil grid, while the pins on common parts such as resistors and capacitors have a 150mill offset from the symbol center, and they will be off-grid immediately when they are freshly inserted on a schematic with a 100mil grid. Recently I tried working with a 100mil grid, but it is a big nuisance because of those commonly used resistors and capacitors (fuses, inductors, etc). Using the schematic editor on a 50mil grid works a lot better.
It seems quite unlikely to me that when a block is copied from one schematic to another, the block itself changes shape. And because of the above, could it be that a part of the block was already off-grid before the copy / paste operation started?
There also is a setting: Schematic Editor / Preferences / Preferences / Common / Editing / Warp mouse to origin of moved object. When that checkbox is on, and KiCad chooses the origin of a resistor as it’s anchor point for the block insert, then the pins of that resistor, and (likely) everything with it will be at a 150mil distance from the attachment point, and off grid when the grid is 100mil. (But still on grid for a 10mil grid)
By “off grid” problems I do not mean just ERC nagging about it, but the fact that I move something or add something and it sometimes does not fit to existing symbols.
When this happen I usually select the whole schematic, realign it to grid and check the whole schematic if it break something. And some time in the future I need to realign it again. But I do import symbols and footprints from various sources, I do copy/paste between projects a lot, etc… so I am not sure why that happen…
What grid are you using in the schematic?
The behavior you describe is common when you attempt to work on a 100mil grid, but should not happen when you work on a 50mil grid (due to those resistor and capacitor symbols mentioned earlier).
That is indeed another nuisance. When things get aligned to the grid, it is possible short circuits are being created when endpoints of wires are on other wires, or attachment points of pins are on wires. It’s one of those things you would have expected to be solved years ago. So apparently it’s not so easy to fix. There is some (a lot probably) of refactoring going on in the fundamental way the schematic editor works, and I guess that has to be done first before this can be fixed once and for all.
I do copy/paste between projects a lot …
Be careful with the CTRL-key during pasting.
The CTRL-key acts as “don’t snap to grid” modifier key. If you don’t release that key fast enough (from the usual CTRL+V paste hotkey, and prior to the LMB-click which commit the pasted content) then the grid-snapping is of and the pasted content is placed offgrid.
Thanks for the advice, I will watch for it, I did not know about the ctrl function as I prefer to have everything on grid.
I try to use 100mil, but as this happen I always wonder whether I changed the grid somehow by mistake - i.e. by some shortcut I do not realize, or something like that. However the mismatch is usually less that 50 mils…
And yeah, the re-check of the schematic is pain-in-the-behind but I understand that this could lead to big problems if I did not catch it…
if it’s less then 50mil then the [Ctrl] key thing as mf_ibfeew mentioned is a much more likely culprit. As soon as you release the [Ctrl] key and move the mouse again after that, the block snaps onto the grid again, so you have to do those two things before comming to the final location with the [LMB] (= Left Mouse Button).
The grid is also silently changed if you press ‘n’ just like in the pcb editor (‘n’ to reduce, ‘shift-n’ to increase), I try to remove this shorcut from the shorcut list, to avoid having this random incidents.
Not talking about ERC here either, but copied symbols/graphics that end up off grid and that were not originally, with the same grid. That’s not something I had noticed in v6, although I may have missed it.
The grid I use is 1.27mm.
One thing that came to mind: now wondering whether this issue is potentially triggered when the copied block contains symbols that themselves contain graphical elements that are off-grid (but not their pins). Something that would warrant being investigated to understand the issue.
When creating symbols, I always use 1.27mm as the default grid, and all pins are always on this grid. But sometimes, I add small graphical elements that are off-grid. Could it trigger the above behavior? Someone talked about the anchor point - I’ve always assumed it was at the origin of the symbol in the symbol editor, am I wrong? If the anchor point was off-grid, I would have issues everytime I add a symbol on schematics though? So probably not that at all.
Lastly, I had missed [mf_ibfeew]'s post above, and just read it. It’s very possible that this is the culprit, as I always use CTRL-C/CTRL-V to copy-paste. This CTRL key modifier sounds like a bad idea. Can it be disabled? I haven’t seen any corresponding option in the Preferences! Might very well be my problem here.
Are your wires always on grid?
I’ve found the cursor attaches itself to one of two positions on the left of a group of symbols.
If the anchor of a symbol with no attached LH pin is furthermost to the left, the cursor will attach to that. (Magenta arrow shows anchor position).
When a wire is connected to a symbol pin, and this is furthermost to the left, the cursor attaches to this.
(Cyan arrow)
In the above screen grab, the cursor attached to the cyan arrow position. Had R19 been further to the left, the cursor would have attached to the R19 anchor.
Do the graphic elements have their own anchors?
If so, it is possible the cursor attaches to an off grid graphic element anchor rather than the symbol anchor if that element is to the left of the symbol anchor.
The anchor position is wherever you placed it. If you have no issues, the anchor has been placed on a pin or somewhere in such a way that the pins all remain on grid.
Correct.
No.
I was not really aware of all the “subtleties” regarding the anchors. The more I read about it, and the more confusing it sounds.
As to the CTRL key, IMO it definitely should be either handled differently or we should be able to disable the behavior. The fact that it could trigger an off-grid placement when we are hitting CTRL-V to paste something is a problem.
(Edit: I suppose that the off-grid placement when holding CTRL stops being active when the key is released? In which case, that shouldn’t be a problem for me as I always release it when pasting blocks before starting to place the pasted block with the mouse. But in case the off-grid relax would remain enabled while we are moving the block around and even after the CTRL key has been released, then it would certainly be a problem.)
This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.
