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://email@example.com * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *