Something new I’ve noticed with KiCAD 7 (this was never a problem with KiCAD 5) - flipping a group of components/zones/traces no longer keeps them aligned to a grid. Instead of flipping about a grid point, it seems to flip about the “center of mass” of the selection, which is rarely aligned to the grid, and the end result is that the flipped selection is now no longer aligned to any grid and it’s difficult/impossible to realign it. It seems like if the selection is symmetrical about the flipping axis then it will stay on a grid, but if it’s not then all bets are off.
Is there a preference or hotkey option I’m missing to prevent this from happening? Flipping a selection about the center of mass instead of a grid point or the origin of one of the items in the selection seems very odd and previous versions of KiCAD didn’t do this.
If there is a footprint in the selection then yes, you can use its anchor point to shift the selection back onto a grid. If there isn’t a footprint in the selection (just traces/vias/zones) then that doesn’t work though.
Here’s an example project that illustrates the problem flip_test.zip (31.5 KB)
Everything is on a 10 mil grid. Select the trace connecting R101/R102, copy, paste, and flip it, then try to drop it onto R103/R104 to connect them. You can’t, because as soon as you flip the trace it jumps off grid and can’t be moved back on.
The only way I’ve found to do it is to drop the flipped selection somewhere off the board, open the properties for one of the traces/vias to see where it ended up, then copy the Y coordinate (X coordinate if your preferences are set to flip L/R instead of T/B), then highlight the selection again and use “M” to move it, then paste the current coordinate and invert it to move it to zero, THEN you can grab and move it to where it needs to be. But that’s super cumbersome.
I see your problem. In fact, I noticed it when I did some preparation work for my previous post. The problem is that the reference point changes at the moment a block attached to the cursor is flipped.
A more graphical illustration.
Select the three track segments by dragging a box from left to right:
Move the cursor to the topmost point of the track and press [Ctrl + D] to duplicate the selection. A duplicate is now attached to the cursor and moves with it:
Press f to flip it. The block selection is now mirrored, but the attachment point of the block to the cursor is not mirrored. It is still in the upper left corner of the selection:
My expectation would be that the cursor would still be attached to the same topmost point of the track. In my earlier example I avoided this situation by by flipping the selection while it is not attached to the cursor (Step 2.), and then do a move (Step 4). as a separate operation, and this move selects a new attachment point for the block. There is no need to do your complex juggling with coordinates, at the moment you do a separate move, a new attachment point is selected.
This may be worth a bug report or feature request. I am not going to do that myself because I first have to update my Linux box and test it myself in the new nightlies to verify if it still exists, and the nighties don’t run on my older Linux Mint V20.3.
Thanks for the suggestion, it does look like if you copy/paste or duplicate the selection, move it elsewhere and drop it, THEN flip it when it’s not attached to the cursor, it does keep it aligned to the grid, then you can move it again now that it’s on the other side. I never tried that before, it should work as a workaround for now.
Edit: Hm, actually maybe I spoke too soon. That did work with another test on another board, but it’s still not working for me on the example project I attached earlier. Whether or not the selection is attached to the cursor, flipping seems to move it off grid.
No, not really, but close. The block is mirrored in place during the flip, and this likely puts it off-grid. It is this next step:
… which selects a new attachment point somewhere in the block and then puts that new attachment point back on the grid again after the move.
Behavioral details like this tend to change from KiCad version to KiCad version. At the moment the block is apparently flipped in place. In an older version I think it was also mirrored along one of the mouse axis.
Ah alright, that’s where the disconnect is. I have “m” remapped to “move with reference” in my settings, so it won’t grab arbitrary points on traces or pads, it only moves from and to grid points so it’s easy to keep everything aligned. If I switch to using the default move which grabs arbitrary points near the cursor, I can convince it to grab a point on the trace to shift it back onto the grid.
