At 06:33 PM 1/31/2002 +1100, Ian Wilson wrote:
>On 01:22 AM 31/01/2002 -0500, Abd ul-Rahman Lomax said:
>
>>Sure, GUIDs would make for reliable matches, but at the cost of severe 
>>inflexibility, in my view. If I have a schematic with a 10K resistor R25 
>>on it, and I delete that resistors. Then I think better and replace it. 
>>The GUID is now different, isn't it? But *I would want any spreadsheet 
>>update to be able to work on R25 across this process*.
>
>I wouldn't - it is a different resistor, just so happens that one 
>attribute is the same (designator).  I hate designators being special - 
>one of the best things about the synchroniser is that it does not rely on 
>designator except for initial match.

It is not only one attribute that it is the same, it is the same value, it 
is in the same location, and it has the same connectivity. It is -- ahem -- 
pedantic to claim that it is different simply because of its *history*. The 
PCB will not care about history. The technician working on the board five 
years down the road will not care about history.

(History is not completely irrelevant if we get some kind of library 
control. But it is only relevant in that we may want to be able to control 
what parts are used and to ensure that the most recent version is being 
used, or if it isn't, we want to know why. It is not relevant for the 
purposes of this discussion. It only becomes relevant if a unique GUID is 
assigned, i.e., the relevance would be an artifact of how the program 
works, not of what we want to accomplish.)

>But I will grant this - Undo should re-instate the previous GUID rather 
>than create a new one.

If there is a GUID, yes, Undo should recover the old GUID. But it is an 
artificial restriction that Undo must take place in a single schematic 
session. Which leads me to a long-time wish: complete edit files, that 
record every change made to a file, such that a playback machine could redo 
all these changes starting from the same original file. This would have 
*lots* of applications. It could be part of a tutorial. It could be used 
for crash recovery if properly implemented (i.e., up to the command which 
caused the crash). It could be used to identify bugs more quickly.

But replacing a resistor with another resistor of the same refdes and 
symbol and connected the same way should produce *exactly* the same 
results. And this is where GUID falls down. If the program ends up behaving 
as if the resistor is different when everything but the GUID is the same, 
that's a problem.

Mr. Wilson doesn't like the specialness of reference designators, and it is 
easy to see why. But the problems of this only result from the fact that 
reference designators can be changed or never made unique in the first 
place. Absent this, they *are* the original unique identifier. This is one 
reason why I am generally prejudiced against renumbering based on PCB 
location, all earlier documentation gets scrambled. Yes, techs like to be 
able to quickly find a part on the board, but almost as often, we (yes, I 
was a tech) want to be able to find a part on the schematic. It is much 
better to give techs good cross-reference information, such as location 
coordinates, than to depend on reference designator sequence, which often 
fails anyway, especially one dense SMT boards where there is no room for 
designators.

The simplest thing to give the tech are the CAD files, which is one reason 
why we want file readers. Come on Altium, you did it in the past with 
Protel v. 2, all it takes is a little work with the demo, so that it 
expires into a demo reader instead of going completely south. We don't want 
to pay for a full license for the technician, that simply is not going to 
happen, it is far too expensive. In larger companies, he might get a 
floating seat, but I think that would be relatively rare.

Ahem, where were we?

>>Okay, persistent handles could be another possible method of linking. My 
>>point has been that relying on handles for linking is inflexible.
>
>Precisely, inflexible but precise.

Yes, but they would be precise in preserving irrelevant distinctions.

>   This is almost always what I want as I am almost *never* taking in 
> external data.  It is almost always exported twiddle (possibly using 
> external sources) and then updated.  I would suggest that this is the 
> most common use of spread export/import at least for the engineering 
> design community.  That may differ from the contract PCB design community 
> where external data is more common.

Yes. However, the kinds of import I do would happen if I were the engineer 
as well. It's just that I'm not going to do the kind of optical analysis 
necessary to locate the parts on the complex board I've been assigned, it 
takes $40K worth of software and more than that to drive the software. This 
generates a list of component center positions. About 4000 of them. The 
need to import comes from the nature of the work, not from the fact that it 
is three or four different people doing it.

