The problem is not software modification it is I just don’t see the point.
And that is the root of why you get so many comments , and why people are bitching and moaning.
You implement things the way you see them. And that is fine, it is your software after all, you control it.
The problem is you don't have a solid grasp on the entire problem or the entire design cycle. The implementation you make is based on your perception.
change is good and welcome , but only if it fixes a problem, not if it creates 20 new problems.
What I’ve been considering is a relational database containing tables of parametric part parameters.
in itself not a new idea. That is how component libraries have been made for decades now. Your new idea is the parametric portion. That could be a good idea , provided there is a mechanism to override the parametric portion and apply customisation. There are simply too many footprints out there. You can parametrize something like an SO package : 2 rows two colums, specify pad size and pitch and done. But, even with such a simple item : i want pin 1 to have a different shape than the rest so my pick and place vision system can detect it and use it as local origin. ( removing the need for a local corner fiducial ). So now we have another parameter in the 'pool'. I may want to shrink paste, or remove soldermask because i am using thick copper on my board and the fab cannot print the soldermask. So now we have another parameter.
The problem in board design is that there are more exceptions than 'norm'. and that makes parametrized parts very difficult. You can use them as the base ( that is what the wizards do) but you can not take away the ability to fully customize them. You , as the software designer, have no idea what the user may need to tweak in the part. you do not know his assembly or production process. there are simply too many variables. So you can automate only to a certain point. They may have a super secret manufacturing technique that they are absolutely not sharing with the rest of the world. you can not know, and you can not make assumptions. The software can not limit because of what the software designers thinks is not necessary. It can of course limit because the software designers may not know how to do something or have not implemented it yet. But there can not be an 'apple' stance where they go : you don't need that. That is not up to them to decide.
All PCB cad software these days has a large set of common functionality. That is the starting point.
Differentiation between tools lies elswhere
DEX is capable of automatically creating schematic symbols,
I doubt that heavily. If i feed a part number to DEX : how does it know if this is an opamp or a timer ?
Your idea of a IC symbol is a rectangle with pins. That is a very narrow view. I may want to split the device in mulitple parts so i can put one section on page 1 and another section on page 7.
section one is drawn as a circle with a cross in it (could be an analog multiplier) while section two is a triangle (opamp). so this 'auto generation does not work , unless all you create is 'blobs'. That is not how schematics are drawn. A schematic needs to be readable. Drawing everything as simple rectangles
doesn't work.
In your perception symbols are generated 'automatically' because all you need is a rectangle.
That is not what the rest of the world works. If all we needed were rectangles we would have stopped drawing capacitor symbols and diode symbols long ago. Why go through all the trouble ? simply draw everything as a rectangle. it's less work. But there are reasons why we have all kinds of symbols, even if that means a bit extra work.
Let's take a large step back and look at something else first.
Historically drawing CAD software began by allowing you to draw some lines and dots and send those to a plotter. the computer software was a replacement for decon-dalo rub-on pads and masking tape. it saved work.
Then we started building libraries with often used symbols and footprints to save time.
Over time other data was introduced : the link between symbol and footprint. procurement data, variants, alternates , stuffing options, spice models, 3d models, s parameters, IBIS models, thermal models.
Today we live in a data-driven design world.
We are now at the point where all information relating to a design , down to procurement data, is stored in a database. the symbols and footprints themselves are just one more property.
we have evolved from the concept of having a symbol and a footprint and "we'll fill in the blanks later" to a model of
here is a part
- this is the footprint
- this is the symbol
-thsi is the spice model
- this is 3d model
- this is who makes it and the part number
- this is where we buy it.
We have gone beyond that to the point where some of this information meshes with other databases , for example live data from our vendors. our database holds the order code, so our database should be able to launch a query to our vendors database for the current price, in different quantities. Ideally our database or the vendors database has crossreferencing so it may suggest a cheaper alternative.
so now we deal with meshing databases with non-static data. everything is 'live'.
if a root element gets updated ( could be the price, could be the silkscreen on a footprint ) this propagates realtime to new designs and can be backported to existing, on-going or old designs.
There should be no duplication of data in the 'master database'. That is why everything is relational in there.
In the design we are faced with the problem that we cannot deal with data that can alter at a whim. So we use a cached copy. a snapshot in time from the master database. This allows us to do the work. Before we send it out for production we do a compare against the master databases and fix or reject discrepancies. ( we may reject a vendor change for a part because we still have 20 reels of the old one and we will use those up first and then we will change). we may reject a footprint because our board has a special feature that requires a tweak on this instance.
That is why the data pertaining to the design is stored in the design. It is pulled from a master database and can be verified and update if we desire so. It can also be locally overridden and left.
We are now at a point in time where there is a clash between design and manufacturing. The 'old skool' way of doing things by exchanging odb and gerber no longer are sufficient. There is not enough info in those formats. if the production house finds a problem they flag it we need to change it and send data back. we need a mechanism where they suggest the change and we can click 'accept' and our database gets fixed. This de-duplicates work and maintains the integrity of the data . It is all about collaboration.
That is why now IPC has made a new data exchange standard (2581) that holds the entire design in a vendor neutral format. I can save my entire project as IPC2581 from cad program x and cad program Y can read in this design and reproduce it completely and correctly.
So now if the fab house needs to do a tweak : they alter the data and send back the design. i can compare revisions and accept or reject changes.
Just like in a word document you can put tags and revision and edit information this can now be done in the electronics design world. I can read someones document, propose changes and the other guy can approve or reject. I have access to the root data.
Of course this brings in new problems. Having access to the every aspect of the design means it could 'walk off' to the competition very easily. that is why 2581 has provisions to mask off data. i can block the schematic or where i buy my parts , or my price. At that point a subset is created which is task specific. But, i can re-import that subset, and changes, back into my master design file so it still saves me a lot of work.
Designing a lump of electronics is no longer divided into a schematic, a pcb, a collection of parts, a procurement database, an alternate part , a collection of papers and post it notes and 'only Kathy knows where to find that piece of information'
The design itself is stored as an entry linking to live or cached data and there are multiple ways in and out of this database, each with their own checkpoints.
Some of that stuff can be automated ( like meshing between my database and a vendors database to get live price and stock info). some of it can't as it falls in the 'exceptions' category ( customized symbols, customized footprints )
We are evolving even beyond this point. Component manufacturers already give us accurate 3D models so we can make sure stuff will fit. In a lot of instances manufacturers also begin by giving us the actual footprints and symbols. This can be in a vendor specific format ( today) but is moving fast to a vendor neutral format that any cad program will be able to read (2581 is the ideal candidate there)
Pick part from a website and the symbol and footprint appear automatically. These are vendor verified. any error is immediately corrected so the trust in this data is very high.
This is not 'future music'. It is here today. The industry uses it, and not only the big boys. Lots of small companies cannot afford hiring someone to do procurement, another guy to do inventory, another to do x y or z. If there is a piece of software that can handle the 'annoying bits' , that is what we will go for.
stuff to think about.
(typed with two fat fingers on a keyboard)