Thanks for putting that in the bug tracker!
I use highlighting a bit, but if I go into the legacy tool, I can see the ratsnest for a component that I select for movement. It’s not persistent, but I can get a good look at where I’m going. After checking again, this has nothing to do with local ratsnest, it’s just how movement works with the legacy tool, but it’s the right way to implement movement. Seems like moving this feature over to GAL would be reasonable.
EDIT: When trying to post the bug, I saw that this feature was brought to the nightly build just today.
Complex ratsnest handling is also a known wishlist bug. https://bugs.launchpad.net/kicad/+bug/593962 (currently it is tagged for version 6.)
To do pin swapping with automatic schematic update is a tall order for sure, but just letting us change the netlist that we ourselves have to square up with the schematic might save time in the back and forth process.
You can do that already. Open the pin properties of any pad. There is an editable text entry field for the net it is connected to.
I like the idea of netclass colors that is described in a different bug tracker (https://bugs.launchpad.net/kicad/+bug/1530637). I suppose when it is implemented, coloring the pads and the ratsnest together would be handy, but I’d rather keep the coloring on even when the ratsnest is off. The netclass coloring code has already been written.
I added this to the bug tracker if you want to chime in (please).
For ending routing at via connection to plane, I added this bug wihch has already been implemented:
For netclass override:
It depends which part you talk about, and how far you want to go…
Letting users Swap Pin connection, inside PCB, needs no database changes at all. It’s a simple automate of what can now be done tediously. Perfect for what computers are built for…
That’s low hanging fruit.
Full automatic Schematic Pin Swap/back annotate is trickier.
However, there a form of PCB’s DRC that tags in the SCH, with arrows like in PCB clearance errors, would need no database changes.
It just needs a Read/Compare netlist operation.
SCH PinSwap / UnitSwap are not intensive use items, so tools to allow users to easily confirm they have PCB-As-Master sync-up, may be good enough.
You can do a Dry Run NET import into PCB side, to get useful reports.
Kicad relies on the fact that the schematic and pcb files are always in sync. So if you do not include back propagation of the pin swapping you will get an invalid design that breaks as soon as the user re imports any changes from the schematic. (In other words i doubt the devs will implement it that way.)
Other CAD tools do not have ‘live’ pin swap, they have a back-annotate step. It is hard to fully automate back pin swap, and those that swap pins inside a symbol sacrifice a little clarity.
Pin swap allows a difference, and it improves the PCB design and flow.
The issue is less with ‘out of sync’, rather in making it easy for the user to confirm they are in sync.
A subtle but important difference.
This is what i meant with “The kicad internal datastructure needs a rewrite for this to work”
I do this with microcontrollers all the time. Pin swapping of I/O pins is extremely common to simplify a layout. If you drive say an HD44780 display controller you generally want four bits in the same port (though not necessarily grouped as bits N to N+3, since a 16 entry map is trivial), but the control signals are easily put on any available I/O pin. Or made-available I/O pin by shuffling things around a bit. (This is why I personally always recommend maintaining a pin plan as a separate design document.) So, yeah, it’s common and it’s also rather tedious in KiCAD… Not a big deal, but a pin swap feature would be very nice indeed. 
What you are talking about there is called “changing the schematic”. How would that work? If you tell pcbnew a trace can got to any IO pin, ERC becomes useless. If you connect to the wrong pin, pcbnew will happily do that and you will not notice. It would be a nightmare!
If you want to use a different pin for IO, change the schematic, then re-import the netlist. A reverse workflow is just unworkable and will likely never happen.
Err, sweeping claims - Have you ever used a CAD pgm that does pin swap ?
It is already out there, in the wild, and yes, it works just fine.
You can even do it right now in pcbnew, just very tediously.
If someone prefers to work-forward they can, but do not block user choice when computers can do this stuff easily.
As feature were frozen some time ago to allow doccumentation wrters to write doccumentation with defined software I wonder if this Shift-click will be doccumented.
Just discovered Pin-Swap is possible now
Select 2 pads using Shift-Clk, then activate PinSwap icon, and voila… Brilliant !
Thanks for that tip!
As this discussion really got me fired up I approached the swap pins and swap units issue and I am releasing it as two action plugins (Swap units action plugin, Swap pins action plugin)
While the implementation is crude and some might call it hacky, it’s what I think is doable with current facilities that KiCad offers.
2 Likes
Well, just like when you do it manually…
- You decide to use P2.11 to drive C#/D instead of P1.2. Delete traces used to connect these two pins.
- Go to the schematic. Edit the library part (cmd-e on OSX)
- Swap the two pins on the component
- Relabel the pins so P2.11 is now called C#/D and P1.2 is called P1.2 to indicate it’s an available I/O pin
- Save the library part
- In eeschema, refresh the schematic (if needed) to verify the pins got swapped
- In eeschema, update PCB from schematic (F8)
- In pcbnew add new traces for the two swapped pins.
I mean, you could probably write a script to do this. In pcbnew, delete traces that are about to be obsoleted; select two pins. Swap. Add new traces.
No problems with ERC/DRC.
1 Like
This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.