>>  But handles, if they exist, could be useful, just as they could produce 
>> incorrect results (like any of the other methods). For example, I have 
>> two resistors, 1K and 10K. The engineer says, swap them. So I pick them 
>> up and move them. Then the engineer says, oops, swap them back. So I 
>> edit the 10K to 1K and the 1K to 10K.
>
>I do not consider this incorrect, on the contrary - if I have a strict 
>company part numbering scheme and the Sch feeds back into a complete MRP 
>system then what I want is a unique number that I can track changes and 
>deletions.  Designator no longer cuts it.  We spend a bucket of time on 
>configuration control.  Unique component numbers would suit me really 
>well.  Already an increasing number of designs we do (both internal and 
>external clients) use the "one manufacturers part number one SchLib part" 
>library system.  So the issue of simply changing the value of a component 
>is not on.  I am hoping that the next version of Protel may in fact allow 
>every component attribute to be locked at the library level (apart from 
>designator).

We generally agree on the need for library control and what it implies. But 
I will still stand with my comment that the history of how a component came 
to be in a place is irrelevant, beyond the library control question -- 
which is a red herring here. *Symbols* should have GUIDs. That's necessary 
for library control.

>In the above scenario, the correct manner of dealing with a component 
>value change is to copy a correct value part of the sch or to place a new 
>one of the correct value.  or more sensibly to swap the components back 
>(in your example).  This may seem like more work to the person laying out 
>the Sch but the back end work reduced can be enormous - especially once a 
>design is under ECN control. Once under ECN, a designator change can be a 
>huge undertaking.  In some companies I have seen standards that disallow 
>the reuse of designators to prevent the reduce the chance that a old 
>iteration part list is used, so causing a wrong value to be fitted.

I think Mr. Wilson has missed the point. I got to the same result by two 
different means (I may not have stated the example completely correctly). 
The "same result" could mean that the PCB resulting would be identical, 
that is, a PCB created from one of the schematics would not necessitate any 
macros when updated from the second. It is another step beyond that to be 
able to link, to demonstrate and use identity, if *relatively* arbitrary 
information such as reference designator has been changed. I definitely 
don't want GUID to be another level of arbitrary -- now fully arbitrary -- 
information standing in the way. As a helpful means of linking, fine. As 
the only means of linking, as a necessary means, no, not fine, a nuisance.

>The increase in rigor required at the front end directly reduces the scope 
>for configuration control errors later (at which time they cost more and 
>are harder to fix).  So the forced reliance of strict matching can help to 
>reduce the human element.  But I can still sort my spreadsheet and not 
>include all the columns - which will cause some interesting changes.. (but 
>ones that will be detected in the back end database systems that will 
>detect masses of invalid value changes etc).

I think Mr. Wilson might have been better in the OrCAD saddle. Sorry, that 
could be considered rude, I wouldn't say it if he weren't my good friend. 
OrCAD forces you to do many things the OrCAD Way, one of the more 
frustrating experiences in my life. On of the advantages of Protel is that 
it provides many ways to the same end, you can pick which one works best in 
your situation.

In general, I agree with the need for discipline in design, particularly at 
the schematic level. Clean schematics are often an unrealized dream of the 
PCB designer. I'm working on a schematic now where the one who drew the 
schematic took the pin-out diagrams used by the engineer and used generic 
symbols for them, so, for example, there is a generic 8-pin symbol which 
can be used for any part coming in a DIP-8 or SO-8 or similar package. The 
pins are all passive in this symbol, if I'm lucky (some are randomly 
scattered among the electrical attributes). It is no wonder, then, that ERC 
reports all kinds of problems. A board designed from this schematic might 
even work, providing that the engineer put extra work into manually 
checking the schematic.

But it's not the way to do things. I've redrawn these symbols to match the 
actual parts, with inputs on the left and outputs on the right and power 
pins appropriately placed, and I redrew the schematic to be a proper 
hierarchical schematic with Port and Sheet Entry connectivity, which forces 
intersheet connection to be explicit. The schematic now ERCs with no errors 
or warnings. In the process, I identified a whole series of unused ports on 
the microprocessor, which may help future engineering on this project, plus 
the redundancy of several parts was uncovered, since it now became easy to 
see how the parts functioned.

The original designer cut corners. He was charging by the hour, so the 
client, it might seem, saved money, and, to be fair to the designer, the 
engineer accepted the work. But that engineer is very polite. In reality, I 
should have been paying more attention, the designer was working for me. 
He's actually an engineer himself, his PCBs are excellent, functionally, 
and we had no standards in place to keep him from doing what he did. I 
might have done the same thing myself had I been in a huge hurry.

