Brad,

The following may meander a little from the basic problem you are
describing, but I think it is nonetheless directly relevant, and actually
address the problem in an indirect way.

It sounds like Protel suffers from the same problem that many, if not most,
of these EDA software systems do, in that, the manner in which the internal
databases store information is in most cases what I call "Entry Order
Driven", that is, that the first part entered in the design stays at the top
of the database list (and any subsequent parts of the same type may (or may
not) get put up there with it), and that all connections are put in their
own little database list in the order in which they were entered, etc.,
etc., etc., and that all of these entries in all of the different internal
databases never loose their original position in the internal database list,
or are moved from their original "Entry Order", unless possibly it is to
sort them by some other parameter that is totally unrelated to the actual
electrical design, such as the part number of the devices, or the footprint
type of the devices, or the physical length of the actual connection line on
the physical schematic, etc., etc., etc., which is again, totally unrelated
to the electrical function of the schematic.

This is why most "Auto Placement" schemes do not work, since they too are
"Entry Order Driven", and internally work off of the same "Entry Order"
internal database lists, which cause them to do stupid things like place all
of the "pull up resistors" of the same value first because the first part
that the engineer put in the original schematic was a "pull up resistor" of
that vakue, which he subsequently copied all over the schematic, an hence
caused to be at the top of the "Entry Order List".

This same problem appears in "net numbering", in that many times the nets
are numbered and processed and laid out in the same "Entry Order" that they
were originally entered into the internal database, which is why
"Priorities" get all screwed up in "Routing " the Board, because the basic
"Entry Order" will never change.

Of course you can cause several subsequent "Sorts" of these internal
databases, when you do things like assign certain parts or nets to certain
"Classes", or certain areas or sheets of a schematic to certain "Rooms", or
assign a certain "Width" to a certain net, of place certain parts on a
specific side of the Board, all of which break down the original "Entry
Order" internal database lists to even more "Entry Order" database lists,
but which nonetheless still somehow never seem to loose their "Entry Order".
Of course the Protel software further alters these "Entry Order Lists" into
yet again different "Entry Order Lists", and yet in some senses, certain
things within these internal databases will never loose their "Entry Order".

Years ago I found out that "Dasix" (which was originally Cadnetix, and then
became InterGraph, and then became VeryBest, and is now Mentor Expidition)
"Compiled" ("Linked") its Hierarchical Schematic Pages or "Sheets" based on
the physical order in which it encountered the actual subdirectory of each
"Sheet" on the physical disk drive, and that if you edited a "Sheet" for any
reason, such as changing a netname, that it created a new copy of the
"Sheet", which really meant creating a new subdirectory on the physical hard
drive, usually at the end of the available disk space, and only when you
finished editing the new "Sheet" did you actually end up deleting the old
copy (or previous backup) of the old "Sheet", thereby deleting its
corresponding subdirectory, and "freeing up" a physical slot on the hard
drive (and its directory) so that you could further sort and scramble the
physical location of the next "Sheet" that you edited.

