| Thread Previous • Date Previous • Date Next • Thread Next |
Could the schematic support multiple parts lists?I'm thinking of the problem supporting different builds say a European version or a US version where the schematic is the same but with component value changes due to, for example, 50Hz or 60Hz supply or the different voltages, regulations etc.
Simon On 16/12/2010 18:15, Dick Hollenbeck wrote:
On 12/16/2010 10:33 AM, Wayne Stambaugh wrote:On 12/16/2010 10:22 AM, Dick Hollenbeck wrote:On 12/16/2010 08:12 AM, Wayne Stambaugh wrote:On 12/16/2010 7:18 AM, Brian Sidebotham wrote:On 16 December 2010 02:31, Wayne Stambaugh<stambaughw@xxxxxxxxxxx> wrote:On 12/15/2010 9:19 PM, Karl Schmidt wrote:On 12/15/2010 07:30 PM, Brian Sidebotham wrote:When placing components such as passives (mainly R's and C's) you come across the common problem that you draw the symbol either horizontally or vertically. When you place the component it could be in one of four orientations, but generally it's either 0deg rot (horizontal) or 90deg rot (vertical).This is called Schematic symbol alternatives - usually you only need 2 versions (bridge circuits need a 45 makes 3 versions) - most CAD systems have this - and its nice. I added this to my wiki's wish list.This would this not be a feature in the schematic capture program? An excellent idea but I don't see it as a requirement of the part file or the part file editor. WayneIt does need a way of telling the schematic capture how to choose a look for a component. However, I think the functionality is allowed for in the current spec already. The different versions can be alternatives, then it is down to the GUI design to make these alternatives easy to select on a per-component instance basis which I'm sure is possible, and if I remember rightly desired by Jean-Pierre for large logic designs too for selecting deMorgan. So I think this is already covered, I hadn't thought about using alternatives for this in the part spec. This also covers different pinouts for processors that are available in different packages. The only thing not covered for me then would be one schematic pin to many footprint pins support. I can't see a nice way of doing that yet. It's only a nice-to-have anyway, and that's only my opinion which generally seems to differ from most others! ;)Conceptually its a merge action so the syntax would look like: (pin_merge PIN_LIST)The danger on the mailing list, or in any conversation, is not adequately reading or listening. This is not a bad idea. If we can have the above verb, i.e. "_merge" during parsing mean: 1) hide all pins but the first by toggling a flag in the pin C++ structure. 2) and control how the netlist is generated later Then you are done. The idea may actually be good after all. We need to avoid having to parse during DRAWING of the part, that would be a bad design, but I think we've steered clear of that with this option.Makes sense to me. The only question left to answer is do we limit pin merge to inherited parts only or do we allow it anywhere.If in the PART class, we support a list of lists: i.e. list of merge lists in binary form, then they can be carried forward in the PART::Inherit( PART* base ) function just fine from base parts. This function is essentially an application specific PART:: operator=() like function. It needs to copy all the pins, even onces hidden via merge in base, and the already parsed binary merge lists. PART::Format(?) should be do-able also, I will put some ideas into design.h soon on that. ================== Commas: not really used in s-expressions, got whitespace for separation of list elements. _______________________________________________ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@xxxxxxxxxxxxxxxxxxx Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
| Thread Previous • Date Previous • Date Next • Thread Next |
