Ok, here we go talking about this again…
This is a serious problem. Or?
My apologies if the video below is all too long and/or not needed at all.
Btw, the same behaviour is also in v 6.99…
You could have left off the first minute of the video, it’s not relevant.
If you replace the footprint on the PCB with some other footprint then probably the locations of the pads change, and then the dragging while keeping the tracks connected does not work anymore. DRC does not flag it because the the pad connection is still good. (Although there is this bug: #9870 )
So neither behavior is a bug, and it certainly is not a “huge bug”, it’s also not a “chaos”, but a moderately minor inconvenience.
It looks like you’re updating some existing project from an older KiCad version. Changing footprint links one by one is not very efficient. It’s a lot quicker to generate a project specific library for those footprints, then modify the footprints in that library (while keeping the exact same pad locations) and updating the PCB with the modified versions.
I do agree this could be improved though. Either by snapping track ends to pad centers if pads move a bit during footprint updates, or by dragging the tracks along during moves when a track ends anywhere in the copper area of the pad. Another possible solution could be in PCB Editor / Tools / Cleanup Tracks and Via’s, which could for example have a function to modify tracks to go to the pad centers if a track ends in a pad.
Also, KiCad can show pads, tracks & via’s in “outline mode”, and this may make it a bit easier to fix this manually.
Thanks for your reply, paulvdh. Why I in this case do it one at a time (only one component in the video/R86) instead of the more “efficient” way is to avoid the chaos which here is mentioned (=all updated footprints losing physical connections). And yes it’s an imported Eagle project in which I want to, as much as possible, use the KiCad standard libraries – as many of these components also have the 3d parts already included. Also it doesn’t mater if the “updated” footprint has exactly the same X/Y coordinates as the one updating from, because as soon “Update Footprint from Library” is clicked, the physical connection is broken/lost – also if you just open the original footprint in the footprint editor and resave it without changing anything. I could show this in a short video but skip it now as videos are not needed here, or are always too long. This is for sure a serious bug, which might have been reported in your #9870 link. Let’s hope the developers sees this and can fix the bug soon (at least in 6.99).
because as soon “Update Footprint from Library” is clicked, the physical connection is broken/lost …
…This is for sure a serious bug, which might have been reported in your #9870 link. Let’s hope the developers sees this and can fix the bug soon (at least in 6.99).
I don’t think this is a bug - it just works different than eagle (and yes, I had to accomodate to this behaviour also at the switch from eagle–>kicad).
With eagle there was the need to connect a track directly to the connection-point of a pad to complete a connection. These restriction on the other hand allows easy track-adaptation if a pad-position/size changes (due to footprint-update/footprint-changes).
In kicad (I think from kicad-behaviour, I have no inside in the code) the tracks (especially track-ends) are not so tight coupled with the pad-positions. So with a change in pad-position it’s not that easy to also correctly change all track-ends.
This seems inline with a general kicad-philosophie with more flexibility / fewer restrictions on the design-process, which on the other hand often results in more responsibility of the user.
My thoughts about the special mentioned case (tracks losing connection from pad-center at updating footprints):
- I also like the “eagle”-behaviour (connection retained to pad-center at footprint-update) more, but I think this is because of >25years eagle-work.
- On the other hand the eagle-behaviour can also cause some work. It all depends on the special case - which footprint is replaced by which other footprint? Your example is the best case for footprint-changes, but there are many other situations possibly where it’s not so easy (from programming point of view) to implement.
- During normal work this was not that much of a problem (for me and my boards in the last year) - doing footprint-updates is only a minor part of a complete design-process.
- Admittedly for the special case of migrating existing boards from another CAD-system into kicad-format (and than also migrate the footprints to kicad-native) I understand that you miss that feature. But after the migration-phase the need for this feature will decline.
- nonetheless - if you think it’s worth the effort you should write a good feature-request, so the developers can decide on implementation.
remark: you use very often the word “bug”, but mostly it’s a missing feature or an unfamiliar workflow. If you use it to often there is a (little) danger that sometimes people
Thanks mf_ibfeew, many good points there and I will try to stop using the word bug. The feeling of this behaviour in KiCad, which gives more flexibility yes, is like pieces of lego not really attached fully together, this way we can build new lego models, which sometimes fall apart if the builder don’t use a good flexible glue. I guess the best path now in KiCad is to forget this and simply get used of it.
is like pieces of lego not really attached fully together, this way we can build new lego models, which sometimes fall apart if the builder don’t use a good flexible glue.
Yes, that was my feeling also at the first 2…3 month at eagle–>kicad transistion. And I get this feeling again if I frequently switch between kicad<–>eagle. Unlike your description we don’t migrate existing boards. So I have to work with eagle for all older projects (declining work) and with kicad for all new projects (increasing part). Especially parallel working is sometimes confusing for my brain:) (my bad).
I guess the best path now in KiCad is to forget this and simply get used of it.
Yes, for now thats the way. For the future (I think beyond v7) it may be possible to include that feature.
I don’t see a problem for just updating the footprints to KiCad native footprints. sure, the dragging footprints while keeping tracks attached does then not work but that’s not a real problem.
And if you want to fix that, I guess it’s about 10 minutes or work for you (guestimated) 100 or so resistors and capacitors.
The rounded pad corners are an advantage (mainly because then the SMT stencil also gets them) Exporting the imported eagle footprint to a kicad library, then updating them with rounded corners and updating all the footprints on the PCB with that modification is also quite easy (probably also takes 10 minutes (or less)).
[quote=“TheSwede, post:3, topic:36599”]
*"Also it doesn’t mater if the “updated” footprint has exactly the same X/Y coordinates as the one updating from, because as soon “Update Footprint from Library” is clicked, the physical connection is broken/lost – also if you just open the original footprint in the footprint editor and resave it without changing anything…"
Whatever we may call it, a “bug” or not, isn’t that a bit strange?
It’s not only the location of the footprint that must be the same, but also the locations of the individual pads in the footprints. From what I can see in your video, the (centers of the) pads in the eagle footprint are slightly further apart then the pads in KiCad’s footprints.
Can you make a small test project with a handful of those eagle resistors, zip it and upload it here?
The I can have a look at it.
Thanks for your time and help in this! I just made a small new project in Eagle (3 capacitors + 3 resistors) and imported it to KiCad – this time the “library updates” works just logical and good, so I must have messed something up with the other/bigger Eagle imported project(s), so never mind with this what I called a bug, it’s obviously not.
Well, a small project may not be as a valid test. Probably importing another format will probably always run into a few glitches. It may, or may not depending on the project, be better than having to start over from scratch.
This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.