At 01:03 PM 1/2/2002 -0500, Bob Wolfe wrote:
>OK Here is the scenario, I ran through this today.
>Hopefully I have described it clearly enough.

I think Mr Wolfe has been quite clear here; I assume he will correct me if 
I have misunderstood anything.

>I am running 99SE, SP6 on WIN98 Second Ed.
>Using the Database structure.

The "problem" he describes is generic to Protel. In fact, I find it 
difficult to understand any other way that the program could operate.

>Create 3 footprints called KP1, KP2, & KP3 that could be used for this
>part in a library,
>Create a part for a contact pattern for a keypad in a library.
>Part named "KEY"
>In that part I have defined KP1, KP2 & KP3 as legal footprints for that
>KP1 the 1st on the list then KP2, then KP3.

This *could* mean that KP1 would be the default footprint, used if no 
footprint were specified. Does it? We will see.

[... a moment of gratitude that I am now running with W2000, and I have two 
monitors, which means I can work full-screen in Protel while I write mail 
on the other monitor, and I have utterly no worries about running out of 
resources. Frankly, if W2000 cost ten times as much as it does, I would pay 
it to avoid going back to W98.... (W98 supports two monitors, but the 
resource problems are serious.)]

>I create a new schematic put these parts on it and connect them up.
>Then I annotate.
>Then I run update PCB.
>Once in the board I see that the footprint that came out on the board
>is the first one on the list (KP1) in the part in the library.

When I do what Mr. Wolfe described, I get an error macro: Footprint not 
found. This is because I did not assign a footprint to the part. The 
library gave me three options,  but I did not choose one of them, I merely 
placed the part as it came from the library. The footprint field was empty.

However, if, during placement, I hit the TAB key and choose a footprint, 
this footprint is automatically chosen for subsequent placements. Further, 
subsequent placements also chose the first footprint for other parts. I am 
testing this with a brand-new installation and there was apparently no 
default setting for footprint. Protel Schematic remembers the last symbol 
placed and presents it as a default for next placement, and this seems to 
activate the choice of the first footprint for all subsequent placements, 
even if the parts chosen are different. It's easy to see how a little 
sloppiness in program initialization could lead to this phenomenon, which 
is harmless.

Once Protel Schematic has been initialized by choosing a footprint during 
placement, the first footprint in the list will be chosen by default. At 
least this is what I saw. This is desired behavior.

>Later on at some point I need to change this footprint, I don't want the
>same name
>because it is physically different but I still want to keep the old
>even though I do not want it used for this part anymore.

>So I create the new footprint KP4 and edit the library for the part KEY
>to use only KP4 as a footprint, while both databases for board and library
>are open.

You cannot edit the library to control footprint assignments. The library 
only controls the list which is presented. Protel does not restrict you to 
four footprints, you can use any footprint you like. Footprint assignments 
are controlled from the schematic. Period.

Because the first footprint in the option list, which *is* from the 
library, will be chosen by default (usually), it may seem that you are 
controlling footprint from library, but you are really only controlling an 
option list, and the first footprint in that option list will, for 
convenience, is specially available for automatic choice. But this takes 
place in schematic and the footprint can be unconditionally changed in the 
schematic, what is in the library is *irrelevant.*

>While editing the part in library I select update schematic.

This will change the option list, nothing else.

>Save then go in to schematic, hit part properties and guess what the old
>footprint, KP1,
>is what is listed,

Yes. Exactly as expected. Changing a list of easy-choice options does not 
change the actual footprint chosen. You might have a footprint which is not 
on  the list! This is, in fact, very common. One would not want to lose 
footprint assignments because a user updated the part from library to 
change some aspect of symbol appearance, pin electrical characteristics, or 
the like.

>I can then select the arrow pulldown and see there is a choice for KP4 and
>once selected it now becomes the only choice for that part. But that means
>every unique part needs a global update, that's allot of needless work in my

