CvPCB has nothing to do with BOM generation. It lets a user match a generic symbol with a generic footprint. More information is required for a BOM, and the experienced user wants that information (a part number) in the symbol, and s/he wants that symbol to also include a footprint.
Which is why the concept of atomic parts exists.
Also, CvPCB still exists for those users who prefer that workflow.
With vias it works in opengl: when clicking on a track, only the clicked segment is selected. Then if remove is selected, the segment is deleted up to the via.
Both in 4.0.7 and nightly 2017-09-25 ubuntu.
OK. A segment is a straiht part of a track from two ends. These ends can be a via, a pad or any point where the track makes an angle. In legacy it is also possible to break a straight segment into 2 segments.
While reading the netlist, as I showed you in the picture, there is an option to “delete or keep unconnected tracks”. Both 4.0.7 and nightly 20170925 ubuntu.
In 2013 and 2004 versions was called “bad tracks deletion”
I’m not a fan of assigning a footprint to a symbol on the library level. In my opinion ability to have multiple footprints per symbol is one of KiCad strengths. Assigning footprints can be implemented better but the concept is still the right one. Library management in KiCad is really awkward to begin with, I don’t need to have a hundred “parts” for a single resistor, just to accommodate all variations of all avaiable footprints.
I wasn’t talking about selecting and deleting a single segment. That’s not a problem, just click on a segment and delete it. I was talking about deleting a portion of a track between two pads or a pad and a via. For two pads “Trivial connection” option does work sometimes. But it will ignore vias and will select everything on all the layers up to the next pad.
It is possible in OpenGL as well.
I guess that’s another pet peeve - different functionality on different platforms. There is no option like that in Windows
[quote=“ArtG, post:41, topic:8874”]
I’m not a fan of assigning a footprint to a symbol on the library level.[/quote]
And that’s fine, if that works for your business organization.
Kicad’s flexibility to allow for disparate workflows is one of its strengths.
Accommodating all of those variations is a problem that exists in other PCB CAD programs, too, and how it is solved really depends on the user/organization’s needs. The one-man shop has a different set of requirements from an organization which has a full up ERP system. Kicad supports both.
Not at all, it’s just not easy to list them. I’d like to give a more general, bird’s-eye view. What actually makes day-to-day work slower, even if one learns to live with it or doesn’t even notice it. Many smaller and bigger things are already mentioned here and some are well-known in the community, some are actively going to be fixed by developers. Here are some things:
Footprint editor should be something like which was mentioned and linked here, using parameters and distances. Now it’s simple and intuitive, but putting pads into their places requires manual calculation or/and moving the mouse to a right pixel. With a good wysiwyg interface it could take e.g. 5 minutes instead of 30.
Symbol editor should have an editable list of pins or something like that for creating and editing pins. Now it’s simple and easy to learn but really tedious.
The interactive router should work better in many ways. There’s much potential there but I just find myself deleting the tracks (often segment by segment) and redrawing them because they are not what I want, even though I spent already too much time drawing them the first time. The problem is mostly that automatic cleanup doesn’t work and it often creates a mess when the new track segment isn’t good and I try to redo or drag it. There exists something like global cleanup but it should just work on-the-fly.
(On the other hand I can’t imagine how anyone could have done it without the interactive router in the first place!)
The interactive router really, really needs dragging for footprints. Sometimes the interactive router becomes almost useless because I need to move a footprint and redo all the tracks. (Well, of course I still use it for doing the tracks, but you understand what I mean…) The non-interactive legacy canvas dragging is of no use.
Of these, numbers 3 and 4 are the ones which cost most time in day-to-day work.
Then, as a programmer, I like to think what could be done to make it better. There I’ve got some pet peeves, too:
The code base is difficult to learn. That’s not specific to KiCad, though. It’s always difficult to dive into existing code.
The coding conventions are horrible. (Using UPPER_CASE for almost anything… Sigh.)
I don’t like wxWidgets. Well, I haven’t even used it, but I still don’t like it. Nowadays there would be no reason to not use one widget library which is directly implemented on all platforms (GTK, Qt). I actually don’t like the idea of “native look&feel”.
I was aware of mathematical expression input and it’s great, but in the larger picture it’s just a small detail which doesn’t move us a long way towards what I want (see e.g. the link in ArtG’s post Kicad pet peeves).
Edit: It would need wysiwyg dimensions, rulers or anchor lines.
Edit2: mathematical expression evaluation already works in daily builds.
Oh yes there is, but I, too, like also to share what’s not so great in my opinion. I like KiCad very much and would like to make it better. Actually I have thought about what it would take to implement something for the footprint editor. But alas, my pet peeves about the KiCad code and other things have kept me back. The most important thing is, of course, the difficulty of learning a new code base and also a new widget library and other technologies (OpenGL, maybe?).
In it Wayne said he is not really prepared to switch to something different then wx if there is no good reason for it. (Basically every framework has its problems and it is hard to predict if any other thing like Qt really is better on all platforms.)
I would disagree in part here. For a given component I very much want to have all the information pre-defined, so a 10k 0805 1% resistor could be called up as same, or a 74-series TTL package explicitly as the SOIC or TSSOP variety. I’m looking at it from the error potential - if it’s all there, ideally checked from the first time a part was used, you’re not going to introduce a typo by re-using exactly what was installed and verified to be correct. Any time I have to go in and edit a field I’m introducing scope for error. If I’m patching in to a database of manufacturer/vendor part numbers then it is very important that the footprint is defined up-front because otherwise I have to go edit two fields or end up with a part that won’t fit.
You could certainly save space by having a symbol library and a footprint library that were distinct from the part library, so all your different resistors in the part library could call up a common resistor symbol and an appropriate PCB footprint and only need one copy of each instead of one each per resistor. However, KiCAD doesn’t do that at the moment. (Which I guess is one of my pet peeves, to refer back to the opening topic.)
Very true, and it’s always a matter of taste to some degree. There are also some good, useful conventions in KiCad, like using “a” for function arguments.
Usually people learn to prefer something which they use, and that happened to me with Qt. The link given by @Rene_Poschl was good reading. I don’t expect KiCad to change in that respect; I just don’t like wxWidgets. Maybe I learn to appreciate it with time, I already started to learn it with python.
Which introduces yet another problem in KiCad - the state of python scripting support (other than the lack of a plugin manager). (Sorry, ArtG, but I don’t limit my pet peeves to the end user problems). Despite of documentation, examples etc. I have found it difficult to find reallly good, working information about scripting. About every example and script I have tried has had some problems. The state of the scripting support seems to be not so good. I hope this will get better after 5.0.0. But this would be a topic for another discussion and not so much for end users.