Mr. Lomax Wrote, > Perhaps. Every change like this makes the problem more complex. Some people > are unhappy about increased complexity. It's a trade-off. Perhaps update > Schematic from PCB should generate a list of macros just like update in the > other direction does. This would be consistent. Then one could choose > whether or not to preview changes, or one could edit the change list if > desired.
Yup that would most likely do it at least for the case of already having a board, like you also said below. This way at least there is a choice to control that update a bit. But I still believe there should be a little more control choice Schematic to Board also. Just my opinion even though it may not be the majority. Robert M. Wolfe, C.I.D. [EMAIL PROTECTED] ----- Original Message ----- From: "Abd ul-Rahman Lomax" <[EMAIL PROTECTED]> To: "Protel EDA Forum" <[EMAIL PROTECTED]> Sent: Sunday, January 13, 2002 10:56 PM Subject: Re: [PEDA] Multisheet Problems & Updates etc. > At 12:25 PM 1/10/2002 -0500, Bob Wolfe wrote: > > >What I do really want though is on the schematic side. All I want is for the > >update schematic > >function to actually put the footprint name defined in the symbol that is in > >my master library into the schematic symbol and actually use that footprint > >on a new design. > > But that is exactly what it does (usually). The first footprint in the set > of up to four defined for a symbol is used by default when a new symbol is > placed. That's the behavior that I've seen. > > > As it works now if there is a symbol in the schematic with > >anything in the footprint field, if you update schematic any new footprint > >will not be used, that foot print stays there. > > Yes. That is not a new schematic. As has been pointed out, the footprint > choices in the symbol library are not controlling. > > > Then once it is in that > >design of course I don't want any automatic function removing or changing it > >unless I really need to change that particular footprint either by an all > >footprint update with synchronizer or individual update using PCB Update > >from library, or just putting any other footprint you want in there. > > > >I just think a little more control needs to be added to the update > >capability. I just have a problem with > >the fact that I ran a function that supposedly should update a symbol in a > >schematic with data from > >a symbol in the library. > > It does. It just does not update the footprint, for the reasons which have > been amply explained. The *choices* in the footprint are not *data*, that > is, they are unrealized. An existing part in a schematic has *data*. Data > should not be overridden by one of a set of choices, it has already > presumably been chosen. > > > I see that doing things on the fly in the PCB like > >changing a footprint then updating schematic from that source, your saying > >you would not want a library update to a symbol in the schematic to change > >that footprint on you. > > Right. And there seems to be wide agreement on this. > > > I just think the way the system does update you will > >have a problem with this. I would think there could easily be a choice here > >to either append or replece data in a symbol during update. That could keep > >everybody happy no matter where the source of > >the update comes from. > > Perhaps. Every change like this makes the problem more complex. Some people > are unhappy about increased complexity. It's a trade-off. Perhaps update > Schematic from PCB should generate a list of macros just like update in the > other direction does. This would be consistent. Then one could choose > whether or not to preview changes, or one could edit the change list if > desired. > > [EMAIL PROTECTED] > Abdulrahman Lomax > Easthampton, Massachusetts USA > > * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * To post a message: mailto:[EMAIL PROTECTED] * * To leave this list visit: * http://www.techservinc.com/protelusers/leave.html * * Contact the list manager: * mailto:[EMAIL PROTECTED] * * Forum Guidelines Rules: * http://www.techservinc.com/protelusers/forumrules.html * * Browse or Search previous postings: * http://www.mail-archive.com/[email protected] * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
