| T O P I C R E V I E W |
| Iain Wilkie |
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
|
| 30 L A T E S T R E P L I E S (Newest First) |
| jlawton |
Posted - 20 Aug 2012 : 12:36:20
quote:
Originally posted by davep
I do something similar.
I order to control the resulting schematic and layout I only use symbols from my own library.
These are usually created from scratch but in some cases I copy from Easy-PC provided libraries and edit them to fit my rules.
Fortunately I do not tend to get involved with high density parts such as 128 pin processors etc.
All my symbols are named as drawing numbers and carry issues as one of the values.
I do the same and only turn on my libraries to avoid conflicts. If we are staying with the same system for now it would be very nice if the symbol name could contain more characters as meaningful descriptions are difficult with the current limit.
John
John Lawton Electronics |
| davep |
Posted - 18 Aug 2012 : 14:40:24
I do something similar.
I order to control the resulting schematic and layout I only use symbols from my own library.
These are usually created from scratch but in some cases I copy from Easy-PC provided libraries and edit them to fit my rules.
Fortunately I do not tend to get involved with high density parts such as 128 pin processors etc.
All my symbols are named as drawing numbers and carry issues as one of the values.
My prefered method is:
(1) check the component library to see what schematic and layout symbols are used.
(2) copy each of these into the new library.
(3) rename them.
(4) go into component item and change names there.
(5) check and fix any problems.
(6) customise as necessary.
|
| JoeB |
Posted - 17 Aug 2012 : 10:57:53
OK, well i'll have to work around that.
Is there a way to know quickly what lib a symbol and footprint are being taken from? I'm guessing not as it depends on the lib order.
When does EPC show an error is symbol or footprint are not found? I dont want to have to add all my components to a sch/pcb just to check them !! |
| Iain Wilkie |
Posted - 17 Aug 2012 : 10:43:14
Joe,
Unfortunatley NO it was not implemented, so you are experiancing the situation I was complaining about. Basically the component, schematic symbol, and pcb symbols are contained in seperate libs. When you select a conponent the system scans in order from top to bottom through the libs looking for the symbol name. You will notice you can change the order of the libs by moving them up and down. But if there is a symbol that has the same name in more than one enabled lib, it will pick the first one it finds, and if it is incorrect and perhaps has a different pinning then BANG ! You have a bad component that unless you spot it will stop your pcb working. Numberone tried to address this with "Bound Libraries" but this is not common knowledge, please contact them directly to find out how to implement it. I did try it but it too ha flaws. Basically it restricts the search of a component parts to fixed libraries and excludes all others.
I have constantly said that the current library structure is the achillees heel of EasyPC and that once a component is generated it should be a complete entity, but Numberone have made it clear they will never change this.
Iain |
| JoeB |
Posted - 17 Aug 2012 : 09:52:53
Hi- Was this implemented?
I am currently creating my own library (EPC V16).
I have copied a component from one lib, to my lib. It doesn't appear to copy the footprint and symbol, so I have copied them too (well i think i have, as a copied more than one component at a time, i may have missed one).
Is there a way to quickly see what lib the footprint and symbol are from when viewing components in the lib manager?
I cant see this, and have to "edit" each component, then look at the properties (right click on the footprint on the right hand window of the component), to check the source lib for the footprint and symbol.
This is quite time consuming. I dont want the SOT23 symbol to be used from the SM lib that shipped with EPC, i only want symbols and footprints that are in my lib to be used.
Once i have done this, i will turn off all other libs except my own, so i can control them accordingly.
How do you know if a component has the footprint and symbol correctly ascioated with it, when is an error shown? When you add that component to a sch or a pcb, or when in the lib editor?! confused- please help.
Also, after exiting the lib editor, why isnt the lib dialog shown again? It disappears and i have to open it again each time (probably a setting somewhere i have missed? |
| Kruse |
Posted - 07 Jun 2011 : 11:12:42
I agree with you in Iain.
A component should contain info of which lib the schematic and each package originates from.
As it is now it just graps the first the best part with that particular name, what ever lib, it might be in and despite of which it was made form.
Even worse is that when you later on discover you have several components in your design that are actually another version that expected, you get trapped.
As A. Einstein said: "Keep it simple - but not simpler".
This is too simple. |
| Iain Wilkie |
Posted - 11 Apr 2011 : 16:39:34
Ok .... I'm kinda wth you on this in that if it definately means never picking up the wrong info then fine. However I still think the safer method is to store all in the component. Now I can understand that may change the whole format of the library system and could case other users problems with existing data etc, so how about being able to produce a new type of library which uses complete components that you can use (or not) ... surely this would mean that the existing system could stay for those who are happy with it, whereas otheres (like me) would prefer the "complete component" version. As all the data is the same when you pull in a component .. it just comes from one file or from 3 files.
Iain
|
| DavidM |
Posted - 11 Apr 2011 : 14:00:09
That was the main driver behind our current proposal, as it means you don't have to keep turning folders on and off. You can have the folders set up to access all the various sets of libraries you've got, without the chance of 'cross pollination' of symbols between one set and another.
David.
|
| Iain Wilkie |
Posted - 11 Apr 2011 : 13:43:16
Hi David,
I do understand .... what I was meaning was at the moment you need to manually move things into the correct folders BUT also you need to disable folders that are not needed and enable the ones you need. Thats really the problem ... is remembering to do all this at the moment.
Iain |
| DavidM |
Posted - 11 Apr 2011 : 11:03:10
Not sure if you have missed a key point here, that for such a 'locked' component library it would not use the library search folder list / order and hence would not 'accidentally' find a same-named symbol elsewhere in your library folders.
So if your Transistor.cml library in your IBM folder was 'locked' (or whatever we call it), adding a component to a design from that library won't find an SOT23 footprint from a library in your 'common' folder or your 'Rolls Royce' folder or anywhere else. It will only find that symbol from your IBM folder, possibly even only from your Transistor.psl if we decide to go as far as to lock it down to same-named library files.
So, this *is* a change from how it currently works, it isn't just automating what you can already do, it is a genuine attempt to propose an alteration to the software that should accommodate several different ways of working including yours.
David
|
| Iain Wilkie |
Posted - 09 Apr 2011 : 08:22:14
I can understand why this is being suggested as it means minimal change to the application.
This is because this can all be done at the moment if you do it manually. i.e. you can copy the symbols for a particular component into that components library and you can name the librarys accordingly .... in fact that is the way I am getting round these problems now.
The proposed method simply provides a more automated way. I can accept that this is a small step forward, however I still cannot understand why once a component has been constucted it cannot become a single entity containing all its design info and does not need to rely on particular libraries being present whenever it is re-used.
Very much like the completed files ..... when you open your pcb design files, they do not go searching libraries for all the components in the design, why ...because they are held totally within the design file.
I just feel its daft to construct a fixed entity but then not store it as such.
Iain
|
| DavidM |
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.
|
| johnt |
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
|
| Iain Wilkie |
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
|
| DavidM |
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.
|
| DavidM |
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.
|
| Iain Wilkie |
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
|
| KevL |
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 |
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 |
| TonyS |
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. |
| KevL |
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
|
| Iain Wilkie |
Posted - 11 Jan 2011 : 10:25:53
Kev,
This is the issue that raised the problem of the values being fixed to the footprint (and not the schematice.
http://www.numberone.com/forum/topic.asp?TOPIC_ID=510
Iain
|
| KevL |
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 |
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
|
| TonyS |
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 |
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
|
| Iain Wilkie |
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
|
| johnt |
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
|
| Peter Johnson |
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. |
| TonyS |
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). |
