| Author |
 Topic  |
|
Iain Wilkie
United Kingdom
1011 Posts |
 Posted - 27 Mar 2010 : 18:55:02
|
Just a thought, but as sometimes there are still conflicts with duplicate schematic and pcb symbols that sometimes means enabling/disabling certain libraries, would it no be an idea for the component to contain the full schematic and footprint info instead of simply their referencies within the external schematic and footprint libs ?... Obviously these libraries will be important when creating a component, but if all the info is now stored in the component, there can be no conflicts ever .... I know it would increase the size of the library but surely this would anly be a minor deatail ?
Iain
|
|
|
Peter Johnson
United Kingdom
493 Posts |
Posted - 31 Mar 2010 : 14:33:26
|
| I don't know the full implications of this, but I agree, it would remove a lot of confusion. I've logged it as an urgent suggestion. |
 |
|
|
Iain Wilkie
United Kingdom
1011 Posts |
Posted - 01 Apr 2010 : 12:59:08
|
In my opinion if this could be done it would remove a major problem with the library structure.
The library structure has never really been quite right... even after its revamp a few revs ago.
For myself who have to juggle with libraries generated by customers, that they have created themselves, plus my own and the optional libraries, it is an utter nightmare trying to do a simple task, such as copying and pasting in a component from one design to another.
If differnet libs are involved you need to enable/disable certain ones and since my libs come from other sources, you have to be careful for duplications of names etc. It really is a task.
Having all the info within the component would eliminate all this confusion, simply copy and paste ... job done. Also when returning libraries to customers would only need one file .. not 3.
Being a long term user of EasyPC I can honestly say that the library structure as it is, is the only part of the tool that really lets it down badly. It would be interesting to see what others think, but a do think it would be a fantastic step forward for the product if this could be acheived.
Iain
|
|
|
|
olga
United Kingdom
107 Posts |
Posted - 30 Jun 2010 : 20:44:52
|
I haven't been around for a while, but I'm having a catch up on the forums...
I do agree with Iain that the library structure could be improved, and I think that the suggestion of each component having the full information with it is a good idea. That way, the component itself is inviolate, and the schematic & footprint libraries are then repositories for the basic building blocks, IYSWIM.
Best wishes,
Olga. |
|
|
|
Peter Johnson
United Kingdom
493 Posts |
Posted - 02 Jul 2010 : 15:38:41
|
| Well, I can 'reassure' you that it hasn't made the cut into V14. However, that means that there's a year for everyone to pitch in and say if they want this to happen. We really do listen to users, so a strong ground swell of opinion that this is the way to go would certainly have an impact. Over to you! |
|
|
|
johnt
United Kingdom
52 Posts |
Posted - 05 Jul 2010 : 16:39:56
|
I'm not really experienced with this enough yet but what I did
when importing eagle libraries was to add my company name
as a postfix to the imported library name and their source.
eg 7400HC_jt_eagle
If you could get your clients to do something like that it might
help for now with libraries maybe.
A utility to append such a string to components in the databases
might be a stop gap for component items if thats even possible
although wouldn't the database carry the library name as the source with each item?
just thinking out loud here.
john
|
|
|
|
Peter Johnson
United Kingdom
493 Posts |
Posted - 15 Jul 2010 : 15:59:13
|
The biggest snag here is that the library names are irrelevant. The program searches for both components and their symbols by name independently of the library name. All the library name and location does is determine which are searched first.
That's the whole point of Iain's suggestion, to minimise the impact of what at times can become a bit of a lottery. |
|
|
|
KevL
United Kingdom
78 Posts |
Posted - 02 Aug 2010 : 23:28:41
|
quote:
Just a thought, but as sometimes there are still conflicts with duplicate schematic and pcb symbols that sometimes means enabling/disabling certain libraries, would it no be an idea for the component to contain the full schematic and footprint info instead of simply their referencies within the external schematic and footprint libs ?... Obviously these libraries will be important when creating a component, but if all the info is now stored in the component, there can be no conflicts ever .... I know it would increase the size of the library but surely this would anly be a minor deatail ?
Iain
Maybe this is a controversial view but I like the way the components work. I think there are problems with the way the libraries work (styles, no global editing capability, binary format libs with no tool for ascii-ing out and in) but not in the way the sch symbols and footprints work.
Surely if you make all of the footprint and schematic symbol info live inside the component then there will be huge duplication? The way the libs work at the moment there is only 1 resistor symbol and 1 SOT-23 definition and these are re-used many times.
If I decide my SOT-23 pcb footprint is wrong I can change it in 1 place and all components which use it get updated for free.
If each component has its own drawing of the SOT-23 then how can I avoid having to edit each component containing the SOT-23 footprint?
But having said that I dont have to deal with customers libs etc and only have a single set of libs which are very tightly controlled and have no duplicates etc.
Kev
|
Edited by - KevL on 02 Aug 2010 23:39:59 |
|
|
|
Iain Wilkie
United Kingdom
1011 Posts |
Posted - 03 Aug 2010 : 08:59:18
|
Kev,
Yes it would cause duplication.... but so what ? ... maybe in the old days of shotages of memory and slow machines it would be a problem, but not today. At the moment, when using lots of libraries (and some that are not your own) the chances of a component picking up the wong footprint is a reality. It has actaully happened to me 2 times, where a board has gone to manufacture only to find a transistor has the wrong pinning. Also when transferring components, you need to supply three files .... not very elegent. The idea is all the libraries stay as they are but are ONLY used to build a component. Once built ALL the info is in the component file, makes for musch easier handling and no risk of future error.
Iain |
|
|
|
pedro444
United Kingdom
25 Posts |
Posted - 03 Aug 2010 : 10:37:41
|
I'm sure the main problems with the library system all stem from
the fact it was designed in the dim and distant past when storage
and computing power was at a premium. Add to this the fact that
there were fewer footprints to handle it all seemed to be very sensible
then. Now with even the simplest of designs it can run into many tens of
footprints & devices. The library system is suffering from component
overload (in my opinion).
So what to do about it.
Firstly my main nag about the system is there is no audit trail. It's
just impossible to be certain that say a component on any one design is the
same as the component that comes up when added to a new design. Was it
updated in between, how can I be sure they are the same. There is just
no way to be absolutly certain. I don't mind the library system as it
is, it's just that components/footprints & schematics need more information
associated with each item. It could possibly be date & time although I always
feel this is a poor way of identifying items.
If it was me implementing the library I would do it something along the following lines.
I would use a proprierty or open database to store everything in.
Each item would have a unique identifier which encompasses all
data of the item, be it a schematic/footprint/component. My preference
would be a hash that lives with the item (Google "hash" if you don't know
what a hash is). Store say the creation or modify date/time in with the item
together with say a version number.
A hash uniquely describes a piece of data, change it even slightly and its
hash changes. Now if you have to compare say two footprints, if the hash
is the same for both the footprint is identical, if different you don't
know how they are different just that they are.
All this could be done keeping the look and feel of the current library
system.
This is where I would now implement another layer above all the current library
where the individual items are bound together in a single entity (all the
component parts bound together). This single entity has its own identification
(hash) to make it unique. It also contains each individual hash from the parts
that make it up.
Add this to a design and because the hashes are part of the individual items
they get saved with the design. Every part of every design is now uniquely
identified. Every item in a component is uniquely identified.
Utilities can now safely update items. Change a SOT23 footprint slightly
and you now have the option of making a new footprint, replacing an existing
footprint, changing / updating the footprint used in a design.
A design could also contain true audit trail, "this" was changed for "that"
on whatever date.
These are just my thoughts on the problem, it may be easy to implement, it may
be a nightmare. Either way I feel a revamp will be of interest to most users
who would be prepared to pay for a more secure library system.
|
|
|
|
KevL
United Kingdom
78 Posts |
Posted - 03 Aug 2010 : 12:24:53
|
quote:
Kev,
Yes it would cause duplication.... but so what ? ...
I'm not concerned about disk space. I agree completely that it is effectively free and not in short supply.
My only concern is that once you have 2 (or more) copies of a single footprint then there is a risk of them being different...... and as we know a footprint is either correct or it is not. So all components which call up a particular flavour of SOT23 should have identical footprints - if they dont then some must be wrong.
Now imagine my assembly house says to me. Thy SOT23 package maketh us weep. For its middle pad size is not what we had mind and it maketh our line break.
So now I need to fix my footprint. As it is now, I change one instance in the footprint lib and am safe in the knowledge that a quick update components (followed by a glacially slow move every string on the PCB, 2days @£1000 per day God Altium looks cheap - dont get me started on that) in PCB will fix all.
Though I suppose if the Lib manager had more power it would say
I notice you have fixed your formerly crappy SOT23 package! Would you like to update all components with this new footprint info so that your libararies dont degenerate into an uncontrollable mess....AGAIN.
Ah global and management of libraries. Tools to help maintain stuff. Maybe in version N where N is large.
Kev
|
|
|
|
Iain Wilkie
United Kingdom
1011 Posts |
Posted - 03 Aug 2010 : 17:02:19
|
The way it is at the moment Kev is that you correct YOUR SOT23 footprint. But then later you laod another library with a different pinning on a SOT23 contained within it, and that library is above yours in the search path ..... hey presto, you do another design load in a component that you think is your corrected one, but its not !!!!!! ... and your back to a faulty board.
The only way to maintain this is to hold all the info in your component. You can then use it time and time again in confidence that nothing can alter it.
Iain |
|
|
|
KevL
United Kingdom
78 Posts |
Posted - 03 Aug 2010 : 19:19:04
|
Iain, I think I'm beginning to understand the trouble you have with libs. As I said I dont have to deal with customers libs etc so have never experienced your pain. Though now I can see why it is so problematic.
What you really need to solve your problem is almost to have a separate lib per customer. So you might have IBM.lib, RollsRoyce.lib etc.
Could you not then put each customers lib in a different directory and point your library folders to only see your required customers libs when working on a particular customer PCB? Does component caching etc stop this working?
The only fix I can see to solve your problem is for EZ to provide a tool to tag filnames with a code. So at the moment you have
NPN.sch sym
SOT-23 xxxx.pcb footprint
BC556.component definition.
The tool would be able to rename the above items to append a customer no to the filenames (or even tag them with invisble metadata). It would also climb inside the component definition and update the refs to suite so that one might use the renaming function to rename your own personal libs to
NPN_000.sch sym
SOT-23 xxxx_000.pcb footprint
BC556_000.component definition.
where _000 is your customer no - which the lib manager might handle for you by providing a table thus
Customer No. Customer Name
000 Standard Libs
001 IBM Libs
002 Rolls Royce libs
So your IBMs libs get renamed
NPN_001.sch sym
SOT-23 xxxx_001.pcb footprint
BC556_001.component definition.
This would probably fix your issue by forcing all components from different customers to have a different name. Especially if the tool was clever enough to be able to rename _000 ending libs from IBM to _001 libs which would be your name for them.
Sounds quite easy to implement.
Kev
Kev
|
Edited by - KevL on 03 Aug 2010 19:34:38 |
|
|
|
Iain Wilkie
United Kingdom
1011 Posts |
Posted - 04 Aug 2010 : 09:48:02
|
Kev,
Your overcomplicating things .... for a start I may have customers libs but I then perhaps what to use a component in one customers lib in another un-related design. In that situation I need to "remember" which customers lib the component was in, then enable the tre libs associated with that customer, ensure that there is no libs enabled "above" the libs and then go searching for the component !!! .... Thats just crazy.
If components are stored in their entirety then I just need to remember or scan through all components to find the one I need .. confirm its what I am looking for and drop it into the design, in the knowledge that I know its ok.
At the moment if I wanted to give you a component I need to give you three files !!! ... thats just plain daft,
Once a component is created it should become integral in its own right
Iain
|
|
|
|
KevL
United Kingdom
78 Posts |
Posted - 04 Aug 2010 : 20:45:38
|
Overcomplicating
Yes maybe but unless Pedros database mechanism is implemented then you have to have some sort of version control and different versions need different names or else the DOS will over write them.
Personally I think the lib binary file format is quite enough encryption. Hiding the data in a database with multiple user access over a network is unlikely to end well. We would hate to have our libs corrupted .... AGAIN.
But the more I think about this the more it seems to me that there are actually conflicting requirements. This is probably why the devs at No1 have not hurried to fix this. It isn't easy.
1. Put gate, footprint and component data in one structure so that you never get gate/footprint info out of kilter when dealing with multiple lib sources when you are dealing with many libraries (Iain's Issue)
2. Not getting into a situation where we have multiple differing (say) SOT-23 variants in our libs when we would much rather have all our components calling up a single (correct) footprint.
I think the issue of 3 types of lib is an inconvenience rather than a show stopper. If issue 1 was not present then we would put up with that (I think). Gerber files are multiple files (one for each layer + drill data etc). We get used to that and just zip them etc. Last time I used Protel (99SE+Sp6) it had two files 1 component/ gate symbol and 1 footprint called up by it so this is not a unique issue for Easy PC.
Some users (like me) only have 1 set of very carefully crafted and controlled libs so never have problem 1. But issue 2 is important as there are lots of other probs with libs which make control and consistency very hard and adding issue 2 would be the last straw.
Some users (Iain and other Design houses) have to deal with many libs and so 1 is a nightmare. Is issue 2 not an issue for you? Maybe it is an issue but if you could just get a couple of SOT-23s on a board with thye correct pin out 2 days running you put up with 2???
IMHO If libs must be changed then both issues need to be sorted by whatever is the replacement.
Am I right in seeing both issues as being equally important for an optimal system?
Kev |
|
|
|
Iain Wilkie
United Kingdom
1011 Posts |
Posted - 05 Aug 2010 : 09:25:27
|
If issue 1 is resolved by combining the schematic/footprint/ component data into one component (the solution I am proposing) then issue 2 is solved .... thats my point.
When you build a component, one of the steps is to map the schematic pins to the footprint pins, so it doesn't matter say which SOT23 footprint that emerges from the footpint library when you create the component, the creater will map it properly regardless of how the pins have been numbered and end up with a "correct" component that is now transportable.
Iain
|
|
|
|
KevL
United Kingdom
78 Posts |
Posted - 05 Aug 2010 : 10:06:52
|
quote:
If issue 1 is resolved by combining the schematic/footprint/ component data into one component (the solution I am proposing) then issue 2 is solved .... thats my point.
I cant see that the above statement is true. Maybe I'm being dumb (quite possibly).
You have multiple components each with its own private copy of a say SOT-23 PCB footprint.
After Ive made (say) 98 components containing the SOT-23 footprint
I notice one of my SOT-23 pads needs to change size (say). How do I avoid having to open each component containing the SOT-23 footprint and editing it??
Kev
|
|
|
|
Iain Wilkie
United Kingdom
1011 Posts |
Posted - 05 Aug 2010 : 10:23:32
|
Why would you want to change the footprint pad size ?
If it needs to be altered for a particular design simply edit it in the design ... simple.
Iain
|
|
|
|
KevL
United Kingdom
78 Posts |
Posted - 05 Aug 2010 : 10:35:26
|
I wouldn't want to change the footprint at all but I might be forced to by having a change of PCB board assembly house. Their process might want different pad sizes.
Also it might not be pad sizes that need to change, Might be silk screen clearance from pads due to different design rules, requirment, soldering temperature profile. Any number of reasons that production engineers use to justify their salaries and cause electronic engineers to do the job twice.
Most assy houses say the the IPC footprints are a good place to start then hand you a list of the changes they cosniderer essential for high yield. Total pain in the bbackside but there you are. Maybe it is only high volume assy houses that are that choosey but there really are good reasons to have to change footprint after the event.
Changing footprints at PCB level is a horrible bodge. An uncontrollable mess.
If the footprint pads need changing they need to be changed in the libs so that next time a PCB is designed no one has to remeber to bodge the footprints after placement.
Kev
|
Edited by - KevL on 05 Aug 2010 10:35:44 |
|
|
|
Iain Wilkie
United Kingdom
1011 Posts |
Posted - 05 Aug 2010 : 10:54:07
|
Kev,
In the 18 years I have done PCB layout for hundreds of customers with a dozen of different fab houses I have NEVER come across this.
Normally the Fab house will adjust the gerbers anyway to suit their process. If there is anything untoward in this , they contact and check.
Also if you DID change it all in the library, there is nothing to stop another manufacturer wanting it changed again etc etc,
Any changes for any particular design need to be local to that design.
Iain
|
Edited by - Iain Wilkie on 05 Aug 2010 11:11:32 |
|
|
|
KevL
United Kingdom
78 Posts |
Posted - 05 Aug 2010 : 11:09:50
|
Kev,
In the 18 years I have done PCB layout for hundreds of customers with a dozen of different fab houses I have NEVER come across this.
Then you have lived a charmed life and I am envious. I have worked for a number of companies where I used to dread the purchasing dept finding a new cheaper source of populated PCBs as it ALWAYS injvolved me or my guys having to dick around with data at the whim of some process engineer. Sometimes one had to wonder whether they had to change stuff just to prove they actually contributed to the job???
You might be insulated from it by your customer's production dept's or you have been dealing with smaller comanies with the "good" sense not to have to many QA guys etc.
Having fab houses mess with your gerbers is verboten by most companies with a quality system. They are making changes to co. data. The data has gone through design review process, version control, archiving. The output of some geezer with a scalpel may not have done. It is also recognised that if you have to post-process data to make it correct then you have to be really sure of the systems in place to ensure the post processing is always done. Will the guy who post processed last time remember to do it next time????
Quality systems .... dont you just love em.
Kev
|
Edited by - KevL on 05 Aug 2010 16:17:34 |
|
|
|
Iain Wilkie
United Kingdom
1011 Posts |
Posted - 05 Aug 2010 : 17:59:41
|
Kev,
I wouldn't say it was a charmed life ... but it is a fact that this is not an issue I have come across to any extent.
Of cource there are always "tweeks" that need to be done after the first or even second spin but its never anything that causes a major headache.
Each Fab has its own set of design rules, and of course there are some generalities, but our designs tend to meet their criterion so there is never much of a problem.
I hear what you are saying about gerber adjustment ... and from the copper point of view there would always be a two way communication as there can be EMC and SI issues in that, but solder paste and resist apertures are sometimes brought into line with the particular processes.
Although a lot of the stuff I do is at the research and development level where quantities are not large .. I do have some major big players producing thousands of various layouts and really there is no problem along the lines you mention.
It could be that since your buyers are looking for cheaper supply, the lower cost board can suffer from a quality point of view and the the manufacturer needs to loosen tolerancies to reduce that cost and scrap to make it viable.
That did happen with one of our designs ... it was fine, changed manufacture to save money .... suddenly zero yeild, but rather than "edit" the tolerance errors out of the design, the client felt happier going back to the original supplier.
There is a lot of truth in you only get what you pay for !
Anyway I still think that one thing you do not want to be able to do is change a footprint globally in already designed components ....
Iain
|
|
|
|
KevL
United Kingdom
78 Posts |
Posted - 05 Aug 2010 : 20:03:21
|
Iain
Yes I agree with everything you have said re design rules being fab dependent etc, tweaks, needed resist appertures etc.
The other issue I come across a lot is that you actually need different footprints for some SM parts depending whether you are going to hand solder the first 10 prototypes and have production quantities machine assembled.
I've cocked that issue up more times than I'd like to admit. I open a datasheet, copy the footprint and think no more of it. Then when the boards come in my technicians bitch and moan that the footprints dont allow access to the pads by a soldering iron for hand assembly. i.e. pads are covered by part and are OK for paste and reflow but useless for hand assy. Out comes the solder paste , paintbrush and hot air blower - with attendent moaning from said technician.
Many SM inductors are like this - maybe because you do the layout job full time you dont make these daft sorts of errors.
Anyway we see the world differently re the below
quote:
Anyway I still think that one thing you do not want to be able to do is change a footprint globally in already designed components ....
I may be oversensitive on this issue but I have to say that I couldn't continue to use EZPC if I had to open a large number of components to modify what should be identical footprints. I would have to change PCB package.
I already have major issues with the difficulty in maintaining the libs. It might be the case that my company would be better off buying 4 seats of a considerably more expensive PCB package so that library maintainance would be faster - and hence more cost effective. Which is a pity because I really like the EZPC editor for drawing schematics and PCBs. It is fantastic value. Without disclosing proprietry info I'm sure you know what the charge out rate for design engineers in consultancy type companies is. £1000++ per day would not be far wide of the mark.
It simply isn't cost effective to have to spend vast ammounts of time hand editing components and having to do it in a number of components would only make this worse. As it is EZ PCB library primitives, styles, layers are very difficult to get working right - and almost impossible to get consistent - especially if, like us, you realise half way through using the libs that the way layers etc had been assigned was not working as well as it could. Our footprints have been designed to have silk screen outlines and also an accurate mechanical drawing layer so that we can export DXF and IDF data to solidworks. The way EZ PC is at the moment there is no alternative to opening up each component in a lib and editing say reference designator styles (the R and V symbols) there is no top level control. Now you might argue that maybe I should have worked out exactly what was needed before we got half way through drawing our libs - and you would be right - but we did try - just got it wrong.
In protel I can edit a footprint (say change line width of silk screen from 10mil to 8mil) and then apply that change to every part in the library - or all libraries i.e. it effectively does a search and replace of styles. In EZPC I have to open every part and do the job one at a time. This wastes hours.
This coupled with the need to hand edit component reference designators to ensure consistent contiguous numbering (to avoid phone calls asking why there is no R13 and R26 on the BOM - is this a mistake?) make some aspects of EZ PC very expensive to use.
Anyway I suspect we are not going to agree on this - though I'm certain that does not make either of us wrong. I hope you dont take my disagreement as a lack of respect - Just different ways of working and different needs etc.
Kev
|
Edited by - KevL on 05 Aug 2010 20:53:57 |
|
|
|
Iain Wilkie
United Kingdom
1011 Posts |
Posted - 05 Aug 2010 : 20:56:03
|
Kev,
There is no dis-respect in anyway and none is taken ... more a lively debate that would be much easier done over an evening in the pub !. (and a lot more fun)
However two opposing views really due to two different working practices. This is were we need more users to join this debate to see which way it should be driven.
There are a few comments at the start of this thread, but latterly it seems to have been ourselves, which has perhaps been productive in airing two different opinions and kicking things off for a wider debate.
So lets hear from the rest of you guys, there are plenty of you out there. I think we agree the library structure has to change, but what does everyone else think...... ??
Iain
|
Edited by - Iain Wilkie on 12 Aug 2010 12:52:08 |
|
|
|
MikeMillen
United Kingdom
10 Posts |
Posted - 12 Aug 2010 : 09:15:54
|
I'd like to voice my support for Iain's proposal. It would represent a significant improvement to EPC, I believe.
A possible solution to Kev's objection would be if the Library Editor offered the option to globally find & change all instances of the changed symbol.
That way you can keep changes local or update the whole library.
|
|
|
|
neily
United Kingdom
3 Posts |
Posted - 12 Aug 2010 : 12:41:08
|
I too agree with Iain's proposed change to the libs and think that Mikes suggestion would be a good addition.
Has anyone from Number One commented on this yet?
|
|
|
|
jlawton
United Kingdom
107 Posts |
Posted - 17 Aug 2010 : 19:06:19
|
IMO the old system has become inadequate in the modern age with so many components available. I honestly don't see how it can be easily fixed as it stands.
I think that Pedro's proposal of a library system based on a database is the way to go. That way much more information can be related to each component, such as multiple vendor part numbers, and it could be searchable /sortable in different fields, etc. The relationship between schematic and layout parts would also be held in the database, and would be editable.
Look at Orcad Capture CIS as a way forward. http://www.ema-eda.com/resources/multimedia/RequestItem.aspx?itemID=193&campaignID=326 shows how the package has links to the component vendors.
See how new parts can be found then added to the local database: http://www.activeparts.com/walk-through.htm and http://www.activeparts.com/demo/activeparts.html
This looks like a better way forward from my point of view than vendor locked CAD packages like DesignSpark or the Advanced Circuits package.
Yes, I know EPC is a budget package!
BTW, why am I never offered an upgrade to the Pulsonix system, I think the sales side is missing a trick here :)
John |
|
|
|
KevL
United Kingdom
78 Posts |
Posted - 19 Aug 2010 : 11:00:38
|
Not really disagreeing with the above but maybe a few thoughts to stir into the equation re component libs and databases.
A populated PCB is usually a subassembly to a larger system. As such a BOM from a PCB will typically become part of a larger BOM which is typically managed by an MRP system. The rest of the BOM might come from multiple sources (e.g 3D CAD etc) Even if you sell populated PCBs there will be items in the product not fitted to the PCB (e.g. poly bag, manual, leads, labels etc). So unless you make schematics containing symbols for labels etc then EPC wont ever make a complete BOM.
The MRP system will usually contain purchasing info, description, supplier info cost etc etc.
There is NEVER a requirement for duplication of said info. If "SAME" info is in two places then it will be wrong in one of them because it will be impossible to keep the info the same.
So is an information rich database system nailed onto a PCB package really the way to go? Is the PCB package really the going to replace an MRP system???
I get the impression that many competitive products add lots of facilities to their packages because they have run out of ways to allow tracks to be joined to pads (E.g Protel). So you get bolt on poor mans MRP systems etc, 3d board viewers which guess what the parts nmight looklike, really poor mans 3d CAD etc. etc.
I would think the info in the libs should be the minimum to unambiguously identify a part in a schematic (for design and design review) and then in a BOM for export to MRP. I.e. keep EPC databse simple with low info content .... but the parts should reference external data and EPC should be capable of BOM output in a format that external MRP systems can deal with (CSV).
I think one of the main problems with the curent lib system is tht EPC designed a completely flexible system then failed to advise a preferred way to configure and use it. Hence many of the lib problems. |
Edited by - KevL on 19 Aug 2010 11:18:00 |
|
|
|
TheBFG
United Kingdom
61 Posts |
Posted - 20 Aug 2010 : 08:20:24
|
I don't think copying PCB footprint data into a component is a good idea. I don't think data duplication is ever a good idea and I guess thats why databases use more than one table!
The problem I have with the libraries is simply that there is more than one, and therefore names become non unique and it is possible to pull an incorrect (but identically named) PCB footprint from the wrong library.
I think one library, with partitions perhaps, and good import / export / update facilities is the way to go.
As for exporting and sharing components then I think yes all info should go in one file, but when it is imported some checking would need to be done to make sure the footprint and symbol names did not already exist in the target library. |
|
|
|
Iain Wilkie
United Kingdom
1011 Posts |
Posted - 20 Aug 2010 : 09:27:10
|
In other words we would still have the same problem ... if there is duplicate information which is correct ?.
Having all the info within the component gets round this. Please note that you could (if you wish) edit/add to the footprint info within a component, but that would be under your control. Th problem arises at the moment when the component "looks" for its footprint in the libraries by name only and can (and has done in the past) applyed the wrong pinning !.
iain
|
|
|
|
TheBFG
United Kingdom
61 Posts |
Posted - 20 Aug 2010 : 10:43:48
|
I really don't think the solution is to duplicate footprint data in the component. This is generally considered bad practice, hence my comment on database design, and this is really a problem of database design.
Like you say the problem occurs because the SW looks for the footprint by name only, and there may be another footprint in a different library with the same name. There is not enough information (other than search order) to pick the correct footprint.
Possible solutions are
1. Use just one library - as long PCB footprint name is unique (i.e. primary key), no problem occurs.
2. If using multiple libraries, each footprint name in each library must be unique, and each library must have a unique identifer or name. The component then references both the PCB footprint name and the library name it came from. |
|
|
|
Topic |
|
Library Structure Suggestion