Ahem... This only affects one single part, the one where the footprint 
option list was edited. This can be globally implemented with one single 
global edit. If you are going to your library and changing the footprint 
option list for each unique part, yes, you will also need to do a global 
edit for each unique part in schematic. (you could skip the library change 
and just edit the schematics, since it is not necessary that a footprint be 
in the option list, but if you want to make the new options available for 
subsequent schematics, yes, you will have to edit your library.

There are two different processes here, and it is easy to confuse them.

(1) Setting a footprint option list.
(2) Choosing a footprint for a particular part.

Because the same symbol might be used for *many* different parts requiring 
different footprints -- a PCB might have ten different kinds of 
nonpolarized capacitors -- there is no direct connection between the option 
list and the actual footprint chosen *except* that -- after some possible 
initialization confusion as described above -- the first footprint in the 
option list will be chosen by default.

This allows you, should you so desired, to set a different symbol for each 
type of capacitor. In that case, one would have a single option for 
footprint, and it would be routinely assigned. In the end, I suspect, this 
is more or less what we will get when we get true library control.

For most of us, however, at this point, we are glad to have the flexibility.

>Schematic Problem:
>Problem here is each unique part needs to be touched separately and then
>globally updated
>to REALLY change the footprint. Other wise the old footprint will get put on
>the board.

Yes. And this is not only the way Protel works, it is the way that it 
*must* work. Each footprint that is to be changed must be changed once. The 
only way to do less than this is to automatically change the footprint *and 
quite often the user would prefer to leave them as previously assigned.*

If we had control of the footprint from the library (which means one 
library symbol = one part, a huge step) then we would expect a library 
update to update the footprints. But we don't have that control. Instead 
the schematic is the command center.

Yes, "each unique part" needs to be touched separately. But if the parts 
share any characteristic, such as all having the same reference designator 
prefix, or the same original footprint, or anything else useable as a key 
for a global edit, then only one edit need be performed. Usually this will 
be the case. If not, then how would an automatic process decided what to 
change and what to change it to?

If you have one symbol = one footprint, then a global edit keyed to the 
symbol name will change all instances.

>And yes you could then change it in the board but why I already supposedly
>it in the schematic. Seems like allot of extra useless work.

No extra work is involved. Change it on the schematic and then update PCB. 
I find it difficult to imagine a simpler way. If this is a revision of an 
existing design, you will have some adjustments to make with tracks.

>In my opinion the update schematic function does not work properly, don't
>know whether Protel intends it to work this way or if it is a bug.

No bug has been described so far. The way it works is that one chooses or 
enters a footprint in the schematic and this is carried to the PCB. 
Alternatively, you can choose or change a footprint in PCB and carry it 
back to the schematic. If you have done the latter, especially, your 
footprints may bear little or no relationship to what is listed in the 
library. And this is how it should be unless there is a very serious 
library control system, something that we are not all eager to see.

I think it is a good idea in the long run, but there is a lot of work to 
get from here to there.

>You might as well not have this update feature if it will not change this
>data in the schematic
>globally for you automatically.

It seems to me that there is some serious conceptual glitch here. Update 
works exactly as I would want it to work. If Mr. Wolfe would want it to 
work another way, what would he want? He has not described how he would 
have update work. I suspect that if he takes the idea he has and reduces it 
to a specific and clear process description, he would discover that he 
would be creating more problems than he solved.

>Now for one or two parts this may not be that much extra work but if your
>library structure needs to change drastically this is a major issue.
>in a service bureau environment.

I work in a service bureau environment. For that very reason, I sometimes 
make a client library, which contains all parts used for a particular 
client. This can be done for schematic and PCB, and the make library 
commands make it easy to create these libraries.

If you are changing all your footprints, yes, you must not only touch each 
unique kind of part in your schematic, you must also *make a decision* with 
regard to each one. This is why the process cannot be automated.

Ultimately, I predict, we will see a library part which is essentially a 
manufacturer's part number. There will be a device for defining a series of 
such part numbers as being equivalent. The complete part number will 
include a manufacturer code, so the full part number will completely 
specify the part for purchasing purposes. Then there will be families of 
symbols and footprints assigned to each unique part. Yes, the part does not 
change, presumably, but we may want to represent it on a schematic in more 
than one way, and we may want to have wave-solder or reflow versions or 
maximum density or best manufacturability versions.

It will be possible to edit a technology option that would, for example, 
choose all the wave-solder footprints in one fell swoop. Another way to 
look at this would be that what is now four options would become many 
options, and the first set of these options would have defined names. So a 
global edit could manage changing the technology for a whole design.

With *this* kind of a system, we will not be talking about choosing 
footprints, except when we are just putzing around and want to put a 
"resistor" on a board and not worry about where it comes from. It will be 
made easy to do this, there will be generic parts.

There will be a web-accessible library that will contain *everything* one 
needs in the way of library parts. We may, as users, help to build this 
library; collectively, we can do a better job at lower cost than Altium 
could manage on its own.

>PCB Problem:
>Back to the part that calls out 3 footprints that can be used.
>"KEY" has all 3 footprints listed as legal footprints, and ALL 3 are in fact
>on a board.

Now, back to the schematic for a moment. Which ones should have been 
changed to KP4 when the update from library was run? My answer is "None." 
And that is how the program behaves.

>I go ahead and change the specific ones as needed to KP1, KP2 & KP3 in the

Yes, you can do that. Or you could change the ones you need to change on 
the schematic and update PCB.

>Now I realize I have to make some changes to many other parts in the
>library at some point. Which would then logically say that I would want
>to update footprints next time I run the synchronizer on this board.
>However what happens is ALL of the parts on the board that are "KEY" change
>back to KP1, which was the 1st one on the list in the part in the library.
>This is not a good thing in my mind.

Sure, it is not a good thing. It is not a good thing to change footprints 
on the PCB and then neglect to Update Schematic!

PCB: (Design/Update Schematic). This should change the footprints assigned 
in schematic to those used on the PCB. (Note that the PCB must be 
sychronized for this to work. I won't go into details on this at the 
moment, but the summary is that one must have run Update in the other 
direction. Turn off the footprint assignment options when doing this.) Once 
this has been done, running the synchronizer will only change footprints 
that have subsequently been changed in the schematic.


>One last statement, this all stems from my need & want to import an Orcad
>schematic with
>footprints names on the parts that I do not wish to use. Therefore I would
>thought the update schematic would have worked properly and forced the
>defined in my library to be placed on a new PCB.

Which footprints?

Here is what I think Mr. Wolfe is expecting. He has a schematic imported 
from OrCAD. The footprint assignments are next to useless.

He has created a project library from the schematic and wants to assign 
proper footprints. He does this in the library, by adding them to the 
option list. Then he wants these footprints to automatically show up in 
schematic when he runs Update Schematic from library. As I think I have 
shown, this behavior would create a huge mess with many designs which, I 
think, would represent the majority of situations.

Now, what would serve the needs of Mr. Wolfe and many of us in similar 
situations would be a small improvement to the Make Project Library 
command. When a project library is created, the assigned footprints are 
ignored. If there is an option list for a part (and there is no option 
list, I am pretty sure, with imported symbols), that option list will be 
used in making the library. But if one has merely assigned footprints to 
the parts in the schematic, the symbol in the project library will be 
without footprint options. If the project library creator were to examine 
the schematic and look for assigned footprints, it could take at least the 
first four it finds and stuff them into the footprint option fields. This 
would accomplish what Mr. Wolfe desires, I expect.

He has been writing about double work. The double work is in creating a 
matching library; most of us in his position simply do not create such a 
library except piecemeal and perhaps we never put *any* footprints in it. 
And then we have extra work that could be avoided.

Schematic has an ASCII database. It should be not too difficult, I'd think, 
to write a program that would create footprint options from the used 
footprints in a schematic. Once this is done, we could then make a project 
library that would include the used options for footprints, making all 
subsequent work for that client easier. I have written a simple schematic 
as ascii and have appended it to this post. A part from a Protel standard 
library called CON2 has been given four footprint options, as can be seen 
in the library section at the beginning of the file. Later, this part has 
been assigned a footprint of "0603". There is enough information here, in 
fact, to write the utility, though one might want to experiment with a few 
things. I'll do it if I have time. Perhaps I should have written "IF."

But it would certainly be useful.

>The PCB problem is less of an issue because I have just went ahead and made
>3 separate parts defining the 3 keypads so it will not rip them up when I
>need to
>update footprints during synchronization. But it still bugs me that the
>footprints do function as I would expect.

Once you have assigned the footprints in PCB, take them back to the 
schematic with the Update Schematic function.


[begin schematic, the first line begins with "Protel":

Protel for Windows - Schematic Capture Ascii File Version 1.2 - 2.0
      10 0 0 0 0 0 Times New Roman
      10 90 0 0 0 0 Times New Roman



         20 30
         Rectangle  0 -30 20 0 0 128 11599871 0 1
         Pin  0 0 4 0 1 0 20 0 -10 2 0 '1' '1'
         Pin  0 0 4 0 1 0 20 0 -20 2 0 '2' '2'

   0 0
Future  1 8 6
EndFuture  1
  0 6 0 1 1 0 15269887 1 10 1 10 1000 800 0
      PowerObject  2 150 260 1 128 0 'VCC'
      Wire  1 8388608 0 3 150 260 150 220 170 220
      Wire  1 8388608 0 2 170 230 150 230
      Junction  150 230 0 128 0
      Part  190 240 0 0 0 0 1 0 0 0 'CON2' '0402'
      Designator  190 240 0 8388608 1 0 0 'J?'
      PartType  190 200 0 8388608 1 0 0 'CON2'
      PartDescription  190 190 0 8388608 1 0 1 '*'
      PartDescription  190 180 0 8388608 1 0 1 '*'
      PartDescription  190 170 0 8388608 1 0 1 '*'
      PartDescription  190 160 0 8388608 1 0 1 '*'
      PartDescription  190 150 0 8388608 1 0 1 '*'
      PartDescription  190 140 0 8388608 1 0 1 '*'
      PartDescription  190 130 0 8388608 1 0 1 '*'
      PartDescription  190 120 0 8388608 1 0 1 '*'
      SheetPartFileName  190 30 0 8388608 1 0 1 '*'
      Part  210 290 0 0 0 0 1 0 0 0 'CON2' '0603'
      Designator  210 290 0 8388608 1 0 0 'J?'
      PartType  210 250 0 8388608 1 0 0 'CON2'
      PartDescription  210 240 0 8388608 1 0 1 '*'
      PartDescription  210 230 0 8388608 1 0 1 '*'
      PartDescription  210 220 0 8388608 1 0 1 '*'
      PartDescription  210 210 0 8388608 1 0 1 '*'
      PartDescription  210 200 0 8388608 1 0 1 '*'
      PartDescription  210 190 0 8388608 1 0 1 '*'
      PartDescription  210 180 0 8388608 1 0 1 '*'
      PartDescription  210 170 0 8388608 1 0 1 '*'
      SheetPartFileName  210 80 0 8388608 1 0 1 '*'
Version 2.0 Sheet
Part  11599871 128 0 0 0
      PartDescription  190 110 0 8388608 1 0 1 '*'
      PartDescription  190 100 0 8388608 1 0 1 '*'
      PartDescription  190 90 0 8388608 1 0 1 '*'
      PartDescription  190 80 0 8388608 1 0 1 '*'
      PartDescription  190 70 0 8388608 1 0 1 '*'
      PartDescription  190 60 0 8388608 1 0 1 '*'
      PartDescription  190 50 0 8388608 1 0 1 '*'
      PartDescription  190 40 0 8388608 1 0 1 '*'
Part  11599871 128 0 0 0
      PartDescription  210 160 0 8388608 1 0 1 '*'
      PartDescription  210 150 0 8388608 1 0 1 '*'
      PartDescription  210 140 0 8388608 1 0 1 '*'
      PartDescription  210 130 0 8388608 1 0 1 '*'
      PartDescription  210 120 0 8388608 1 0 1 '*'
      PartDescription  210 110 0 8388608 1 0 1 '*'
      PartDescription  210 100 0 8388608 1 0 1 '*'
      PartDescription  210 90 0 8388608 1 0 1 '*'
Library Version 2.0

1 4 4 20 0

Junction 0
Version 3.0 Sheet

Abdulrahman Lomax
Easthampton, Massachusetts USA

* * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
* To post a message: mailto:[EMAIL PROTECTED]
* To leave this list visit:
* Contact the list manager:
* Forum Guidelines Rules:
* Browse or Search previous postings:
* * * * * * * * * * * * * * * * * * * * * * * * * * * * * *

Reply via email to