>How does this relate to the point under discussion?  For us we have almost 
>no external data that can not easily be merged into an exported spreadsheet.
>
>So any solution that does not allow for *forced strict* matching would be 
>a potential hole in our configuration control system.  So any other option 
>for matching would be an option we would probably rarely use that we would 
>want to be able to disable.  (This raises the idea of Admin driven design 
>options and tool configuration.)

I'd like to be able to take a list of reference designators and make 
changes on the corresponding schematic parts through spreadsheet. That is a 
routine operation, actually. The way to do it now is to create the handles 
by exporting the spreadsheet, then one pastes the new data into the 
spreadsheet and updates it. This is a process completely dependent upon 
making a whole series of actions exactly in the correct way. It 
*effectively* depends on reference designator matching to link, the handles 
are simply a means. I'd like to see a way of doing it more directly. I.e., 
a spreadsheet import done without requiring an initial export whose only 
purpose is to create the handles and which must then be used in exactly the 
right way, no mistakes allowed or it crashes, in order to get the data back in.

So what I would see is a data import wizard. You feed it a spreadsheet and 
an identified schematic or project. You select a key field or fields, the 
most common would be reference designator, but there would be others. You 
then select fields to be imported and match them to schematic fields. Press 
Update and you are done. The program notifies you of any match errors or it 
dumps this data to a report.

I used MYOB, an Australian accounting program, for my wife's business. It 
does data import in this way. Nice feature, one of the reasons I bought the 
program.

Now, for a new form of keying, I'm suggesting connectivity keying. Exactly 
how it would work is not completely clear to me. It would be used to link 
schematics to other schematics, perhaps to come up with a list of *real* 
differences. It could be used to relink schematics and PCBs where one of 
them has been reannotated and the hidden links have been lost, a situation 
which is, at present, one small step short of complete disaster, requiring 
some serious workarounds and possibly quite a bit of manual labor to 
recover. With connectivity keying, it would be pretty simple.

>One point we have not addressed, yet, is that currently any entity can be 
>exported and modified in the spreadsheet and then updated.  the bloat from 
>a GUID attached to every entity could become significant, I will accept that.
>
>We are definitely coming at it from very different viewpoints.  It is now 
>Protel's problem to think about all this and to distill it into realizable 
>and useful implementation (assuming they haven't already done much of this 
>and assuming they think any of it is a good idea.)

What we really need is more interaction with Protel engineering. Right now 
it happens mostly at the PCB Design Conference shows. We might have a 
bright idea and engineering thinks it stinks. Or vice versa. In that 
situation, *both* of us are wrong in some way or other, and we will only 
come to a good solution if we can find out why each of us thinks 
differently and address the issues which are raised. It might be that we 
have not been understood. It might be that we overlooked something but 
there is a way to deal with that.

With only one-way communication, the status quo, Protel software 
engineering is like a runner with one foot tied up behind his back. Yes, he 
can hop along, and he might even be faster than all the other runners, but 
what if he could be unhobbled?

Why is he hobbled in the first place?

History. First of all, the kind of communication that is now possible was 
not possible some years back. Secondly, there is an idea that software 
engineering has to be a big secret.

As to the second matter, there may be a case for this, at least it deserves 
consideration. I know for a fact that Protel's real long-term competition 
(Cadence) reads this list, and they read it carefully. Several top Cadence 
executives have recognized me immediately from my name tag and I've even 
received fan mail from one of them. It may or may not be a coincidence that 
not long after this, Cadence announced a strong working relationship with 
the Specctra user group.

But I think that the losses from much secrecy outweigh the gains. It only 
seems useful if everyone is equally hobbled. One thing is clear to me: the 
secrecy does not serve *us*, the users, and every dollar that ends up in 
the hands of Altium through Protel sales comes from us. In the long run, 
that company which best serves its customers will be the most successful. 
I'm not denying that there are other factors, only that this is the single 
largest one. (And one must understand that it is not good service to price 
a product too low, since the continued availability of the product depends 
on sound pricing.)



Alitum has an historic opportunity here. I hope they don't pass it up.

[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/proteledaforum@techservinc.com
* * * * * * * * * * * * * * * * * * * * * * * * * * * * * *

Reply via email to