Today, virtually everything that you look at in terms of a listing of files
on your computer, is "Sorted", either alphabetically or by some other
parameter such as file type or something else, before it is listed on your
display and actually presented to you (even the LS command in Unix or Linex
sorts the directory before it is displayed). The one possible exception to
this is a directory listing (the "dir" command) in MSDOS (or the "Command
Prompt" on some newer versions of Windows), which will present files in an
unsorted manner in which they are physically located (listed) in the actual
directory (or subdirectory) on the actual hard disk. If you look at this
type of "list" you will begin to understand the scope of this problem

Thus in "Dasix", every time that you edited a schematic "Sheet" in your
design, and then "re-Compiled" ("re-Linked") your entire design, you got a
completely different netlist, because it physically encountered each
"Sheet's" subdirectory in a new and different location or physical "Entry
Order" on the hard disk as it was "Compiling" ("Linking").

This may sound dumb, and even stupid, and in fact it really is, but that is
the way that these simple and stupid software systems work at the bottom
level of their software designs.

Back in about 1988 or 89 I had a friend who I worked with at Datatape, and
he spent his day compiling complex FutureNet designs for Xilink parts, which
would take hours at a time to compile, and never route to completion, and
after each compile he would delete a few insignificant parts, and cycle the
schematic, and then re-enter the same parts and connections just as they
were, just to re-order the internal database lists, and then he would
re-compile the same design, which would ultimately route to completion after
repeating the cycle for several times, if not for several days. He would
then repeat the process two or three more times again after he had routed to
completion, just to try and get a little better final route for the design.
Sometimes this is what you have to do to get a stupid piece of software to
dance to the tune that you want it to.

Do you think that Protel is any different than any of these earlier systems
in its basic design?

We have faster computers with faster processors and oodles of megabytes of
memory, and better displays with a gazillion colors, and much more complex
functions "pre-done" in terms of functions or subroutines or "system calls"
or "operating system procedures", etc., etc., etc., all of which make it
possible to do something easier and faster, but basically, it's the "same
ol' same ol' " thing that we were doing twenty years ago, with a few more
requirements and a few more features and a few more "bells and whistles",
all of which still do not quite work the way that they should.

You have to remember that the computer in front of you on which you run
Protel is just a dumb and stupid little box that can only do a couple of
hundred different dumb and stupid little instructions like moves and
compares and calculations, by which it is programmed to perform slightly
larger tasks, and that even those simple tasks are dumb and stupid, and only
become useful by their amazing speed and repetition of those simple little
tasks which ultimately allow them to perform large functions, like screw up
a schematic in Protel.

The same old problem is that the databases in Protel are simply a bunch of
databases containing "Entry Order Lists", and the different "routines" in
Protel simply perform hundreds if not thousands of simple yet specific
different little "tasks" on each of the many different little "Entry Order"
database lists to ultimately transform all of those original "Entry Order"
database lists into yet many new and different kinds of "Entry Order"
database lists, which can be used to perform different specific functions,
such as graphically display lines and circles of different sizes, and
locations, and colors on your display, or print them on your printer, or
output them as an yet another list, which to some extent is yet just another
"Entry Order List" called a Gerber file.

This is why I SHOUT AND YELL AND SCREAM and rant and rave about the people
at Altuim / Protel needing to not only understand how to program software,
but also understand the design process and the electronics industry in which
the end product on which they are working is used. You would be amazed how
much better a product can be when the people programming it not only know
how to program, but also know how to draw a schematic and at least know a
little bit about the basic operation of what the
schematic represents and how the circuits flows. Yeah, I know, sadly that's
even too much to ask of most designers, let alone programmers. Oh well.

Brad, the simple answer may just be to delete R15, R16, R17, and R18 (and
and any other of their counterpart), from the schematic, cycle the design a
few times , and then re-enter them. Then they may actually renumber where
you think they should, but then again, you will have now screwed up all of
the connections to those parts, which are now going to be at the bottom of
the list for lines and connections, and hence nets.

Oh Well, I think that you will at least begin to see the scope of the
problem.

Actually, why don't you try manually numbering them to be what you want, and
then "Updating", and  then "Annotating" again.

Needless to say, I could ramble on about this for days and weeks and months,
and as a result get so upset as to even maybe write a program to do it right
myself, just to calm down again.

Enough for now.

JaMi

----- Original Message -----
From: "Brad Velander" <[EMAIL PROTECTED]>
To: "Protel EDA Forum List Server (E-mail)" <[EMAIL PROTECTED]>
Sent: Monday, March 03, 2003 3:29 PM
Subject: [PEDA] P99SE Annotate component sorting order.


Hi all,
this is an issue that I am sure has been around a while. On this design I am
working it has just become too much for me to accept, is there something I
am missing or a work around?
Trying to annotate a two page schematic it keeps pre-sorting and ordering
it's annotate based on the part type information. It is not simply using the
part type information for matching purposes, it is doing matched part type
designator assignments first.
For example, here is what I am seeing.

I have a bunch of resistors on page two of the schematic. They are being
numbered R38, R39, R40, R42, etc. sorted according to the specified annotate
pattern. Then the next resistor may be R15. A short number of resistors
follow the original number pattern R43, R44, R45. Then I get another one
R16! The part type data of the R16 is the same as R15 and is different than
all the other mentioned resistors. On the same page I noted some resistors
of the same value/part type information that were numbered R17 & R18 even
though the other resistors around them are numbered in the 50s.

What P99SE is doing is annotating according to the specified pattern only
when it finds a part type that was not previously matched by the part type.
Parts with matching part types get annotated in the order that the first
component of that value was found on the first page of the schematic, then
it purposely searches out parts with the same part type to annotate next in
sequence even across other schematic pages.

On my configuration for annotating I do have the "Group parts together if
matched by:" set to part type. However this is only for grouping multipart
symbols, is it not? Matching multiple parts from a single package? Or am I
carrying old baggage from OrCAD or other packages, the Help file agrees with
me though?

Sincerely,
Brad Velander.

Lead PCB Designer
Norsat International Inc.
Microwave Products
Tel   (604) 292-9089 (direct line)
Fax  (604) 292-9010
email: [EMAIL PROTECTED]
http://www.norsat.com




* * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
* 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]
* * * * * * * * * * * * * * * * * * * * * * * * * * * * * *

Reply via email to