This time it’s library edits. A bug or an explained background to this?
normal behaviour (currently).
While it seems the program could easily automatically match the connection on your example it’s harder to program a generic algorithm which can foresee all changes a user can do to a symbol.
To compare it (again) with your last cad-tool: Eagle retains the connection-graph based on changed/unchanged pinnames and/or pin-position. But all wires/nets get mostly redrawn with sloping angle and so they also need rework (if you want a visually appealing result) after a symbol-update. So also this update-strategy needs comparable cleanup-work after symbol-update.
I also think that updating a changed/modified symbol is not that often - after initially creating a good symbol (which involves some iterations with symbol-drawing → saving → update symbol → good/bad-decision → next iteration-cycle → ) the symbol will seldom be modified. For instance at my change eagle–>kicad I didn’t missed this particular functionality. (in fact I noticed the difference only now at reading your post).
Nevertheless this could be worth a feature-request on gitlab. And than lets see if someone takes on the task. Another option would be to wait for the schematic-python-API and implement this experimentally with a python-script (to see how it performs in real world usage).
mf_ibfeew, thanks for your detailed explanation. Now when I know about this library behaviour I will try to be more careful (and frightened)…
Updating a library should never trigger an automatic change in the schematic. KiCad V5 and older versions did that, and it was horrible. It can easily result in multiple broken schematics if some library maintenance is done.
@paulvdh : I think that’s a misunderstanding.
Update a symbol on request is ok (and good).
It’s about updating an already connected symbol in the schematic. If the modified symbol has the pins on different places (coordinates) the connections to the already drawed wires get lost (timestamp 0:37 of video).
I agree with @TheSwede that there is potential for errors, especially if the user bulk-updates symbols and updates also occur on currently not displayed schematic sheets. The connction-loss of previously connected wires may occur in the background, unseen from the user and so it’s possible to overlook such a change in the schematic.
Agreed. This should under no circumstances be possible. As you say, imagine a bulk update over plenty of pages, could easy get into a nightmare.
I haven’t experimented with this yet myself, but wouldn’t running an ERC after updating flag any newly unconnected pins? I can see this possibly causing undetectable errors if you decided (for example on an IC like a µP) to change the pin numbers to better group the pins for schematic logic without actually moving any pins.
But until KiCad has some sort of autoroute or air wires for schematics, I don’t see how KiCad can handle this. And since in KiCad the placement of the wires is what actually defines the connection net, I’m not sure if the underlying code can actually handle something like this without major reworking.
Yeah the ERC will catch these kind of issues pretty easily, I had the problem after library updates multiple times in the past especially when we started matching our library against the KLC. It should be anyway be part of a good process to run the ERC/DRC after one modified the symbols/footprints to catch any potential issues.
ERC catches symbol-updates
The ERC is able to catch all mistakes with moved (and lost connection pins).
But only if the ERC-check for “Pin not connected” is enabled. (this check is disabled on my current workflow - too man false-alarms).
The ERC doesn’t catches if pin-positions get exchanged - these update-cases are undetected at the moment (uC-pins-interchanged, Tx/Rx-pairs swapped,l A/C from diodes changed - see @SembazuruCDE ).
My current workaround against “silent update changes”: trying to not bulk-update at all. This self-limitation is not that hard, once the library-system gets fairly stable the update of all symbols on schematics gets rare.
But until KiCad has some sort of autoroute or air wires for schematics, I don’t see how KiCad can handle this. And since in KiCad the placement of the wires is what actually defines the connection net, I’m not sure if the underlying code can actually handle something like this without major reworking.
I second this. Additionally I had no good idea/description how to implement the check. And the little impact (for my adapted workflow). Otherwise I had already written a gitlab issue.
After some thinking a copy (or taking the ideas) from the eagle-behaviour may work - if someone writes a description of this procedure/behaviour in detail.
Maybe it would be enough to write a warning-line in the output-message-part of the update-dialog? The current output-string “symbol updated” is not really useful.
You can catch errors that are caused by modifications of schematic symbols if the PCB is already designed. In that case Schematic Editor / Tools / Update PCB from Schematic [F8] and a DRC check will list the violations.
At the moment there is no such thing as a separate netlist in the Schematic Editor. The only thing that generates the netlist are the coordinates of the attachment pins of the schematic symbols, and the coordinates of the endpoints of wires and junction dots.
It would be nice to have a real netlist feature in the Schematic Editor. Especially for reverse-engineering.
KiCad could be a great reverse-engineering tool if it was first possible to synchronize some photographs as a “background image” with the PCB for reference, and then port the netlist to the Schematic editor and show ratsnest wires in the schematic. Again, just to be clear: This is currently not implemented, and I’m also not aware of plans to implement this.
This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.