| Author |
 Topic  |
|
Iain Wilkie
United Kingdom
1011 Posts |
 Posted - 20 Aug 2010 : 13:29:59
|
I use multiple libraries .... supplied from different customers and therefore impossible to guarentee unique entries in the libs.
Think of it this way .... a component is built up of a schematic and a footprint or number of footprints. Once built from the these libs it should become unique in it own right and not be open to misinterpretation by it searching libraries whenever it is going to be used. This also means it can be shared with no possibilty of error.
Much in the same way as a PCB design is done .... i.e. the PCB you have just designed contains schematics and footprints .... these are now stored as part of the design so you can send this design to another EPC user and they will be able to open it and all the info is there.
Imagine if it was like the component scenario we have at the moment, and it (the PCB design) only contains links to the information it needs in libraries, the whole thing would be a complete disaster !..
So all I am saying is we want to treat components as complex design units that are totally standalone just in the same way a PCB layout is totally standalone.
Please remember that what I am proposing still means you need the schematic and footprint libs to build the components as before but once complete it holds all the info. Also note that you would still be able to edit/add to a component.
Iain
|
Edited by - Iain Wilkie on 20 Aug 2010 13:58:16 |
 |
|
|
KevL
United Kingdom
78 Posts |
Posted - 20 Aug 2010 : 14:10:56
|
BFGs idea of only having 1 library will solve most of the problems here.
I suspect most of Iains trouble comes from the fact that he ends up with 2 (say) semiconductor libs in his lib search path. 1 is his own and the other is from the days customer.
Duplicate names in each cause him a distaster. I suspect this is a consequence of unintended consequences when EPC lib system was "designed" at the beginning of time. They allowed multiple libs so that one could have a resistor, capacitor, etc lib for ease of maintainance (or so they thought).
But as BFG suggests having a single lib would obviate all of the problems with duplicate filenames if it policed this when items were added to it. The lib merge function to add bits form new lib to proper lib would need some power though. It would have to rename new parts (if needed) and then go and rename them on the schematics and PCB files. Ouch.
Items could trivially be tagged as being Capacitors, resistors etc inside the single lib entity and items could trivially be filtered by the category for searching and maintaning etc.
I still feel that there must be a way of coming up with something to fix Iain's pain without introducing duplication which I and BFG would not be in favour of.
I suppose when I argued against the database option I was dreading a MS Access type setup which can (and most assuredly would) become corrupt and then render the libs broken - especially a multi-user MS access type setup. At that point we'd give up and buy Protel.
I suppose a single lib could be regarded as a "database" but for safety one would have to persuade EPC to give us an ASCII out and backin again fuction so that we could fix it when it breaks.
Ive got corrupt lib files at the moment. Still most libs are OK and we just live with it. Imagine having only 1 lib and it being corrupt - there would be weeping.
I'd be interested in knowing what the EPC devs are thinking re this? Do they take notice of our discourse here???? Maybe commercial and marketing reality is that to sell new seats they have to keep coming up with tickbox features to compete with other PCB packages and this is more important than fixing problems which need a big re-write. (One can sympathise with commercial reality)
Kev
|
|
|
|
Iain Wilkie
United Kingdom
1011 Posts |
Posted - 21 Aug 2010 : 10:19:51
|
Kev,
Your point about the EPC developers is bang on .... I know we have differing views on how to fix this, but we are united in that there is a problem that does need fixing and thats the whole reason for this thread.
I have driven this from scratch in a bid that it will attract so much input that the dev guys would need to take notice .... we need to keep the momentum up, probably continuously so that this can be put right for V15.
The release of V15 proved to me that the features that EPC can offer is now more or less at saturation point and that they will now have so much time on their hands that to direct their thoughts to this ... the major achilles heel of EPC, might be a way forward.
However to attract their attention we need people power and I am glad to see this thread growing to hopefully to be one of the biggest on the forum.
However I would have though that even by now we would have had some input from EPC on this ..... even if it was just to say "we hear what you are saying" , but alas nothing so far.
So "HELLO EPC ARE YOU THERE ?" your absence is worrying....
Also I call on all other EPC users to let there feelings and views on this be recorded on this thread if you agree with what is being debated. Even if you have no ideas on how to improve this, still leave a comment and at least we can present it as a petition.
And come on EPC at least let us know you are listening !
Iain |
|
|
|
KevL
United Kingdom
78 Posts |
Posted - 22 Aug 2010 : 11:35:14
|
i'm on holiday in Turkey at the moment. I have lots of time on my hands but its to bloody hot to go outside and so next to my air con I have a few mins to get some thoughts down about what I would like to see.
Will post when next online
|
|
|
|
TheBFG
United Kingdom
61 Posts |
Posted - 23 Aug 2010 : 09:00:26
|
quote:
Originally posted by Iain Wilkie
...
we are united in that there is a problem that does need fixing and thats the whole reason for this thread.
...
Also I call on all other EPC users to let there feelings and views on this be recorded on this thread if you agree with what is being debated. Even if you have no ideas on how to improve this, still leave a comment and at least we can present it as a petition.
Agreed, I think the more people that comment, the more likely we are to arrive at an optimal solution. |
|
|
|
shadders
United Kingdom
223 Posts |
Posted - 23 Aug 2010 : 09:26:16
|
Hi ,
On this topic, i create my own libraries, so if there is already Texas Instruments, i create Texas Instruments Extra libraries and componenets there.
The problem i came across is the updating or installation of a new version - did not want the existing libraries to be up dated and overwrite my compinents.
Hence, the new library system will have to take into account a merge of libraries - the new, the Easy-PC old and your own components.
Apologies if this has already been stated, or is already possible.
Regards,
Richard. |
|
|
|
DavidM
United Kingdom
458 Posts |
Posted - 23 Aug 2010 : 09:35:04
|
Rest assured we are keeping a close eye on the discussion, we are not ignoring you at all. In fact we are glad that such an active discussion is taking place, it makes it more likely that all the possible angles and issues are considered before any changes might be made.
One thing that comes across to me from the discussion so far is that no one solution would necessarily suit everyone, which makes this discussion so important. If we do change how libraries are structured, managed or organised, we want it to be done in the right way and for the right reasons.
So please do keep contributing to the discussion, particularly if you have any thoughts on any issues or implications that have not yet been covered.
David.
|
|
|
|
davep
United Kingdom
101 Posts |
Posted - 25 Aug 2010 : 13:17:45
|
I have one library in use at any time.
The files are located in a workarea folder that gets a backup daily.
The original Easy-PC supplied (and customer) files are kept out of reach of Easy-PC unless required for extracting symbols etc.
If I need (eg a Texas symbol) I copy the library files into the work area temporarily, do a copy and rename the new symbol to avoid any possible conflict.
I agree it is more work to relink circuit and PCB symbols.
I also this copy to 'improve' the symbols (such as creating power gates for ICs).
I have never had any library problems as a result. The recent library search mechanism complications have passed me by!
|
|
|
|
Gary
United Kingdom
1 Posts |
Posted - 27 Aug 2010 : 10:10:55
|
| I would like to see the library modified and personally I am in complete agreement with Iain on this one. I too have issues with using customers libraries and have had confusion with multiple instances of the same component with different pinout due to errors or corrections within the libraries. The potential for mistakes being made when using different versions of libraries is all to real. |
|
|
|
TonyS
USA
16 Posts |
Posted - 27 Sep 2010 : 01:20:46
|
I have had a heck of a time today because of the "first found" nature of the current library structure.
My comments -
1. I feel that when you create a component you should just be able to select a schematic symbol from a specific library and combine it with a pcb footprint from a specific library, and store the "component" in a specific library without having to worry that the wrong primitive will get used.
The problem, as I see it, is simply that created "components" (because of the EPC library structure) do not reference the source library name for each primitive.
You think you are using the \TONY.lib\RESISTOR created using the \TONY.lib\RES schematic symbol along with the \TONY.lib\0603 footprint (it even looks correct while you are "Browse"ing for the pieces. But then you find out that the component you placed on the schematic actually found, and used, the \EPC\RES first.
By including the specific libraries information, KevL can change his "master" 0603 footprint and have it propogate through all the components that specified it, while Iain can use either the \Iain\RESISTOR or the \Tony\RESISTOR (or both for that matter) in a design.
(Sorry that it took me four paragraphs to say what TheBFG said earlier in one sentence : )
2. Why should we be "re-inventing the wheel"? With all the different packages out there, isn't there a favorable library structure(s) that could be emulated (Pulsonix, OrCad, ....)?
Thanks |
|
|
|
Peter Johnson
United Kingdom
493 Posts |
Posted - 27 Sep 2010 : 14:43:35
|
quote:
Originally posted by TonyS
I have had a heck of a time today because of the "first found" nature of the current library structure.
My comments -
<snip>
The problem, as I see it, is simply that created "components" (because of the EPC library structure) do not reference the source library name for each primitive.
You think you are using the \TONY.lib\RESISTOR created using the \TONY.lib\RES schematic symbol along with the \TONY.lib\0603 footprint (it even looks correct while you are "Browse"ing for the pieces. But then you find out that the component you placed on the schematic actually found, and used, the \EPC\RES first.
<snip>
Thanks
When only one path was allowed, components DID reference symbols by name and library, which was unique. As soon as you add multiple paths, it's no longer unique, which is why the operation was changed. There was also a major headache in that symbols weren't portable. Move them to a new library as part of rationalisation, and the components stopped working. With the present system, including a library path to keep a unique link would just make this problem a nightmare!
Other systems aren't necessarily better. For instance, Orcad used to link designs directly to the libraries (they may have changed it now - I don't know). With no internal copy of a component, it meant that if you wanted to ship a design to someone else, you had to ship the library for the design to be readable. |
|
|
|
TonyS
USA
16 Posts |
Posted - 29 Sep 2010 : 17:08:37
|
Peter,
I don't understand how having multiple library paths would impact "uniqueness"? Isn't the \Search Path A\ MyParts ( .cml, ssl, psl) different from \Search Path B\ YourParts ( .cml, ssl, psl)?
I am not saying that the entire library path should be included in the component information, just the library name.
Personally, I do not know the benefit of having multiple library paths to begin with especially when the primitives are not unique. Also, I would rather have a component that "stopped working" knowing that I had messed something up, than having no idea that the wrong symbol was being used because a symbol with the same name was found first in the search path.
And yes, I did use OrCad 1.0, which unfortunately, functioned just as you described. But my point was that Number One should honestly evaluate all the library topologies out there and see if there is a better one (you can't make everyone happy, but I think that a good number of your current users would like a better library structure). |
|
|
|
Peter Johnson
United Kingdom
493 Posts |
Posted - 07 Oct 2010 : 12:19:30
|
quote:
Originally posted by TonyS
Peter,
I don't understand how having multiple library paths would impact "uniqueness"? Isn't the \Search Path A\ MyParts ( .cml, ssl, psl) different from \Search Path B\ YourParts ( .cml, ssl, psl)?
I am not saying that the entire library path should be included in the component information, just the library name.
Yes, but \Search Path A\ MyParts ( .cml, ssl, psl) couldn't be distinguished by library name alone from \Search Path B\ MyParts ( .cml, ssl, psl). Both are perfectly legal. Including the path would lock everything down too hard, and not including the path gives a hybrid between the current issues, and portability issues - in many ways the worst of both systems.
This thread is being monitored and the various different suggestions considered. Nothing can happen before V15, as any change would involve format changes, which would mean early V14 files wouldn't be compatible with later ones - a scenario we're very anxious to avoid. |
|
|
|
johnt
United Kingdom
52 Posts |
Posted - 07 Oct 2010 : 15:47:35
|
I find I don't need to refer back here too often now so if I've missed something - sorry.
I think before I could really discuss this from the perspective
of considering changing structures I'd want to see a text based
or diagram based description of how the existing databases/tables
are defined and how they work together.
This is not somethig I'd like to try and understand from a users point of view at all.
That may seem backward to some (Ian especially maybe) but what is being discussed is redefining a database. I think it would help if the current specification was fully defined in a clear to view format first.
As a new user I did have a few issues at first but I've found ways around them now. Also circuit design is only a part of what I do anyway so I manage ok. For me it isn't a massive problem.
But I would rather not to have had to find ways around my issues so I do think this thread is important.
But I'm suggesting you do it from a software engineering perspective rather than add hoc comments from us all.
I've worked with relational databases and even SSADM (spit curse)
and can only say that no matter how much we hated the
rainforests eaten up by such methodologies - having a well
structured form of design and documentation is sometimes the only way to get a complex job done.
User feedback is always required - but means little if it is dissasociated from actual or proposed designs. As a user we tend to only see the parts that specifically affect us as individuals. That just isn't enough for the task being discussed here.
This is a good product - you are right not to jump too soon
but I think the comments here suggest things need looking at.
If it is accepted that something must be done - the software engineers should be looking at it from that perspective I feel
and should now say so.
I just think (as my grandad used to say) it's time to P or get off the pot.
Otherwise this thread could go on forever without achieving anything at all.
john
|
|
|
|
Iain Wilkie
United Kingdom
1011 Posts |
Posted - 07 Oct 2010 : 19:21:19
|
quote:
Originally posted by johnt
Otherwise this thread could go on forever without achieving anything at all.
john
The threads goal is to send a strong message to the programmers that the library structure needs looking at as a matter of urgency. We have beeen informed that it is being monitored so fingers crossed the hope is that V15 will deliver.
Iain
|
|
|
|
Iain Wilkie
United Kingdom
1011 Posts |
Posted - 05 Jan 2011 : 08:55:56
|
HAPPY NEW YEAR NUMBER ONE !
And the only reason for this post in the New Year is the hope to keep this thread alive and well so that hopefully the programmers that will now be working on V15 can concentrate their efforts in fixing the achilles heel of Easy-PC in preference to any other "major" features.
As you know my particular want is that you create a component using the symbol and footprint libraries as usual, BUT once the component is created it contains the unique symbol and footprint data and NOT links to libraries the way it is at the moment.
You would still be able to add and edit footprints to the component. This gets round the really annoying fact that if you have many libraries from different sources you don't have to enable/disable relevent libraries to get the correct component where names may have been duplicated and different pin mappings used that cause errors in the selected component .... that you can only spot if you are really careful.
I have already been through this loop again on a particular layout and noticed a wrong component pinning due to part of the component picking from the wrong library !.
I know others have other ideas ... I think mine should be a fairly straightforward to implement ?? ... Anyway the main drive here is to keep the thread alive so that a clear message is hopefully sent to the programmers.
Iain
|
Edited by - Iain Wilkie on 07 Jan 2011 10:18:16 |
|
|
|
TonyS
USA
16 Posts |
Posted - 10 Jan 2011 : 19:12:43
|
There are just some things with the library - component structures that are not intuitive to me. When you don't know "why" things are the way they are (some underlying reason) you just assume the design was not thought out as well as it could have been. Perhaps a Library "white paper" is needed.
Today's "head scratcher" example is:
I have an existing Resistor component that I want to add another pcb footprint to. I add the footprint, but where did the existing "values" go (Ohms, Wattage, Tolerance, Part Number,...)? Oh, I see, for some reason, "values" are associated with the PCB footprints and not the component itself (doesn't make sense to me) so I have to take the extra steps of adding existing "value" information back in. I just remembered that I had already brought up this issue ("values" being tied to footprints) in a previous comment. "Intuitively", there should be one set of "values" for a component (and not 5 different "value" sets if you have 5 different footprints).
Not being able to change a package type, while keeping component attributes / values for a component already placed on a schematic is also non-intuitive to me.
Please note that I am "complaining" only because I think EPC (please change the name) is a great tool and I hope it becomes even better. Thanks
|
|
|
|
Iain Wilkie
United Kingdom
1011 Posts |
Posted - 10 Jan 2011 : 20:38:50
|
Tony,
Your are correct.... values are tied to the footprint which is daft. I have spoken to Number one about this and they have added it to their "ToDo" lists....
Iain
|
|
|
|
KevL
United Kingdom
78 Posts |
Posted - 10 Jan 2011 : 20:58:45
|
I think this is a symptom of something I have drawn attention to in the past - i.e. the EZPC app is very (too?) flexible and/or an optimal way of working has not been defined -in the supplied documentation.
One could argue that if a component needs a different footprint then it really requires to be a different component (usually). That is have a single component for say 0603 1% and another for say 1206 1%. Then each component only needs a single footprint. Each component then has its actual value field set when placed on the schematic and other unchanged fields in the schematic symbols then indicate the 0603 1% type info. Thats how we work anyway.
Not sure I realized that the value was actually tied to the footprint. Is it not also tied to the schematic symbol as placed on the schematic?
The only components I have which have multiple footprints is where there is the occasional need to have packages with subtly differing footprints due to lead forming options or horizontal or vertical mounting options e.g. TO-220 packages. Is that what your resistor component alt footprint is about?
K |
|
|
|
Iain Wilkie
United Kingdom
1011 Posts |
|
|
KevL
United Kingdom
78 Posts |
Posted - 11 Jan 2011 : 15:34:07
|
Jees thanks for the link. Was not aware of this issue.
Cant believe the appalling bodge solution of changing the footprint of an 0805 to be physically an 0603 would get past any co. with even the slightest aspiration to have a quality system. We would have to do this properly which would waste many days work (or cost many thousands of pounds - whichever way you count it)
Would cutting and pasting values from the component values grid not be a better solution? Provided that the components were sorted by reference designator then surely that would work OK. If only EZPC could do ASCII out and back in again from all of its grids. :-) Such a simple mod - so many problems solved - so many hours saved.
K
|
|
|
|
TonyS
USA
16 Posts |
Posted - 17 Jan 2011 : 00:13:32
|
| It would be nice if NumberOne provided some feedback to this thread discussing options that they were considering for library improvements. |
|
|
|
Iain Wilkie
United Kingdom
1011 Posts |
Posted - 17 Jan 2011 : 12:03:05
|
Indeed !! .... It does seem somewhat "quiet" from any feedback from NumberOne.
This is one of the hottest topics ever posted on the site (that I can remember), so it would be nice to know that perhaps this may now be considered as "the number one" (get it ?) item on the programers fix list....
Iain |
|
|
|
KevL
United Kingdom
78 Posts |
Posted - 18 Jan 2011 : 13:44:27
|
I'd be interested in knowing what the devs are intending for the next version of EZPC. I'm surprised that number one has not sought advice or feedback as to what users want improved/fixed and what (if any) additional features are wanted. I have been surprised by some of the features which have been worked on and released in previous versions when to my mind more pressing issues have been ignored. Anyway I get the impression - judging by the number of questions which have remained unanswered on the forum - that number one people are currently too busy to contribute to the forum.
K
|
|
|
|
Iain Wilkie
United Kingdom
1011 Posts |
Posted - 29 Jan 2011 : 11:03:32
|
I am getting a bit worried about the lack of response from Number One. There was a time when queries would be replied within a few hours if not maybe a day, but now it is as if they have dissappeared from the radar! . This coupled with the devaluation of the tool with its free offing to RS, I become to wonder if the product is about to hit the buffers.
I think I for one would like to hear something from NumberOne so that if there is an imminent demise, then at least we all know and can move on and plan for the future.
I will post this in the "General Area" as well.
Iain
|
Edited by - Iain Wilkie on 29 Jan 2011 11:08:13 |
|
|
|
DavidM
United Kingdom
458 Posts |
Posted - 01 Feb 2011 : 15:23:36
|
I've already responded to the other thread about perceived lack of responsiveness from Number One:
http://www.numberone.com/forum/topic.asp?TOPIC_ID=540
On the subject of library structure, we are certainly not ignoring the question and will be reviewing all the pros and cons of the suggestions aired in this discussion as we plan for the next Easy-PC version.
As for other suggestions for improvements, we are always happy to hear them. Selection of features for a new version is always a balancing act between attracting new users and retaining existing ones.
Many of our existing users are happy with the product and generally only want small changes here and there to make their particular kind of project easier to do, whereas these small features don't in themselves necessarily have significant appeal to prospective new users. Many of the over 500 suggestions currently logged on our database fall into this 'minor improvement' category, but that isn't to say our ears are closed to more enhancement requests. Just email your ideas to support@numberone.com and we'll consider them.
David.
|
|
|
|
DavidM
United Kingdom
458 Posts |
Posted - 05 Apr 2011 : 14:41:25
|
I wonder if the following would resolve the bulk of the issues that Iain has with mixing libraries....?
What about a global setting that says the library access can only retrieve footprints or symbols from libraries that are in the same folder as the library from which the component is being read?
That way you would not accidentally get an SOT23 footprint from your ABC library set when adding a component from your XYZ customer library set. If it couldn't find an SOT23 in the folder where the XYZ component library lives, you would get an error message instead of it silently collecting one from the ABC footprint library.
You would of course still have to partition your libraries into folders so that there weren't 2 footprint libraries holding an SOT23 in the same folder, but we could always look at adding a tool for checking this.
Can you all please give this idea some thought, and let me know if this - or something like it - would be a workable solution to this issue?
Don't forget that a percentage of our user base actually prefer the way its working now, so we would prefer a solution that caters for both scenarios.
David.
|
|
|
|
Iain Wilkie
United Kingdom
1011 Posts |
Posted - 05 Apr 2011 : 19:52:39
|
Hi David,
Sorry but it doesn't do it for me ! ... For a start a component may be built from a schematic symbol that lives in one library folder and a footprint from another ... thats perfectly reasonable as you want to gather the relevent info for your component no matter where it lives. So unless you deliberately copy the info into a new library folder then it doesn't work. What I am saying is once you have created a component, why does the info not just reside in the component rather that try and gather it everytime you want to use it. The other thing about it is if you create a component to "give" to somebody else, you need to give them 3 files !!
Iain
|
|
|
|
johnt
United Kingdom
52 Posts |
Posted - 07 Apr 2011 : 11:24:49
|
That would be object oriented programming Iain. The problem is if an application isn't designed that way right from the start you can't just bolt it on afterward or you end up with a pile of confused spaghetti. (see MS windows / IBM OS2 for example)
There is much that is simply being done wrong by application programmers these days. Much of it caused by M$ incompetent OS designs. (The use of a registry to store application data, failure to keep all application specific code in one tree, the lack of OOP and consequences of, bloating of OS distributions with irrelevant rubbish, totaL deliberate confusion about what is and is not part of an operating system...) the list is endless and frankly hilarious.
The consequences less so.
john
|
|
|
|
DavidM
United Kingdom
458 Posts |
Posted - 08 Apr 2011 : 14:46:56
|
Given the range of opinions and feedback about this topic and the various pros and cons of different options, I still think that something like what I have proposed would cover it. To elaborate on what we are proposing:-
1) a component library could be marked (probably using a setting in the Library Manager dialog) to specify that it only looks in the same folder for its symbols.
2) a component from such a library would thus attempt to locate its symbols in symbol libraries in the same folder, and if not found, would not look in other folders
3) a component could be also created which used symbols from libraries in other folders
4) the act of doing 3 would request that you identify the destination symbol libraries in the component library's folder, into which the symbols would be copied so that they can be referenced 'sideways' from the component.
To elaborate slightly on the thinking, the copying of symbols at (4) does not duplicate symbol data any more than the suggestion to 'bind' symbol data inside components. Regardless of whether the symbols came from the same folder or a different folder, binding them inside the component would still require the symbol data to be copied.
Alternative to this is that the symbol libraries for such a component library are always the same filename as the component library, that way they always go together as a set and you almost get a 'bound' set of data even though its at the file level and not on an individual item basis.
At least with our current proposal it is not copied for every component in the current folder that references it, and the symbols are still available to be accessed for update with the existing editing tools. Thus no major rework is required, and the current method of working is still available for those many users who prefer it that way.
I look forward to hearing responses to this suggestion.
|
|
|
|
Topic |
|
Library Structure Suggestion