Re: [PEDA] Fw: Altium - Think it, Design it, Build it!
Here is my reaction to Altium. I am rather desperately hoping it is a hoax Altium sounds like a name for a company that is trying to imitate something modern without quite making it. It's very nineties. * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * To post a message: mailto:[EMAIL PROTECTED] * * To leave this list visit: * http://www.techservinc.com/protelusers/leave.html * - or email - * mailto:[EMAIL PROTECTED]?body=leave%20proteledaforum * * Contact the list manager: * mailto:[EMAIL PROTECTED] * * Browse or Search previous postings: * http://www.mail-archive.com/proteledaforum@techservinc.com * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
Re: [PEDA] Spam trawlers in this group
At 11:13 AM 8/24/01 -0500, Frank Gilley wrote: Just curious, but lately I have been getting spammed from what would appear to be email addy trawlers in this group. Anyone else getting spam from .au's? after posting here? This is not the usenet, surely we don't have to have addy trawlers in our own group! Either that or Altuim sold our addresses... (surely NOT!) Who would buy what they can get for free! (As was pointed out, Altium has no special access to the addresses of subscribers to this list; that data is held by Techserv. I very much doubt that Techserv would sell the subscriber list. They do offer advertising to the list -- no one has purchased it, it was pretty expensive last time I checked; but such mail would come as a normal post to the list.) However, this list is archived on yahoogroups. If you one's e-mail address is in the signature, it becomes web-accessible, and Mr. Gilley does have his address in his signature. There is also a Techserv archive -- on the Techserv web site, and it happens that a piece of mail from Mr. Gilley is in that archive; I found it by searching google.com on his e-mail address. This list sends the email address of writers with posts. But both the Techserv archive and the yahoogroups archive (protel-users-PEDA-archive) strip out the addresses. So the email address is only publicly viewable if you put it in the body of the mail or it is in your signature. So anyone could search for messages containing terms that might indicate that a writer was a potential customer, and then extract the e-mail address(es) from those messages. I get *lots* of spam, because I don't conceal or disguise my address, and I am active, not only here, but on newsgroups as well. * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * To post a message: mailto:[EMAIL PROTECTED] * * To leave this list visit: * http://www.techservinc.com/protelusers/leave.html * - or email - * mailto:[EMAIL PROTECTED]?body=leave%20proteledaforum * * Contact the list manager: * mailto:[EMAIL PROTECTED] * * Browse or Search previous postings: * http://www.mail-archive.com/proteledaforum@techservinc.com * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
Re: [PEDA] Altium Total Support Brochure
At 03:13 PM 12/5/2001 -0500, Brian Guralnick wrote: Usually when I purchase any software, or hardware, from any other vendor, I can get support for free almost indefinitely without having to renew some sort of membership. Actually, indefinite support is, in my experience, the exception rather than the rule. We are all using one of the Microsoft operating systems. As I recall, free support for that is limited to a few months from first contact. My wife's business uses a very common accounting program, support is free for a few months, after that it is pretty expensive. And all the other major CAD vendors charge plenty for support. Protel was an exception. While I am concerned that the ATS charge seems high compared to the software purchase price, we don't really know where that price is going to settle. I am much more concerned about all the confusion that comes from uncertainty about where all this is going; supposedly on of the purposes of ATS is to make it easy to budget. Hey! It's not easy yet! I'm hearing reports of users bailing or at least researching alternatives. I'm trying to figure out why all the secrecy and mystery. Obviously, a company needs to preserve some flexibility, and when there is a sale, there is always the customer who bought just before the sale who is irritated. If a sale were announced in advance, obviously purchasers would wait unless they absolutely had to have it TODAY. So the company might as well announce the sale immediately. Sometimes, however, companies will issue a credit to purchasers who bought just before a sale was announced. If a sale involves a small savings, it is not very important, but 20%, What my wife has done in her business has been to issue a credit to the customer against future purchases. Companies have sales to jumpstart cash flow or move inventory. The latter motivation is not particularly relevant to the software industry. By issuing a credit instead of making a refund, the customer is kept happy and immediately cash flow is not negatively impacted. Altium did this to a small degree with the ATS announcement. It was back-dated about a month, as I recall. One buyer wrote about missing the deadline by a day or two. We don't yet know the impact of that, because we don't yet know the true value of ATS, we only know what upgrades *including* ATS are costing. It seems pretty unlikely that a P98 upgrader is getting the upgrade free and ATS for $1995. We had been expecting the next upgrade to be $995 or so. Protel, for the last few years, has only had modest sales, i.e. price reductions, and it is sudden price reductions that get buyers angry if they missed them. Instead, Protel has announced price *increases* well in advance. This has a similar effect to a sale in that it will stimulate fence-sitters to make a purchase decision, but it does not cause any ill will. Anyway, it is obvious that if a company needs to lower a price temporarily (or permanently), or offer some extra substantial benefit, which amounts to the same thing, it must announce it on a certain date. Those who buy before that date may just be out of luck unless the company accomodates them in some way. I'd suggest a certain period before the sale date where those who purchased within that period get some benefit, not as great as the sale benefit or price reduction, but something that makes the difference not so drastic. For example, Protel 99SE purchasers in the three months prior to October 1 might get ATS at half price if they buy it within, say, three months of the ATS for pre-10/01 licensees announcement. This will not only mollify them but it may actually stimulate ATS sales for that group As to those of us who bought Protel even before that, we have had the use of the program, which is probably worth a few hundred dollars a month, at least for serious users. * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * 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 * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
Re: [PEDA] Altium Total Support Brochure
At 03:51 PM 12/5/2001 -0500, Bagotronix Tech Support wrote: I think that free support should be maintained for old products forever, as long as there is no cost associated with maintaining that free support. No cost support is possible. It consists of downloadable service packs for the software, FAQs, bug lists, and workarounds, all on the company's website. I understand that they cannot offer free telephone or e-mail support forever, but website support they can. I agree. A year or so ago, I bought a Compaq notebook computer from a close-out distributor. They told me that I could get the manual from Compaq. So I went to the Compaq web site and found that Compaq had arranged with a company which provided manuals. For about $50, I think. It might have been $100. The PDF manual had been removed from the Compaq site. I returned the computer and find myself very reluctant to consider Compaq computers. Sure, they probably made some money selling the rights to the manuals. But, essentially, they sold out their customers, because only customers need those manuals, perhaps it was lost or damaged. Because all of the development cost for the manuals was absorbed into the cost for the computer, getting some money for the ongoing rights to publish the manual probably seemed like free money to the Compaq bean counters. As they say, penny-wise, pound foolish. Almost every manual sold by that company will generate a jolt of ill-will against Compaq. People know, by now, that documentation costs are included in the product cost, and with the web, the cost of distributing it has become very very low. If I lose my Protel manual, no big deal, I can get the PDF. Protel sells the book for $90. Given the press run, that's probably a fair price. But I certainly hope that Protel doesn't decide to dump the PDF on the theory that it could then sell more manuals * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * 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 * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
Re: [PEDA] Footprint pads moving during or after copy/paste/move processes.
At 06:05 PM 4/1/2002 +1000, Ian Wilson wrote: Harmless unless you actually have unlocked the component - and then the classic missing pad can be generated. Select a net (or connected copper), which includes components with unlocked primitives. Delete the selection and away go the pads. This is a problem and it would be nice if Protel gave a warning that component entities were about to be deleted/moved by this action. Yes. Absent such a warning, we should be vigilant whenever unlocking component primitives that they are relocked immediately when it is no longer necessary to have them unlocked. (Major purpose for unlocking primitives: to modify a silkscreen outline, for example to be able to read designator text which overlaps the outline; this is one way to get tighter legends with SMT parts.) * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * 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 * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
Re: [PEDA] pad jump
At 03:11 PM 4/1/2002 -0800, Dennis Saputelli wrote: i am reasonable certain that my mysterious pad jump happened right after and as a possible consequence of a File Save As It would be rather surprising if that was not merely a coincidence. File Save As does not have any effect on the file itself, which remains in memory unchanged. Exceptions would be the edit flag, which is cleared, i.e., Protel knows that the file has been saved since it was last edited, and the file name, which is changed to the new name as the file is saved under that. It would be pretty hard to get this one wrong. But I suppose stranger things have happened. I'm not convinced that I have seen sufficient confirmation of this bug report to consider it verified. There simply is no coherence of conditions as yet. What we have is a report, confirmed by some, that they have seen pad footprints move; I don't think that any have reported that this was at all frequent. Since pad footprints can move by a number of normal processes, plus they could move from database corruption from any of many different possible causes, I would want to see either (1) many confirmations, or (2) confirmation with some similarity in the conditions under which the pad jump was observed. Mr. Saputelli has sworn up and down that he didn't do any of the things that would normally cause supposedly locked footprint pads to move, but he can't possibly know that his computer did not suffer the alteration of a bit, perhaps by a cosmic ray I'm *not* saying that it is unlikely that such a bug exists. I don't think Save As is likely to be related, but there are plenty of other things that could go wrong. If any of our readers observe pad jump, i.e., you are sure that you did not unlock the primitives of a component and that you did not edit the coordinates, perhaps thinking you were editing a track width, by all means, report it here, together with a description of what you were doing at the time; also the X,Y magnitude of the jump would be interesting. You should be able to determine the exact change in X and Y coordinates by noting the new coordinates, then replacing the component from its library * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * 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 * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
Re: [PEDA] Out-of-workspace items (ex Extended selection spells)
At 12:43 AM 4/3/2002 +1000, Geoff Harland wrote: I understand what you are saying, but I do wonder how much space you want while you are moving items about; after all, 100 inches by 100 inches is a pretty big area :) (i.e. much much larger than any PCB which I am ever likely to be called upon to design). The issue is not the size of the workspace, though if one were working at a finer scale, for example 10:1, that 100 inch workspace could becomoe a tad tight. Why would one want to work at scale? Well, Protel gets a little flakey somewhere in the micron region; definitely CAMtastic does. I have run into these limits on an MCM design, 2 mil track and space with certain structures needing to be a specific size and shape. Protel did generally work here, and gerber provides adequate resolution, but CAMtastic was useless, it seems to have been designed for the mil region, not much below. I've worked with Tango DOS, which had a 32 inch workspace; I never had occasion to need larger. But I recall my frustration when I could not place a block because some element of the block was outside the workspace. Sure, I'd like a warning. But I might want to place the block, then bring the wayward parts into the workspace. I can do that with Protel. Frankly, I'd rather see Protel remove the workspace limitations, at least for some aspects of the program. It stores the coordinates, why not allow display? If it is necessary -- for speed, perhaps -- to keep active primitives inside the workspace, still, since it allows them to exist outside, why not go further; if there are aspects of the program that would be too difficult to reprogram, one already has the problem of having to filter the input; what is needed is a warning to the user that the results are not reliable. Most notably, DRC. But it is silly that Protel cannot recognize a pad outside the workspace as being unconnected! IMO, there are pros and cons to having the ability to move items outside the 100 x 100 kosher workspace. If prohibited, user-created macros would then have to contend with the possibility that their invocation would move one or items outside that area, which could result in complications. Exactly. OTOH, it is not always obvious when items are outside this area, so that is the drawback to not prohibiting this. Much, much easier to simply warn the user when a primitive is created or moved outside the workspace, and to report such primitives in DRC. The last is the most important, and the easiest to implement. * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * 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 * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
Re: [PEDA] Excluding a component footprint from a DRC check
At 01:08 PM 4/5/2002 +0100, [EMAIL PROTECTED] wrote: Is there any way of excluding a component footprint from a DRC check? You can set special rules for footprints, components, component classes, or specific footprint pads, from some DRC checks, particularly Clearance Constraint and a series of Manufacturing constraints, most of which involve calculated layers and so are not really DRC rules, as well as Placement Constraints and the Unconnected Pin rule. This does not, however, exclude the footprint from DRC; rather one sets a rule such that the component will not generate a DRC error because it satisfies the special rule. There is a priority relationship for rules, too much to go into at the moment. If it were stated more specifically what Mr. Turner wants to do, we might give more specific answers. But a little experimentation should go a long way * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * 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 * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
Re: [PEDA] Selection when in single layer mode
Unfortunately, single-layer mode has not be implemented in the best way. It was apparently designed to be used for viewing, not really for editing. The solution might be for Protel to disable selection entirely in single-layer mode, or make single-layer mode edit the same as having the same layers enabled in the Layer dialog. There are other problems as well We'd like to use single-layer mode to route on a single layer, especially where there are blind/buried vias, but display does not work properly, as has been dsicussed at length in the past. * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * 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 * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
Re: [PEDA] flies in the archive
At 11:49 AM 4/9/2002 +1000, Ian Wilson wrote: Brad is correct - the original enquiry was not about archives but about the servers and basic scripts. As Brad said, these are stored in the Files store of the yahoo users group. Not really important, yes, the original inquiry was about those files, but the subject line mentions the archive. We have one thing which we call an archive and it is the message archive on yahoogroups. We usually refer to the place where the files are stored as the filespace or the files area for protel-users. So I was making clear where the archive was located, for the record. Others answered the intended question. * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * 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 * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
Re: [PEDA] Excel to Protel Schematic
At 04:27 PM 4/8/2002 -0700, Shuping Lew wrote: I try to add IC power table to Schematic... Others gave good advice as to how to make a table in Schematic. So I'm responding to the basic idea of making an IC power table. It is essential, of course, that actual connections be made to power pins, even if the pins are hidden. If one wants to show the connections in a table, it would be better to use multipart components with a power section, placing that component and connecting it to power, instead of using hidden pins. A text table is REF information, i.e., it would be redundant, used for reference only. Redundant information should clearly be labeled as REF, but the fact is that it may be assumed by a reader of the schematic to be accurate. And there will be no automatic checking of this information to guarantee that it corresponds to actual connections. I consider such a table to be not a good idea. Power section parts can be designed so that they are placed in what would be similar to a table; the difference would be that these parts would actually make the desired connections instead of being merely for reference. This is more flexible and more reliable than using hidden pins. May of our experienced writers are strongly against any use of hidden pins at all. That may be an extreme position, but one should be aware that there are reasons for this strong dislike of hidden pins. * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * 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 * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
Re: [PEDA] flies in the archive
Sorry. * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * 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 * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
Re: [PEDA] FW: Access violation -- Is it a Protel bug?
At 03:23 PM 4/16/2002 -0700, Shuping Lew wrote: I tried to load a netlist file to PCB. It has over 1,100 components. I receiced a warning of access violation. It says: Access Violation at address OF086CC6 module Exception Occurred in PCB: Netlist... First of all, yes, I would strongly suspect a bug, though a damaged executable is a possible but unlikely culprit. Mr. Wilson is correct, it should not be possible to cause an access violation with bad (or good) netlist data. One factor not stated so far: did the Schematic pass a full ERC? Many designers, trying ERC, find so many errors and warnings that they do not bother to clean it up. After all, the job is due, etc. But that quickly-done job is going to be a problem if the PCB contains errors that could have been avoided if errors or warnings in the ERC had been found and fixed. Most experienced Protel designers take the trouble to track down and fix *every* error and warning. If a warning is verified to come from a condition that is intended, a no_ERC directive (Place Directive) is placed on the error marker to suppress the report. For example, I'll put such a directive on every unconnected pin, because I want to check for unconnected pins, for a very high percentage of schematic errors will result in an unconnected pin, or a net with no driving pin. As others have mentioned, a possible cause of the crash is a duplicated pin, i.e., a pin which is in more than one net, or possibly a net which is found in the list more than once. The former condition can be created by a bad symbol or by more than one part with the same reference designator. The latter will generally be detected by ERC. A sign of the former would be that an Update PCB will produce macros even after Update has been run twice. I would not trust that a netlist which crashes Netlist Load will produce good results when loaded through the Synchronizer (Update PCB), even if the latter does not crash. I would not be content until I had tracked down the exact cause of the problem, which can be done by cutting down the net list into sections, repeating the process until one has found exactly what causes the problem. (Note that a problem might exist because of two different nets or node in the list, widely separated in the file, so the chunking might need to be done in a more complicated way than merely cutting the file in half each time). * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * 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 * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
Re: [PEDA] FW: Access violation -- Is it a Protel bug?
At 10:13 AM 4/17/2002 -0700, Shuping Lew wrote: ---I created netlist for each sheets. There are total 25 sheets. I then loaded them individaully. There were no problem. If the problem was, for example, that you had an incorrect scope such that some net names were duplicated between sheets even though you did not intend to connect them, or there were duplicate designators, with one on one sheet and another on another sheet, each sheet would still load correctly, but the combination would fail in some way. A common error is the use of flat hierarchy with named nets on each sheet, but the sheet numbers are not added to the net names. This will cause duplicate net names, quite a mess. What Mr. Velander wrote should also be noticed. I'd be interested to see that net list. Mr. Lew, if he is concerned about proprietary data, could make a copy of his .ddb, edit the schematic to remove all type data, generate a net list -- which should still crash Protel, that should be verified -- and send it to me or to anyone else interested. Don't send it to the list! (A net list without data regarding the types of parts contains zero IP. I would not reveal the data to anyone else anyway, even if it did contain type data.) * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * 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 * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
Re: [PEDA] transparent backgrounds ??
At 02:13 PM 4/17/2002 -0500, Robison Michael R CNIN wrote: it was mentioned here a while ago that if i had hardcopy artwork, i could scan it, get it sized appropriately, and add it as a transparent background for me to use as a guide for interactive routing. is this correct? There are several .BMP to Protel translators around, including one in the [EMAIL PROTECTED] filespace. For one small project, I used a digital photo of a board, processed a bit in a graphics program and converted to .bmp (there are shareware converters out there, such as Graphics Workshop), then imported. I had to scale the data first. I forget exactly how I did it. Since I'm comfortable with gerber data, I might have dumped it as gerber and then scaled the gerber with a custom utility. There are other ways. If you can get the drawing scanned into DXF, that may be easier and more flexible. The data was imported or moved to a mechanical layer. Track could then be drawn over it. * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * 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 * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
Re: [PEDA] FW: Access violation -- Is it a Protel bug?
At 02:40 PM 4/17/2002 -0700, Shuping Lew wrote: I use some notes on every schematic project. So I created a schematic symbol named note for it. To avoid the warning of missing footprint, I also created a footprint named blank to associate with that symbol. I think there is a better way. You can copy notes to the clipboard and then paste them repeatedly wherever you want. To set up these notes for repeated use, just create a schematic sheet from which you can copy them each time you create a project. You could also make the notes part of your drawing format, i.e., the template file. I'd guess that the problem was caused by whatever was in that blank footprint. If it had no primitives, that would very likely be an unanticipated data structure, it is not surprising that it would crash Protel. Yes, the data should have been tested before being crunched, but the reality is that programmers simply don't think of everything We should perhaps verify this bug, I don't have time, but it should not be difficult. Once it is a reported bug, if we can verify it, future versions will be tested, by us if not by Protel * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * 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 * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
Re: [PEDA] Tango to Protel Translator
At 05:33 PM 4/17/2002 -0500, Jon Elson wrote: BUT, this applies ONLY to PCB, not schematic. ... I still don't know of a way to do it Tango Schematic can be read by Accel PCAD schematic (since that is the descendant program) and PCAD schematic is convertible to Protel Schematic through the PCAD-Protel translator available from Protel. * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * 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 * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
Re: [PEDA] changing electrical type
At 10:07 AM 4/18/2002 -0500, [EMAIL PROTECTED] wrote: Is there anyway I can change the electrical type of a pin to one that is not listed in the drop down menu? I would like to put an open drain on one of the pins. I rather doubt that there is a way. It would have to be in some kind of system configuration file. Then, we would hope, the ERC matrix would add the type to the matrix. But what would happen, then, when such a file, using the new pin type, were read by someone else's copy of Protel. There would have to be, also, an automatic modification of the pin type list to add a new type that was found on the schematic. I don't think they went that far. The only use for the pin types, as far as I know, is in the ERC, and I suspect one of the existing types would serve But the whole type question could be revisited, I'd suggest, it could get more sophisticated. * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * 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 * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
Re: [PEDA] IPL netlist to Protel
If a translator cannot be found, it is not terribly difficult to massage almost any netlist format into Protel form, unless the format is binary instead of text. Sometimes one can use just a word processor, but if this list is not organized by net, a spreadsheet like Excel can help with resorting; then the final polishing of the list into Protel format can be done with a WP. * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * 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 * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
Re: [PEDA] dual monitors
At 09:52 PM 4/19/2002 -0400, Brian Guralnick wrote: | I'll look into this, it may prevent the boot messages, etc. from spanning, | though that is a minor annoyance. | It does. Yes, it does, but it causes other problems. Six of one and a half dozen of the other. No time to write about this today * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * 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 * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
Re: [PEDA] Power plane clearance rule
There is another problem with this rule If I am correct, it is indeed, a hole clearance. But true clearance will be about 3 mils less, more or less, because the holes are drilled oversize so that 1.5 mils of plating (1 oz) will bring it back to the specified size. That is a conductive reduction of the clearance. It can be even larger because fab houses drill within a range in order to meet specified hole tolerance. In other words, if you specify 10 mils annulus, you actually get 8.5 mils *nominal* minus fab tolerances. Thin, too thin, usually. * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * 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 * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
Re: [PEDA] Shortened Designator on Silkscreen
At 11:30 AM 4/23/2002 -0700, JaMi Smith wrote: Most of these boards are built in house, but the error rate on stuffing components (the wrong ones in the wrong locations) is very high and the trouble-shooting time to find these assembly errors is exhorbinate, so I really do need the silkscreen every place I can get it. No, you don't. You need good process for assembly. Good assemblers don't even look at the silkscreen. It's too time-consuming. Instead, efficient hand assemblers would, in my experience, prefer to have a golden board, i.e., a board which has been correctly assembled. It's not essential, but if they have a flicker viewer, so much the better (i.e., a viewer which switches quickly from a view of one pcb to the other, with the images positioned identically. Very efficient for detecting differences, first used, I think, in the search for what was later named Pluto. I think I have heard of such a device being used for assembly, but I'm not sure. Similar would be a device which superimposed an image of an assembly drawing over a view of the physical PCB. Presumably, however, if assembly has been making lots of errors, they don't have tools like this. One reason, by the way, to send difficult assembly out. You really can't compete with them, when all is said and done. Herein lies the problem. I have 4 duplicate channels, with ref designators currently numbered as R1_1, R1_2, R1_3, R1_4, R2_1, etc. in the 4 parallel and identical channels. That's a problem in itself, perhaps, though it is one possible configuration. Other posts have often described ways to do duplicate channels in PCB. The default naming that Protel uses when you simply copy a block of components is *not* intended for serious use in duplicating blocks. You could consider these names as placeholders. Their meaning is obvious. But if you like those names, it is obviously easy to obtain them. The solution starts with a good renumbering in the schematic. The use of channel postfixes (like A, B, C etc), assigned number sequences (like channel A contains all refdes numbers between 100-199, B contains 200-299, etc) should be done at the schematic level. It is possible to use match on selection status to rename parts block by block, or if each section has its own page on the schematic, Protel's annotation tool can handle some kinds of channel numbering. Global edits with appropriate match criteria can be used to add distinctive characteristics to each block. As I recall, there are some irritating limitations in replacement criteria which has led me in the past to use the spreadsheet to add channel designators; one should realize that complex manipulations of refdes and comment text can be done in the spreadsheet, and one would have all the tools available in, say, Excel. I've not had good luck with the Protel spreadsheet editor, but perhaps I did not correctly intone the incantations. I use the Protel spreadsheet tool just for exporting the data and taking it back into the Schematic or PCB. If one wants to use the spreadsheet, I advise looking back into the archives for posts about how to Update from Spreadsheet. It can be quite persnickity, if you look cross-eyed at it, it can fail. My ref designators are already as small as our fab house will go for which is .025 high and .005 thick lines, and I am also tenting all of my vias so that they will not interfere with the silkscreen. Good. Though, as was implied in what I wrote before, I would not let silkscreen requirements override fab and assembly quality requirements. If you want tented vias, perhaps to reduce solder bridging, or you can at least tolerate them -- some assemblers, as I recall, don't like them, perhaps because of outgassing during soldering -- fine. Otherwise I would not go very far to make a complete silkscreen. But if you want a complete silkscreen for 0402 parts, there is lots of room between the parts if you cut out some of the outline, especially if you can handle 5 mil text. I've never gone that small. I'd make some custom footprints with the outline designed for this use. You could, of course, unlock primitives for a footprint and edit the outlines, but I would only do this if there were just a few places where it were necessary. I could however get a lot more designators placed in the limited room that I have if I could eliminate the channel designator part of the ref designator, i.e.: reduce the R1_1 to simply R1, which is much shorter, and which due to the layout is acceptable since the channels are physically very clear and already labeled as CH_1, CH2, etc. Sure. And this is not at all difficult to do. See below. However, if I shorten the actual designator, it makes for synchronization problems with the schematic, as well as hell to pay in the DRC department. Right. Don't do that. Instead use the Comment field, which is otherwise a bicycle for a fish. To make the comment fields correspond to the
Re: [PEDA] Ground plane floods on top and bottom of PCB
At 12:14 PM 4/24/2002 -0700, Afshin Salehi wrote: Hello all, Currently on PCB's I flood the top and bottom layers with a ground plane after routing. I've started doing that on certain boards, particularly fine-pitch SMT boards. It can make a good 6-layer stackup, with power and ground planes separated by 5 mils or so in the middle, for good distributed capacitance, layers 2 and 5 for most routing, and only fanouts and occasional or extra power routing on the top and bottom. covering the top and bottom -- except for component pads and fanouts -- with ground *may* improve noise behavior. It might also cause impedance discontinuities, it depends I have it remove the dead copper then I manually place via's where there was no flood to connect those area's to ground. One might want to place extra vias anyway, for better return paths. I then repour the planes and continue this process until I am satisfied with the coverage. This can't be the most efficient way. Is anyone else doing something like this that has a better way or a trick I am unaware of? I look forward to reading your replies. The only thing I can suggest is that you place as many vias and ground them before pouring. There is very little harm, if any, in having extra vias. I received a board here, done in OrCAD Layout, where the designer had used a pour, top and bottom, and had not removed dead copper. Worse than useless The pours that I made as described above did not need many additional vias, if any, for simple connection, because the only islands were inside QFPs or the like, and there was always at least one ground via already in there * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * 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 * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
Re: [PEDA] Importing a large image file into Protel PCB
At 11:05 AM 4/25/2002 -0400, Jim Vegh wrote: I have search all over the web and the previous forum posts and cannot find bmptopcb anywhere. There is a program which was donated to the user's group in the filespace for [EMAIL PROTECTED] http://groups.yahoo.com/group/protel-users/files/Convert.zip Note that you may need to be a subscriber to the mailing list protel-users to access this file, and also to be registered with yahoo (so that yahoo can recognise your identity through a cookie). We could have made the filespace fully public, but discovered that this could create some intellectual property hazards, so I think we left it member-only. There is another bmp to protel converter from a user in New Zealand. It must be obtained from him, it's illegal to pass it on, as I recall. He sends it on request, at least he did in the past. I don't have quick access to the information, perhaps someone else does. * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * 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 * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
Re: [PEDA] Print preview bug on Arcs
At 02:58 PM 4/25/2002 +0100, Michael Binning wrote: Dave, I have just tried creating a simple design using tracks in arc mode, as a test. Got to print preview OK, but as soon as I hit the print button, bye bye Protel. Locked solid. The problem may be file-specific, so it is crucial to save a file which shows this problem, together with information about the printer and printer driver revision level. Unless the bug is known, which would likely show up pretty quickly on this list, the file, or a cut-down version of the file that still shows the problem, should be sent to Protel, together with the printer/driver information. At the same time, other users may wish to investigate the problem. Please don't send attached files to this list, but only to those individual users who indicate their willingness to receive them. (I think this list is now set to reject attachments, which is essential for most mailing lists, particularly because of virus security, but also for other reasons as well). * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * 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 * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
Re: [PEDA] recovering data
At 12:53 PM 4/30/2002 -0400, Bagotronix Tech Support wrote: Since Protel DDBs are so huge now, fitting a large project on one CD-R might be a problem. Protel DDBs get large if one does not empty trash and compact the database. The latter is the most important and the least visible problem, the only symptom of failing to compact is that the file gets larger, and larger, and larger. If I am correct, the Access database being used does not automatically recover space when a file is deleted. That's what the compaction tool is for. I have 99SE set to automatically compact every database when it is closed. A minor nuisance sometimes, it takes a little longer to close the database. Or one can manually compact from the Client menu. (That funny down-arrow in the upper left hand corner of the screen) A while back, I still was using a 56K dialup actually running about 30K, I got a very, very large ddb from a client. After compaction, it was less than one-tenth the size. It would take a truly large project to be too big to fit on a CD after being cleaned up and compacted. * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * 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 * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
Re: [PEDA] mirroring or flipping a PCB (was:...)
At 03:45 PM 4/30/2002 -0700, Mira wrote: The meaning in Pcad is that you get all layers swapped. Top goes to bottom, silk top - to silk bottom. So it's like looking at the PCB from the bottom side (or routing as the bottom side it your top side). There are three possible aspects to mirroring and flipping. Mirroring would not flip the board, it would not convert top to bottom, etc. Mirroring is useful in generating checkprints of the bottom layer(s), particularly the legend; it can also be used, in gerber photoplot, to generate bottom views that can be reimported. Flipping could mean flipping in view only or flipping in actuality. View-only flipping would merely mirror the display. It should be relatively easy for Protel to implement this, but they have not. View-only flipping is really the same thing as plot mirroring, except it is with the display instead of with print or plot output. Actual flipping is a tad complex; Mr. Wilson, as I recall working with Mr. Harland, wrote a board inversion server. Full board inversion (we called this deep inversion) would truly reproduce the database as if the board had been completely flipped. Note that this involves changing inner layer assignments, it is not merely a matter of mirroring all layers and swapping the top and bottom layer assignments of primitives. Deep inversion would primarily be useful with design re-use, I won't go into details. Design views of your top and bottom overlay (silk) next to your PCB design help you to locate easily the components. When you flip the PCB and refresh you'll see the views changed, too. Highliting a component also highlights in in the view. Select another one and it appears selected on the view. Yes, this is a desirable feature. It was originally, if I am correct, a quite expensive add-on to PCAD. This feature, as I would anticipate it, would allow the placement of a view of the PCB next to the PCB. This view might not only be mirrored, if desired, it might also be rescaled; it might include only a defined section of the design (i.e., to create a detail view). The existence of this tool or something like it in PCAD reflects the mission and user base of PCAD: PC design specialists working in large companies. Protel is aimed primarily at engineers, though there are certainly large companies using it. The original price of PCAD -- at the time Protel bought it -- reflects this difference. PCAD pricing was collapsed almost immediately by Protel to a flat $10K for the whole shebang, at a time when Protel pricing was still $6K for a full suite. Protel pricing has now come up a bit to $8K, but we can expect that this pricing really reflects the new elements that will appear in Phoenix, since it will include Phoenix when the latter is released. Bottom line: the (relatively) easy way to make bottom-side-view assembly drawings is to export appropriate gerber and re-import it; this is how I have done it and I think Techserv does about the same (they may have utilities to speed the process, but it is not difficult). I've got another question. When moving the selection I placed it close to the lower left corner... but some of the components are now out of the working space. I looked to me it was possible to place them there and Protel didn't complain. It was deselected and saved in the mean time. Naughty, naughty. Yes, Protel allows out-of-workspace primitives. Having used Tango, which does not allow this, I'd say that I prefer the Protel way; but Protel should add tools to make it easy to recover such primitives. Among other things, DRC should report out-of-workspace primitives; as it is, an out-of-workspace footprint pad will *not* generate an incomplete net error. I consider that a bug. There is a clear sign that you have out-of-workspace primitives: Zoom All will not confine itself to the complete set of primitives that you can see. The basic method of moving these primitives back into the workspace, where they can be manipulated and/or deleted, is to place any primitive, like a large pad, Select All, then Deselect Inside to deselect everything visible except that pad. Pick up the pad, and when you are moving it, a box should appear that will extend out of the workspace. By moving the pad, you may be able to bring in the out-of-workspace objects. I say may because sometimes an object can be so far outside the workspace, as a result of multiple selected object moves, that it will take more than one move to bring everything in. How may I select again the PCB only? There are many other things than I don't want to move. Protel provides a powerful set of selection tools. I've described above one way to move only out-of-workspace objects. There are others. Note that sometimes a component may be basically on-screen but may have an out-of-workspace primitive. This can make for complications, but it is still not difficult to fix once one knows the problem. (Such a condition can
Re: [PEDA] Acrobat Reader to Protel sw
At 08:57 AM 5/1/2002 -0700, Tony Karavidas wrote: No, PDF is a completely foreign file format. I don't imagine ANY EDA tool reads PDF files and makes use of the 'information within. Right. However, there may be a path to get some data in. Protel will import DXF, and there are, I understand, some utilities that will convert bitmapped files as well as other formats to DXF. There will be scaling issues, and component and information will not be in the file, one may need to restore it. The problem is similar to converting gerber to PCB, only more complex because of scaling and because both gerber and Protel are vector-based. I don't know about PDF. * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * 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 * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
Re: [PEDA] mirroring or flipping a PCB (was:...)
At 03:00 PM 5/1/2002 -0700, Mira wrote: Does anybody know how expensive Phoenix will be? I'm not sure that Altium even knows for sure. But they have announced that pricing will be in line with current pricing, i.e., $7995 for 99SE full regular price. There are often sales and specials for multiple licenses, etc. They are also indicating that upgrade from 99SE licenses older than a certain date (1 October 2001?) will be $1995. Since that is also the current upgrade price from Protel 98, they will have, if they keep to what they have indicated, devalued P99SE licenses bought before the cutoff date. This has not been past practice, except that really old licenses tended to be the same upgrade price to be come current, i.e., the upgrade from Autotrax to P98 was the same as the upgrade from version 2, and the upgrade from version 3 or before is now $3995, twice that of what it is for P98. There is normally a resale market for Protel licenses, but the pricing uncertainties and structure have certainly thrown that market into disarray; it becomes very difficult to determine the value of a license much more than today it is worth I have a PCB, which reports 5 polygons although I see only 4 on the PCB. One of them is empty and can't locate it. When I select all and try to move it, it says there are locked primitives and one of the polygons doesn't want to be moved. How to find out which primitives are locked? How to locate the empty polygon? My, my, you *are* exercising the program, to run into so many Protel quirks so quickly. Empty polygons are created when one sets the polygon to remove dead copper, and there is no net seed within the polygon. So all poured primitives are removed, and the polygon becomes a tad difficult to find. It is possible to find polygons and their tracks using Edit/Export to Spreadsheet, and to edit the remove dead copper parameter in the Spreadsheet, updating the PCB. This is a bit of a tricky process; and changing the attribute will not cause, I think, the polygon to repour. But selecting all, cutting it, and pasting it back will cause Protel to query whether or not you want to repour. I think there is a better and easier way, but I forget what it is. This is not exactly something should need to be done frequently Generally, however, once one understands how to accomplish a thing in Protel, it does make sense, it is relatively easy to remember. Probably... after you remember all sets of buttons to press. No, the point is that *most* important commands are fairly easy to remember, and quick to use. I did *not* find this to be true with OrCAD Layout, which was designed to force the user to do things the OrCAD Way, which was *often* quite convoluted. There were plenty of things that I could do in seconds in Tango which took me hours in Layout, mostly to figure out how to do it, and when I did find the way, it was complex and not fast, and it was, from my point of view at least, highly arbitrary. Next day, when I needed to do the same thing, I could not remember it. If I did not keep notes, it was back to research mode maybe it was faster to find the info the second time around. But not much. And, as I said, the process would often turn out to be much more complex than what I expected. More specifics on this below. I met Orcad on a crossroad several times. PCAD was/is my love from the first sight. Love is like that. However, had you met Protel first, I find it less likely that you would have become so infatuated. Certainly, however, this is open to discussion Many Protel users simply could not have afforded Accel PCAD; when what has become the unified package was about $20K, Protel was selling on special for about $4K. I got in for $2K because a friend had a spare Autotrax license. Since Autotrax sold for less than $1K, as I recall, Protel was really cheap for such a flexible and powerful system. I paid another $700 to upgrade to 99SE. You couldn't even buy the severely limited Windows versions of Accel Tango for that So I am not at all surprised to find that PCAD has features which are lacking in Protel. It ought to! [I wrote about Loop Removal.] This reminds me about one of the first versions of Orcad. I had several nets routed but there was no space for one more and I couldn't find a way to move the segments. I decided to delete it but for Orcad this meant remove the net from the netlist. So, I had to load it again. The right way was to re-route it from the beginning to the end and then the old one was removed automatically. I hope this is not the case here. Only if Loop Removal is enabled. The problem with OrCAD, as I recall, was that it was either impossible or less than obvious how to turn off loop removal. In Protel it is a selection field on the Preferences screen. It was also quite difficult, I found, to guide the routing in Layout. The cursor would float and the track would go to what
[PEDA] Current virus danger
I have been notified by a subscriber to this list that he received what is probably a copy of one of the W32.Klez viruses, and that the mail appeared to be from me. This virus is known to spoof outgoing mail addresses, and it is quite unlikely that I am infected -- though it is remotely possible in spite of my precautions -- but his receipt of that mail, appearing to be from me, indicates a high probability that a subscriber to this list is infected, and other subscribers can expect to receive the virus. This virus is currently at epidemic levels, I have received perhaps ten copies of it. All users should treat any mail with attached files as dangerous unless prior correspondence leads one to specifically expect it from the sender. I would never send anyone an attached file unless they are first warned and generally I would wait for an acknowledgement before sending the file. Further, this virus can take advantage of security loopholes in Outlook and Explorer; it can be enough in some cases simply to open the mail even if the attachment is not opened. I use Eudora, which is not so vulnerable, and I turn off the Eudora option Use Microsoft Viewer. So I don't automatically see animated text, etc Darn :-) Users are likewise urged to use Windows Update frequently to ensure that critical Microsoft patches have been installed. * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * 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 * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
Re: [PEDA] Want to buy 16-bit Protel w/License
At 05:21 PM 5/1/2002 +, [EMAIL PROTECTED] wrote: I am interested in purchasing Protel PCB/Schematic Software with license. Prefer Protel 98 or newer. For the information of our readers, older Protel licenses which have not been used for upgrade are eligible for upgrade pricing. Right now, a Protel 98 license is worth almost as much as an older 99SE license because it can be upgraded to 99SE for $2000 and the upgrade will include the Phoenix release, whereas a pre-Oct 1, 2001 (?) 99SE license will not be automatically upgraded, some Protel announcements have indicated that the upgrade pricing will also be $2000. So if one has already decided to buy a 99SE license, or wants to buy one but cannot afford the current price ($7995?, it fluctuates with sale pricing), anything below about $6000 would be an improvement. I'd say that $4000 is about right for a used P98 license. Yes, this may be more than one paid for the license in the first place As I have indicated elsewhere, the Protel resale market is in a bit of disarray due to uncertainties about pricing, plus Protel has run sales which lowered the price by about 20%. Since used licenses were selling for about 25% below regular price, the sales left not enough improvement to motivate buyers; naturally a seller could lower the price accordingly, but sellers usually want to get as much as possible and thus are motivated to wait until pricing settles I may have a 99SE license for sale, BTW. Note that licenses which have already been used for upgrade are considered by Protel to be subsumed into the new license; Protel has stated that it will consider the sale of an older license to be the sale of any newer license founded upon that older license. I don't think they would get away with that in court, i.e., they could not prosecute for copyright violation, BUT they are completely free to set whatever policy they deem appropriate when it comes to recognizing licenses for upgrade purposes. So one could be trashing one's right to upgrade by selling an older license that could be a very expensive mistake. * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * 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 * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
Re: [PEDA] propagate net
At 05:49 PM 5/3/2002 +0200, Rene Tschaggelar wrote: I have unassigned tracks (no net) and would like to proagate the connected net. In schematic there is a 'design/update pcb' that has a checkbox for 'Assign net to connected copper'. That somewho does not appear to work. It should. It is possible, however, I'd think, to feed this command situations that it cannot digest. Most notable would be a short condition. Obviously, if two component pins with different nets assigned are connected together, Protel will not be able to determine easily which net to assign to connected primitives. As I recall, it will assign nets until it encounters the conflict and it will then abort assignments for that net, leaving the rest of the copper unassigned. Since it could encounter the conflict almost immediately, almost all the copper in the net could remain unassigned. Now ( in pcb editor ) I have do : -edit/select connected copper -read the netname from the source -doubleclick one new track item -change net to new net with global, selection same Is that all possible on one click per track ? No. At least I don't think so. A cumbersome and complex solution has been outlined, and I don't even think it would work as described. I don't think that is the way to solve this problem, it is much simpler than that. Is that possible on one click for the whole board ? Not one click, but a few, and perhaps a little detective work. I don't know what condition the board is in, so what I will describe may be more involved than necessary; I have to assume that it is quite a mess I'd start by running, in PCB, Design/Netlist Manager/Menu/Update Free Primitives from Component Pads. then run DRC with Short Circuit Constraints checked, and nothing else. Fix any shorts. It may be a bit tricky; I think that the Short Circuit Constraints report will include No-Net track connected to anything with a net assignment. If there is too much noise like this, I'd do the following: Run PCB:Design/Netlist Manager/Menu/Create Netlist from Connected Copper. From your Schematic, run SCH:Design/Create Netlist. (Presumably you know how to set up the scope options for netlist creation) Then use SCH:Reports/Netlist Compare to compare the two net lists. You may be able to find the shorts quickly this way. Once the shorts are removed, Update should work, whether it is run directly in PCB or through the Synchronizer. If not, save the file (so that it may be possible for someone else to look at it, perhaps after removing proprietary information, if any) and ask us again If there is still an issue, one or more of us may volunteer to receive the file, please don't send it to the list! * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * 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 * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
Re: [PEDA] All Servers gone
At 11:29 AM 5/3/2002 -0600, Cam Andruik wrote: Well this is wierd. Yesterday Protel worked fine. Today I start it up and it will not open a database. I have no Servers installed. If I add them, the next time I start Protel they are all gone again! Anyone ever seen this before? Not this. Perhaps someone has a better idea what is happening, but at this point I would uninstall Protel, move all the *99SE.* files in the Windows directory to some other location, and reinstall Protel. If it works, one can then, if there is customization to be recovered, move the *99SE.* files back by halves -- keeping track of what has been put back in the most recent batch --- until the problem reappears. Proceeding like this, the bad initialization file, if any, may be found, and it might even be partially recoverable with a text editor If there is no serious customization, I wouldn't bother restoring the old files. * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * 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 * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
Re: [PEDA] propagate net - solved, thanks
At 01:42 PM 5/4/2002 +0200, Rene Tschaggelar wrote:
Thank to all for these quick replies.
The netlist manager solved it. I didn't try to propagate
through unassigned vias, since they usually don't pick up the
changes in net assignment. So I did repeat {assign, place via}
until all nets were completely assigned.
Vias and free pads do not pick up the (new) net assignment if they are not
directly connected to a component pad. Stitch vias would be an example.
Otherwise the Update command previously described should update free vias.
I made a section on a page describing the procedure :
http://www.ibrtses.com/software/protel99se.html
While that page does describe a process for recovering a file from gerber,
it does not give the most efficient way of doing so.
The process I would use is to start with free track and pads brought in
from gerber. (vias are plotted the same as pads, so they import as free
pads.) Save that file separately. I would then place the footprints so that
the pads overlay exactly. It is also possible to recreate a footprint by
copying the pads (through the clipboard) into a footprint (in the library
editor). Then I would delete all free track and pads. I would then import
the net list or run Update from the Schematic. Then I would open the
separate file with track and pads. I would use global edits to delete all
footprint pads, typically they would be different sizes from vias or free
pads. When I have the file with only track and free pads, I would use Tools
Convert to change all the free pads to vias (or those which are
appropriate, if there are other free pads on the board). I would then copy
this en masse to the PCB with the footprints. It will help if the block
copy reference is in the same location as a footprint pad. When a block is
copied, the default is that copied track and vias and pads pick up the net
from already-existing primitives
I haven't tested this recently; if the net assignments are not complete,
the Update Free Primitives process should complete it.
Rene
Rene Tschaggelar wrote:
I have unassigned tracks (no net) and would like to proagate
the connected net.
In schematic there is a 'design/update pcb' that has a checkbox
for 'Assign net to connected copper'. That somewho does not appear
to work.
* * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
* 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
* * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
Re: [PEDA] mirroring or flipping a PCB (was:...)
At 10:06 AM 5/4/2002 +1000, Ian Wilson wrote: On 01:03 PM 2/05/2002 -0400, Abd ulRahman Lomax said: ..snip.. I do understand that the Protel training, with Mr. Wilson, is quite good Not me - I do not do any Protel training. Maybe some other Mr Wilson :-) Ian Wilson Yes, Rick Wilson * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * 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 * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
Re: [PEDA] recovering data
At 09:38 AM 5/7/2002 -0500, David VanHorn wrote: Stop! Don't confuse the terms! I'm not confused. This has gotten a tad out of hand. The subject of this list is Protel software, not RAID systems or whether person A or person B is or is not confused. A RAID discussion is peripherally related, the discussion of persons is completely outside. There is an open topic list to which such discussions can be taken. As to the RAID topic, it is quite obvious that there are hazards against which a RAID drive will fail to protect. A properly designed backup system protects against nearly every hazard; however, there may be *some* lost data and there *will* be lost time. There are still hazards against which a backup system will fail to protect unless *all* data is kept permanently. A raid system is definitly NOT a backup, it's something like a fail safe system! It protects ONLY against hardware failture and can't replace a backup system. This was 100% true if his terms are understood according to his intention. Does it protect against failures of the raid controller? Does it protect against the OS instructing the controller to destroy your data? Failure of the RAID controller may or may not corrupt the data. OS Failure (which may not be failure of the OS itself but of system security or operator error) is a necessary hazard, i.e., there is no way to absolutely protect against it; but frequent backups with a long trail will do well. But the question of the use of a raid controller is not based on elimination of backups. Rather it is a cost\benefit analysis that balances the cost of the system against the expected loss of operating time from hard drive failure. With a raid level 5 it is possible to work further if one (and only one of at least three) of the hard drives fails. So you cube your odds of having a drive fail, to protect yourself from that failure, assuming the OS or the applications don't barf all over the data first? I know a little about probability theory, though I am certainly short of being an expert. The odds of having a drive fail increase but are not cubed, rather they are -- aproximately -- added. I.e., a .001 probability of a single drive failing, by itself, would become, for the probability that one or more drives out of three fail, the compliment of the probability that no drives out of three fail, i.e. 1 - (.999)^3, which is 0.002997001. Thus the average cost of replacing a failed disk during the period of usage is almost tripled. But hard drives are cheap. Unless the disk failures have a common cause, such as a fire or poor system design overheating the drives, the probabilities should be independent, which is why they are cubed when the events must be simultaneous. However, the chance of a system failure due to a simultaneous failure (the same day) of more than one disk become much, much smaller. The sum of the probabilities of all possibilities (0 drives fail, 1 drive fail, 2 drives fail, and 3 drives fail) must be 1, i.e., certainty. We have the first above, the last is 0.1. Because there are three equally probable ways that one drive alone can fail, the probability of one and only one drive failing becomes three times the probability of each specific condition (i.e. F00, 0F0, and 00F), which is 0.001 * 0.999 * 0.999). This is 0.002994003. Adding the probability of three failures, this becomes 0.002994004. We must subtract this from the probability that one or more drives fail to get the probability that two or more fail. This is 0.02997. I.e., adding two drives has reduced the probability of system failure due to hard drive failure from one in one thousand per day to three in one million. Raid was a good idea in 1980, when hard drives were somewhat unreliable. I've had them fail, as have we all.. However, every OS I've run in the windows line has caused way more problems. Way more problems, yes, but not way more massive loss of data. It is unusual for an OS failure (i.e. bug) to cause massive loss of data. There are virus that will format your drives, of course. If a hard drive fails all you have is the backups. No one has suggested RAID as a substitute for backups, unless perhaps the array is across a network with computers in different locations. That isn't ordinarily called RAID, if I am correct Rather RAID is a device for reducing down time as well as the time to restore lost data from a single drive failure. * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * 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 * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
Re: [PEDA] deleting a string
At 02:00 AM 5/10/2002 -0700, Mira wrote: Ian, I use S-A and everything is selected. No hidden layers. Even though the strings on all layers could not be deleted. The strings are definitely selected and could be moved. E-D doesn't work. S-A selects everything. I checked this on all layers. E-L clears the selection but in fact it's still there after I refresh. Presumably Design/Options/Layers/All On has been pushed. All these strings used to be text dimensions, board layer names (free text), and text in the drill charts. All selected primitives could be deleted but the text - not. These strings could be selected as free primitives as well. So, I presume they are free, unlocked. This is a clue. These 'strings' are the result of gerber import (or DXF import), since drill chart strings are not displayed in the PCB editor. They are not strings, they are free track which look like strings. Unstated was whether or not they are locked. In my opinion, Protel should simply not delete any locked primitive until it is unlocked, but instead it queries the user, who only has two choices: delete them or abort the command. It would be useful, sometimes, to be able to delete everything but what is locked. As the matter is, one would have to do global edits to turn off selection for everything that was locked But that is probably not the problem here, or Mira would have told us about the locked message. I just can't get rid of them. You can get rid of *anything* by saving as ASCII and deleting its records. I'd think that would be reasonably safe to do; but always make a backup when attempting to edit the ASCII. But it might be simpler to select everything except the lines and copy *that* into a new PCB file. I'd also ask where this file came from. If it is, directly, gerber import, it should be easy to edit. But if someone has, for example, made it into part of a footprint, and if there are workspace issues (something might be outside the workspace), it could get tricky. A quick check to see if anything is inside the workspace would be to select all, then pick it up with the cursor and move it. If the box that appears extends outside of the workspace, bingo. Yes, by all means, post the offending records if you can find them. You can do searches on a coordinate, that's one way, if you can find the coordinate. What do you see when you double-click on one of these lines? You could try globally editing a line that you *can* edit to unlock all lines in case lock is involved. A Protel ASCII database can be loaded in Excel by using | as the field separator. Excel, at least the version I have, will prompt the user through the load process. But saving the file would be tricky, I'd just use Excel for searching and finding and reporting, not for editing, necessarily. (Unless one edits through Spreadsheet Export, a whole different animal with its own quirks.) * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * 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 * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
Re: [PEDA] round PCB?
At 12:22 PM 5/13/2002 -0500, Jon Elson wrote: If you do autoroute, you need to make the keep-out line out of straight track segments. This is the only limitation I know of. A hint for quickly and accurately making the outline out of arcs: draw an arc of the right size and position, gerber photoplot it using RS274-X, software arcs, and absolute coordinates, then import it back to the appropriate layer. (If you import a single gerber, it goes to the current layer, as I recall, and in the right position if you have plotted absolute. If there is only one layer enabled, definitely it will go to that layer!) It will be a polygon with a lot of small faces, drawn with individual lines. That's what a software arc is. * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * 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 * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
Re: [PEDA] Issue w/ lomax short Kelvin Paths and Copper pour
If gerber plots were not rounded off, there would be no problem with the virtual shorts, and, in fact, if fab houses fabbed the boards as-is without modifying the gerber, there would also be no problem. But Protel does some rounding and it is not easy to exactly control aperture assignments while using the much easier RS-274X, though it can be done; properly implemented, aperture match would cause the gap to actually disappear as long as the pad distance is such as to leave the pads on a 1 mil grid. But as Mr. Saputelli discovered, it is fairly easy to set up and place a virtual short footprint in such a way as to leave a tiny gap, enough to puzzle the fab house inspector. Complexities like this have led me to recommend the alternate method I indicated in another post in this thread. It is a little easier to document and no fab house will be tempted to modify the gerber. * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * 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 * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
Re: [PEDA] Issue w/ lomax short Kelvin Paths and Copper pour
At 02:41 PM 5/14/2002 -0700, Dennis Saputelli wrote: could you repost your alternative? possible implementation: enable an unused mech layer and label it shorts. Add track on this layer to a jumper footprint so that it will short the jumper if added to the plot for the copper layer. Use the shorted jumper on schematics to isolate a net section (i.e., to control connection path). Create a separate gerber definition file under the CAM manager for the copper layer used which adds the shorts mech layer to the plot; disable plot for that copper layer in the regular CAM gerber definition file. If both definitions are enabled for plot in the CAM manager, both will be plotted. (Copy the main CAM def file to make the special one, then disable all layers except the one you want to plot and change the mech layer to plot simultaneously in on the mech layer tab.) I have not actually used this procedure, only the microgap virtual short, but it seems quite straightforward in theory. If anyone has used it, please confirm that it works or tell us how it didn't, if known. I would expect that the most likely failure would be that the designer forgets to set the special CAM definition, which would be relatively harmless at the prototype level since the shorting jumper could manually be shorted. (This is also the case with the microgap short). This, by the way, is a good argument for requiring the fabricator to provide its customer the actual CAM files used for fabrication. Fabricators routinely make small changes without informing customers in order to improve manufacturability But I've never seen a fabricator provide the actual files. In any case, the fabricator who unshorted the pads should very clearly have queried the customer as to whether or not the pads should be shorted (as they would if the board had been fabricated as-is) or opened to a fabricatable gap. So those missing shorts were due to fabricator error... i missed it i did find that origin pin 1 seemed to nail the issue and make no gap even in gerber 2.4 my gap was i think .005 mil in the (bad) case of using center origin and using gerber 2.3 i think the result was a 2 mil gap as the edges of the pads were pulled back toward the center to the nearest mil this notwithstanding it has proven to be a useful and clever tool Dennis Saputelli Abd ulRahman Lomax wrote: If gerber plots were not rounded off, there would be no problem with the virtual shorts, and, in fact, if fab houses fabbed the boards as-is without modifying the gerber, there would also be no problem. But Protel does some rounding and it is not easy to exactly control aperture assignments while using the much easier RS-274X, though it can be done; properly implemented, aperture match would cause the gap to actually disappear as long as the pad distance is such as to leave the pads on a 1 mil grid. But as Mr. Saputelli discovered, it is fairly easy to set up and place a virtual short footprint in such a way as to leave a tiny gap, enough to puzzle the fab house inspector. Complexities like this have led me to recommend the alternate method I indicated in another post in this thread. It is a little easier to document and no fab house will be tempted to modify the gerber. -- ___ www.integratedcontrolsinc.comIntegrated Controls, Inc. tel: 415-647-04802851 21st Street fax: 415-647-3003San Francisco, CA 94110 * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * 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 * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
Re: [PEDA] Protel DXP beta testing
At 04:59 PM 5/15/2002 +1000, Thomas wrote: I received an invite to apply for Protel DXP beta testing today. As I have not signed it yet, I don't suppose its breaking the NDA to let you know this. It's my understanding that Beta testing was only being offered to those who had already signed up for their volunteer testing program, which involved signing a non-disclosure agreement at that time. Perhaps Protel has invited someone else, perhaps Thomas forgot about it. I signed the NDA, but it does allow signers to reveal already public information, public as of the time of signing. The interpretation of that, and application to this situation, is not completely clear to me, but I do interpret it as possibly meaning that the fact of Beta testing remains confidential if it was not publicly known when the agreement was signed. So I can't conform or reveal whether or not I have received a Beta testing offer But, ahem, *if* Phoenix is in Beta test, well, it's about time! I urge Altium/Protel management to be reasonably thorough in private Beta, then to open Beta to a wider group (i.e., any licensee who wants to download it) before formal release. Many bugs do not rear their ugly little heads until the program has been exposed to a wide range of user-generated conditions; as we have noticed, there are bugs that took us two years to find It also think it a good idea for Beta testers --- ahem, when it is in Beta -- to look at our database of known bugs: http://groups.yahoo.com/group/protel-users/database and test the new version for fixes to these bugs. You must be a member of [EMAIL PROTECTED] (and, I think, have a yahoo id linked to the list) in order to access the database. (protel-users is a low-traffic list used presently as a backup for the main Techserv list, since support can be time-critical, and also for file storage and access.) * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * 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 * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
Re: [PEDA] Protel DXP beta testing
At 08:02 AM 5/15/2002 -0400, [EMAIL PROTECTED] wrote: I received it yesterday. However, I haven't yet decided whether to sign or not. Perhaps the biggest sticking point is that the license specifically forbids me to use the beta to do real work - above and beyond the usual disclaimers of liability for any of the results. Unless Beta testers ignore it, that would be a severe handicap placed upon Beta testing (I'm neither confirming nor contradicting the report above). It would make testing perhaps 5% as effective as it would be without the restriction. I can only see two reasons why Protel might have that restriction: (1) Liability if program defects caused loss of work product. But this has already been covered according to the report above. (2) Fear that Beta testers will keep using Beta after the Beta period expires and not pay for the upgrade. While it might be true that some would do this, it is a singularly stingy approach. Beta testers put in a lot of work; the ability to continue to use a Beta program beyond its time would be a very small compensation. However, Protel might instead offer Beta testers who actually made or confirmed bug reports a discount on the upgrade if they do this, the restriction would not be offensive. the big problem with the reported restriction is that it would require users to do *extra* work in Beta testing beyond the work involved in communicating problems. I've always tested the software, in the past, on real work. If the report is valid, does Protel think we have loads of spare time? * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * 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 * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
Re: [PEDA] AW: Kelvin Paths and Copper pour
Due to a mail system error, this did not go out yesterday when it was written: At 11:57 AM 5/14/2002 +0200, Georg Beckmann wrote: For to do this, I use dummy parts usually 0402 resistors for the routing. You have different nets for current and sense, you can also give them different rules. After finishing the routing and checks, I short this parts in the schematic, do an update pcb and short this parts in the pcb manually. That's a quick way to accomplish the goal. However, my preference is for something more like this: At 06:03 AM 5/14/2002 -0400, [EMAIL PROTECTED] wrote: This sounds like a perfect application for the Lomax virtual short which has been discussed on this board. Check the archives for details, but in a nutshell you create a part which has a gap which is too small to fabricate (i.e. 0.02), and set up a special design rule to allow a 0.01 clearance between the pads involved. Place a jumper on the schematic to allow the two wires involved to be separate nets, and place the physical component described above to control the connection point between the two nets. The advantage of this method is that the short is maintained in the database; if you run the autorouter again, next year, it will not fix the routing path. It can be a little tricky to set up the part, but once you have it, it is done. There is a PCB file with a virtual short that works at: http://groups.yahoo.com/group/protel-users/files/virtual_short.zip (Because some files in that filespace are proprietary, it is necessary for copyright reasons and the yahoo agreement to restrict access to the filespace to members only. So yahoo needs to know that you are a member, which means that you must (1) be a subscriber to [EMAIL PROTECTED] and (2) accept a yahoo cookie. Maybe someone will set up an alternate space for those who are on a cookie-free diet.) An alternate method is to use a dedicated mechanical layer to create the short and a special gerber plot setup to plot that layer only, together with the shorting mech layer. This method is simpler and the shorting part easier to create. Do *not* place the short as free track; rather put it in the footprint so that it is automatically maintained in the correct position. If the mech layer is named something like shorting bars it will be a kindness to future generations, and the part should likewise have a descriptive name that makes clear its function. * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * 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 * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
Re: [PEDA] New Netlisting Problem
Due to a mail system error, this did not go out yesterday when it was written: At 05:36 AM 5/14/2002 -0700, Fisher, Jerry wrote: Did you run an ERC to see if the resistor is flagged with a connection error. This is absolutely the first thing that should be done; and the ERC matrix should be set up to detect unconnected pins. If not, fix it. I can hear the screams of pain from designers who have turned that ERC rule off because they get hosts of such errors and all or most of them are not actually errors. But there is a better way; once one understands why a no-connection error is being found -- the most obvious and common is that the pin is intentionally unconnected -- one should put a No-ERC directive on top of the error marker; you will never again have to see that error. In fact, it's good practice to place the directive when you are wiring the schematic as a flag that the pin is deliberately NC. Years ago, an engineer pointed out to me that checking all unconnected pins on a PCB layout was a good way to find errors quickly, as *most* errors resulted in an unconnected pin. This was with manual layout, tape and mylar. It's still a good idea, and the programs make it easy to find NC pins if you don't turn the warnings off! * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * 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 * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
Re: [PEDA] Protel DXP beta testing
At 08:49 AM 5/15/2002 -0700, Brad Velander wrote: [...]Another impact on revenue figures for this half is the re-scheduling of our next major product release. Protel DXP, which is now expected to go into external beta testing in May and released for sale in July 2002. So I guess anybody can talk about May beta testing occuring all they want because Altium has already released such information publically. Actually, they did not make it public that they were entering beta test, and, in fact, we don't have any report that it is actually in beta test, only that a user or users have received an invitation. That might be sent out in advance of the actual release to beta. What they said, as quoted, was that it was *scheduled* for external beta in May. Small point, perhaps, and perhaps it is moot. Personally, I think the secrecy is not only unnecessary but counterproductive; if it were up to me I'd probably make the beta release open to all licensees; an agreement might be necessary, but it would be one along the lines of a promise to uninstall when the beta period is over, if one does not buy or otherwise lawfully receive the upgrade. People expect beta release software to be buggy It is much more important to find the bugs and fix them before full release than it is to keep it all hush-hush Bugs in the final release generate a lot of negative opinion about the program, the fewer the better. And as far as the competition goes, I think that if the competition seriously wanted to look at the Protel beta, they would find a way. * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * 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 * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
Re: [PEDA] rooms?
At 11:26 AM 5/15/2002 -0700, Tony Karavidas wrote: Rooms are great. Yes, though their automatic generation can be a small nuisance. The checkbox for adding rooms is the default setting, as I recall, so I'm often getting rooms when I don't want them I'd prefer the default to be settable or to be the last used as with many other Protel dialogs. * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * 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 * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
Re: [PEDA] Too many hole sizes
At 01:37 PM 5/16/2002 -0700, Brad Velander wrote: Abd ul-Rahman, I agree with your general idea but suggest it is not practical with a most designs. Depends on how one tries to use it, doesn't it? The text size would have to be so small as to make it unreadable on anything but an E size print. How many companies even have E size plotters left hanging around these days? An E-size plotter is not necessary. The biggest problem is with small vias. Suppose we have a 25 mil pad with a 15 mil hole. The clearance is, let's say, 5 mils. So we have a 30 mil circle within which we can have text without any overlap. A small amount of overlap is acceptable, but I'll neglect that. If we are stating hole sizes in mils, there will be no more than two digits for such small holes. So we must represent two digits in 30 mils. I'm not testing it right now, but offhand I'd say that 15 mil text would accomplish the deed. Too small to read? Not. The print should be made at 2:1 at least. 30 mil text is readable if the resolution of the printer is good. But it would be better at 4:1 or more. Yes, if the PCB is larger than, say, 5 x 8, a 2:1 print will be larger than B size. But this is already a problem for inspection. In other words, inspecting the plots at 1:1 is not really practical, so they must be inspecting them at higher magnification. If the text size were not so small then you would have text overlapping text with equally illegible numbering. Most fab shops that I have dealings with would only be able to print B size docs and they don't typically supply CAD stations to inspectors. This also assumes that a print for an inspector must be one piece of paper originally. That is not necessary. Prints can be taped together. But the whole thing is a tad ridiculous. If the inspectors don't have a computer of any kind on which they could view a PDF or a gerber file (with a free viewer, if the company is really that cheap), then we have one weird company in this day and age. What is a drill drawing for? Some of us don't supply them at all! Once upon a time, drill plots were bombsighted, hence the use of target-like symbols. To my mind, the major remaining role for a drill drawing (which may double as a fab drawing) is for the designer's convenience. With it, he or she can quickly tell what a hole size is supposed to be. He or she will be able to view it at any magnification desired As for the number of drills, David's answer suggests that he has good reason for so many drills. Yes, it was acknowledged that this could be true. * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * 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 * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
Re: [PEDA] Too many hole sizes
At 08:16 AM 5/17/2002 -0700, [EMAIL PROTECTED] wrote: 4. It is good practice to provide fabricators with your whole design or at least the .pcb file because often slight corrections are necessary to be made just to adapt the pcb to their technologies, and let them generate files and reports they need. From an individual fabricator's point of view, this may be true, though the fabricator increases the risk of error by modifying design files, that is, the risk of error for which the fabricator will be held responsible, which could be very, very expensive. We have seen in recent threads where fabricators made incorrect assumptions about design intent. The raw PCB file, in my opinion, should not, under normal circumstances, be provided to the fabricator. It belongs with design engineering. Yes, fabricators may wish to make certain modifications in the files in order to end up with the nominal track sizes, for example, after the etch process behavior is considered. But this is a geometric modification and can readily be done in a CAM program, so the fabricator only needs the gerbers. The supplied gerbers should show nominal dimensions indicating the desired finished result, not necessarily what will actually be plotted. For example, I may specify an 0.028 hole and that is what will be in the PCB file, but the fabricator will probably drill the hole at 0.031 to allow for the thickness of the plating. So the fabricator will modify the files according to the needs of the fabricator's process, which may vary from fabricator to fabricator. If the relationship between the fabricator and the designer is close, possibly the fabricator might have the PCB file, but would not have the authority to modify it in a permanent way. Anomalies found by the fabricator should always be queried to the designer even if they seem easy to fix. One person's anomaly can be another person's special design condition. Abd ul-Rahman Lomax LOMAX DESIGN ASSOCIATES PCB design, consulting, and training Protel EDA license resales Easthampton, Massachusetts, USA (413) 527-3881, efax (419) 730-4777 [EMAIL PROTECTED] * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * 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 * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
Re: [PEDA] OT Too many hole sizes
At 11:08 AM 5/17/2002 -0700, Brad Velander wrote: I developed my undying adoration for Fab dwgs at one employer where we purchased our PCBs in various shops usually located in China, Hong Kong, Singapore, India or Korea. Try doing that without very complete and thorough Fab Dwgs. You (and your employer) won't survive long without Fab Dwgs. Reading carefullly, I'll agree with Brad. But what he wrote could be misinterpreted. Not all environments require fab drawings. A small engineering firm might have a relationship of trust with a fabricator who routinely does boards according to the fabricator's standard production. This is, in fact, quite common. Formal fab drawings take time to make, which means they cost money and a little time-to-market, perhaps. Obviously, if one is going to various vendors and trying to get the same product each time, one needs formal specifications. As to the matter of specifying finished sizes vs. drill sizes, I include the knowledge of plating thickness and how it affects hole sizes, as well as the allowed variation in finished size, in the design rules I set. Protel's default 10 mils is pretty naive, rarely is it the best setting, especially with, for example, power plane air gaps. I am giving the fab house a set of files which represent what I want. How they get there is largely up to them, unless I specify it. I don't want to nail them down to a particular drill size; exceptions to this would be rare, I can't think of any I've encountered. However, it is prudent to specify on any fab drawing that the holes are finished or as-drilled, whichever applies. I think fabricators are accustomed to seeing finished sizes in drill files, so sending them as-drilled sizes might toss them for a loop unless it is very clearly flagged. I haven't watched the actual process, but I would imagine that fabricators take the drill file and assign real drill sizes to the drill codes according to what they think their process requires. With finished sizes being specified, these drills would nominally be an average of 3 mils oversize from finished. * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * 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 * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
Re: [PEDA] Power plane questions
At 03:02 PM 5/19/2002 -0700, Embedded Matt wrote: 1. I placed an arc on the plane (my board is circular) to form a circle all the way around the edge of the board. The idea is to keep the plane away from the edge of the board. The assigned net for the arc is No Net. Is this the correct procedure for keeping the plane away from the edge of the board? Yes. The only way to blow out (clear of copper) the edge of the board for power planes is to place primitives to be plotted at the same time (i.e., on the same layer or on a merged mech layer). There is an annoying warning generated by DRC, however, that there are primitives on the plane layer. This warning is generated because the presence of such primitives, if unintentional and in certain positions, could break nets. Placing the edge blowout on a mech layer and setting the plane photoplot(s) specially in CAM Manager to merge with that layer would be a solution. Obviously, one must still be careful not to break nets with the edge blowout. 2. The arc is 50 mils wide. Since I placed the arc directly on top of the board outline, I expect to get 25 mils of clearance from the board edge to the plane. In general, is that enough clearance? Yes, it is conservative but it is also what I routinely use. 3. I have split the plane into multiple nets. The tracks that indicate the boundaries are 45 degree and 90 degree tracks. Recall I have an arc on my board edge. Because the 45/90 tracks and the arc are not compatible, the tracks extend outside of the arc to avoid tiny slivers of plane near the board edge. Is there a better way to do this? For example, can I define the regions with mostly 45/90 tracks but add an arc at the board edge to complete the region? Will the way I have done this likely confuse the board house? Not the board house, as long as the desired outline is clearly specified somewhere, but it might confuse DRC. I forget if arcs can be used for facets of the split plane polygons, but definitely one should use the polygons and not use free primtives, it was not completely clear to me what Matt is using. I do suggest keeping all plane split edges inside the board outline created by the drawn blowout. Since the latter is being drawn with a 50 mil track, which would be unnecessarily large for a plane split (I might use 20 or 24 mils), it is easy to bring a split to and into the edge blowout without taking the split beyond the nominal board edge. Small slivers on an inner plane would generally be harmless, I would not put a great deal of effort into eliminating them. However, if you leave only a very thin path between one part of a split section and another, this could be a problem. * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * 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 * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
Re: [PEDA] More Qs :)
At 02:35 PM 5/20/2002 +0500, Waheed Bajwa wrote: Whats a polygon good for? For filling an area of a PCB with copper. Also called a copper pour. Properly set up, the inside of the polygon will fill with copper (track) except for clearances as determined by the appropriate design rules around pads, via, and other primitives not belonging to the same net as the polygon. Also what are Gerber, NC Drill and Pick and Place files (CAM) Gerber: standard file format for photoplots. Gerber was originally devised to control mechanical photoplotters that drew with light by moving an aperture (an opening for light to pass through) over a film (actually, the film was usually moved, not the aperture, same difference; conceptually it was the aperture that was used to draw.). The original gerber used a separate aperture list; the early plotters only had relatively few apertures on a wheel. RS-274X gerber added more sophisticated commands and features, the most notable of which is embedded apertures, so that no extra aperture table is necessary. Protel will generate one anyway NC Drill: This is a file with tool (drill) sizes and positions, for controlling a Numerically Controlled drilling machine. The format is called Excellon from one of the manufacturers. There are also other formats. Pick and Place: A file with the position of all components and their rotations, for use with automated assembly (pick-and-place) machines. * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * 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 * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
Re: [PEDA] Too many hole sizes
At 10:36 AM 5/20/2002 -0700, Brooks,Bill wrote: Okay, I'll jump in... The PCB fab house can do what ever it wants to make the board.YOUR FAB DRAWING allows your company to ACCEPT/REJECT it if it does not meet your standards. Yes. Another reason not to specify as-drilled sizes. It is a lot harder to inspect Tolerances need to be specified for inspection. The FAB Drawing is the control document that protects your company. If you think of it that way you will not go wrong. There are still plenty of ways to go wrong. Note that Protel does not generate, in its .Legend table, tolerances. These will need to be specified separately, for a formal drawing. So, making a board without a FAB drawing is do-able, but it leaves your company no recourse to reject whatever they ship unless you have some accept/reject criteria specified for the material they ship to you, IN WRITING. That is usually defined in the Fab Drawing. Yes, the criteria could be defined in the Fab Drawing, but they could also be defined in a purchase order or attached document, which might refer to an industry standard. In the absence of a fabrication drawing, there is still protection for the buying company. First of all, the company will typically have the magic wand of simply not paying for bad boards. To keep its credit rating, it will, of course, need to formally document for the vendor its reasons for not paying. If a PCB does not meet generally-accepted standards in the industry, the common-law position would be, I'd think, that the customer would not have to pay. If, for example, there is a track on the Gerber and it is missing on the PCB, or vice-versa, that is clearly a manufacturer error unless the customer has approved a modification. The most common cause, in my experience, of serious disputes is where a fabricator failed to catch a relatively obvious customer error. This is, in fact, the customer's fault, and would still be a problem even if there is the most formal fab drawing in the world. Informal board purchasing is not all that unsafe UNLESS and UNTIL the quantities get large or the boards are very complex, i.e., very expensive to make individually. Most board vendors will bend over backwards to please customers, if there is any reasonable basis for the customer's complaint. Not all, but most, and you want to find out about the companies that won't! If a customer error caused a batch of boards to be useless, and it was an error that the fabricator might have caught in a decent inspection, a good fabricator is likely to make some compromise to lessen the customer's pain. Still, it doesn't take much to add critical information to the drill drawing to make it into at least a rough fab drawing. Perhaps some of us will make available standard fab drawings that they use If some are sent to me, I'll put them up on the protel-users web space. * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * 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 * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
Re: [PEDA] bitmap into PCB converter?
There is a free bmp to protel converter in the filespace for [EMAIL PROTECTED] To access it, one must be registered with yahoo as a member of the mailing list. There is another converter from a designer in New Zealand: -- from a 1999 post by Harry Selfridge. I don't know if Mr. Velthuizen is still charging for the program The product I have used for the past couple of years is PCBLOGO. It converts BMP files to Protel PCB files. It has all the best software features - it's cheap ($30NZ or $15US) and it works: PCBLOGO Henry Velthuizen ([EMAIL PROTECTED]) 104 Upper Fitzherbert Road Wainuiomata New Zealand At 12:09 PM 5/20/2002 -0700, Evan Scarborough wrote: Greetings Y'all, A couple years back I came across a little freebie utility called bmptopcb.exe and it was handy for getting logos onto PCB silkscreens, but I can't seem to find it again. It would run from a DOS command line and output a protel 98 pcb file that would easily import into 99se. What was nice about this one was that it kept solid areas of the graphic filled. I originally found the link to it on the Protel web site but I had no luck this time. Does anyone know where to find this or a similar utility?I'm looking for a freeware or shareware version not a time out demo. If anyone has one they can legally share you can send it to me off-line at [EMAIL PROTECTED]. I certainly appreciate it and thank you in advance! Thanks and Best Regards - Evan Scarborough _ Chat with friends online, try MSN Messenger: http://messenger.msn.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/proteledaforum@techservinc.com * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
Re: [PEDA] Schematic Port questions
At 12:16 PM 5/20/2002 -0700, Embedded Matt wrote: Two easy ones (I think): (1) I have a multi-page schematic with ports to connect nets between pages. Is there any way, besides adding a net label, to force Protel to give the net the port name in the netlist instead of something like R54_1? If you are using a hierarchical schematic, the net will take the name that it has on the highest level on which the net occurs. If the net is not named on that level, it will be given a numerical name. This is not a bug, it is, rather, a necessary consequence of how hierarchical schematics can be used. One may connect WR* on one sheet symbol to CHANNEL1WR* on another sheet symbol. Which name do you give it? Even if the schematic is not flat, suppose one is using Ports Only scope. Using a port, one may connect a net with one name on one sheet to a net with a different name on another sheet. In other words, Net Labels establish a local name (or a global name under certain circumstances, Ports connect between sheets. Ports are not used to name nets. If you are using Net Labels and Ports Global scope, you must place a net label to force the assignment of a net name. With this scope, you don't need to use ports at all But a little redundancy never hurt anyone. Why do I care about net names? Because descriptive names help me when I'm routing. Why don't I want to add a net label? Because then I have a wire with a net label and a port right next to each other -- it just looks silly. Nevertheless, sometimes this is absolutely necessary. (2) I am using the Reports/Add Port References (Flat) feature which works pretty well except that it doesn't seem to generate a reference for ports of the same name on the same page. Is there any way to get the references for ports on the same page? I haven't used that tool, so I'll let someone else answer Except I'll mention that this is not how Ports are designed to be used. They are specifically for intersheet connections. Bring a Port onto a sheet and if you want to use it in various places without having a wire, use multiple net labels. * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * 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 * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
Re: [PEDA] Place net name cross project?
At 11:03 AM 5/21/2002 -0400, Phillip Stevens wrote: Is there a way to get cross project net names (net names from all sheets in a project, not just the current schematic sheet) to appear in the place net name dialog box pull down list? Assuming that you have the panel displayed, with Browse Primitives set and Primitives set to Net Identifiers, push the Open All button at the bottom of the panel to open all sheets if they are not already open, check All in Hierarchy and push Update List. * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * 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 * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
Re: [PEDA] hidden pin problem
At 03:52 PM 5/21/2002 -0500, Robison Michael R CNIN wrote: hi bruce, oh! i used no name for them. and it went ahead and netted everything together, even across different packages and specific parts! i'll look into this. maybe i can name them and lose the bad net. I don't think so. Hidden pins are for power nets. Period. Some say they should not be used at all. Yes, hidden pins with no name will tie together into a net with no name If you name them, they become a net with the name you give them. If each one has its own name, well, this should work. But it would be a royal pain to manage. If a pin is to be hidden because you don't want it to show on the schematic and you don't want it to connect to anything, make the library part without the pin i hid the pins to more closely mimic the original schematic. i had to have them somewhere or else my footprints wouldn't sync up with the components. No, pins and footprint names are not connected. If a pin is missing from a symbol, it will simply be given no net when the net list is loaded or the PCB is synchronized with the schematic. Yes, if you have a pin on the schematic that is assigned a net, you will get an error when Protel tries to take the net information into the PCB, but the reverse is not true. Unless these pins are completely nonfunctional, i.e., not connected inside the device, it is poor practice to omit them from the schematic. Rather, they should be visible and a No-ERC directive popped on them to suppress the unconnected pin warning. So by trying to hide the pins, you are simply bending over backwards to reproduce what should probably be considered a mistake. If you don't try to conceal the pins, you can use standard schematic symbols and have that many fewer opportunities to make a mistake. * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * 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 * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
Re: [PEDA] Gerber to Protel, was Boardmaker to Protel
At 10:47 AM 5/23/2002 +0100, Ivor Davies wrote: I have just joined this list and have my first query. We have a huge number of PCB designs in Boardmaker (an old DOS package written by Tsien of Cambridge, UK) and require to import them somehow into Protel. BTW, there is a much newer version of Boardmaker. I do know that Boardmaker was interested in writing a Protel translator, but I think CAD companies generally avoid providing translators that translate *from* their own packages. It appears there may be legal issues with writing a proprietary file format; but there would be no such issue if the translator were a Protel server It has been suggested that the Gerbers generated by Boardmaker can be imported via Camtastic. How can this method recover the connectivity between layers? There is a lot of hand work involved, it is not just a matter of doing an import and then being done. How can the plot of a pad on one layer relate to an identically positioned plot of a pad on another layer? (or is Camtastic so fantastic that is knows that such instances are vias?). No, Protel is that fantastic, or, rather, a skilled designer driving Protel. Global edits make a lot of things possible. Here is a general procedure: Bring the gerber into CAMtastic; this step could be skipped if the gerber is compatible with Protel. CAMtastic output can be made compatible. (There are some tools in CAMtastic that might assist in the process, I have not explored them.) Bring in the gerber to Protel. You would ideally want to also bring in the drill data. I wrote a Tango utility that would import a drill file, looking for pads at the drill location. If it found a pad, it converted the pad (which starts out as a surface pad, being brought in from Gerber) into a through-pad with the appropriate hole. Since it is possible to import Tango to Protel, there might be a path to use here, but I'll assume that Tango is not available and one will manually deal with hole sizes. Visually identify footprints and create these footprints in Protel. You can select the pads of a footprint and copy them into a library footprint. Create a footprint for all different components on the board. If the footprint contains through pads, assign the pads the appropriate hole (which will be known from a drill drawing or from a CAMtastic import of the drill file). The holes should also be given the correct pin numbers. You'll need the Boardmaker net list to get those pin numbers, and also to check the finished list. It might be necessary to translate the list to Protel format, I have not researched this point. Once you have all the footprints. Take, say, the top layer of the board and place the footprints over the existing free pads from the gerber import. Identify the via pad size and globally select all the via pads based on pad size (and possibly on drill size). Use the Convert tool to give all these pads the appropriate hole size and then to convert them to vias. Select all remaining free pads on the design. Unselect any free pads you want to keep, such as mounting holes. Delete all the free pads. Keep your work at each stage, since you might easily make a mistake or run into some unanticipated condition and you might have to backtrack. Note that the top layer not only has all the pads but it also has all track and vias for that layer. Delete all pads on other layers. (I've described the import of a through-hole board; with SMT, one will merely need to place all bottom parts before deleting pads. I'd recommend building all the parts as top side parts; if there are bottom parts (footprints that are not used on the top of the PCB) I'd mirror the bottom layer and move it to a top layer (i.e., on a scratch PCB) before building the parts.) The track routing should be correct already. Complications: polygon fills if Boardmaker DOS had that; these could be left as drawn track, but if extensive changes are to be made it might be worth converting them to Protel polygons. split negative layers will require hand work to replace the split track with split plane segments. When the board appears correct, load the net list and verify. Fix any errors. * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * 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 * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
Re: [PEDA] TO3 footprint
At 09:26 AM 5/23/2002 -0400, Jeff Adolphs wrote: Good Morning! I have a TO3 schematic part with pins 1, 2, 3. The TO3 footprint has pins 1, 2, and two pin 3's. I thought this would work but the pin 3's do not have netnames in the layout. Do I have to use a schematic and footprint pin 3A and pin 3B? Let me guess. Mr Adolphs used Netlist Load instead of the synchronizer (Schematic/Design/Update PCB). There is a known bug in the Netlist Load routines which causes assignment oscillation: the existing assigment will change state between the correct net name and no-net with each successive load. The easiest fix is to use Update PCB, but if that is not available, as with a net list from another CAD Schematic program, making a fresh load after having cleared out nets will produce correct assignments. The command Design/Netlist Manager/Menu/Update Free primitives... will restore the free primitive assignments (i.e., track and via). Note that non-pad primitives that are part of footprints are also updated in addition to free primitives. A symptom of the problem is that each netlist load produces new macros, even though the same netlist was just loaded already. The macros oscillate the assignments. It is a good practice to reload the net list or resynchronize before beginning routing and after completing a design; if the only macros that are created are the oscillating kind, or no macros are created, the load can be cancelled. It would still be prudent to manually verify those pads. * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * 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 * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
Re: [PEDA] Hole annular ring
At 11:14 AM 5/23/2002 -0700, Embedded Matt wrote: I have placed a few pads on my PCB with the following properties: X size: 0 Y size: 0 Don't do that Round Hole size 147 mil Multi-layer Not plated These are supposed to be mounting holes. I get annular ring violations on these pads. Of course: your hole violates the annular ring rule that you have set. Should I not be using pads for mounting holes? No, you should be using pads. There are a number of solutions to this problem. (1) Make the pad larger than the hole by an amount which matches the *hardware* which will mount to the hole. That way Protel's clearance rules will ensure that you don't have mounting hardware shorting to track or vias or other copper. (2) Use a pad substantially smaller than the hole, even smaller than any other pads used on the board. It will be drilled away, it is harmless. It is unlikely to confuse the fabricators. But this will still generate an annular ring error. You could disable annular ring checking, but it might be better to create a special annular ring rule. If you give these pads a distinctive name, for example MH you can make the rule apply to Free-MH. But I have not tested how the annular ring rule works in a case like this, I almost always use the larger pad solution. I prefer (1) for a number of reasons: it checks the hardware clearance automatically, and it does not confuse the Protel DRC even if no special rules are written. * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * 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 * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
Re: [PEDA] Adding extra tracks and vias.
Another solution, besides those already given, is to use, in the footprint, through pads the size of vias and with the same hole size, given the same net as the SM pad. You will have complete DRC protection Another solution which might be better in some ways is to add a test point (single hole) part, one on each unused pin. Once one knows how to copy and paste, it would be very quick to add these to the schematic, one click per pad or even several pads with a single click. These will then be incorporated into the net list; an advantage is that they can each be given a number which can appear on the legend, making such changes easier to document and recognise. There are also ways to speed up the PCB side of this, but I won't go into detail now. Note that it is an advantage to be able to move the test or wiring points if routing requires it... You can move pads included inside a footprint by unlocking the footprint in the Edit dialog; but I'd prefer adding separate parts; the separate parts can be made into a Union with the flat pack to which they adhere, so they will move around together. At 11:10 AM 5/23/2002 -0700, Embedded Matt wrote: I'm working on a layout with two quad flat packs. A substantial number of pins on each chip have no connection. Because of the difficulty of hand-soldering to fine pitch pins, I would like to add a track and a via to each unused pin for possible use later. I'm have two issues: 1. DRC flags these extra tracks and vias as violations. 2. I get no protection from the design rules that specify minimum clearances and such. I think this must be a common problem. Is there an easy way to fix this without changing the schematic? Protel 99 SE sp6. * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * 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 * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
Re: [PEDA] Gerber to Protel, was Boardmaker to Protel
At 11:31 AM 5/23/2002 -0700, Brad Velander wrote: Abd ul-Rahman or others, do you know of a process using Protel V2.8 whereby you can read in gerber type data with a unique name applied to pads or vias of certain sizes. No. Then you can replace these uniquely named pads and via flashes with Protel pads vias through global edits? I don't recall the exact process but I did do it once under the guidance of someone who is not here anymore. We used to do this to return intelligence back to gerber flashed pads and vias in the Protel database. That typically just left tracks to globally edit to the correct layers. it's not perfect solution fo this problem but it did take care of multilayer type pad connectivity. First of all, if the plot layers are appropriately named, they will come in to the proper Protel layer. The difficulty with the process Mr. Velander has described is the hand-waving part: getting the file with unique names applied to pads. He mentioned vias, but vias don't have names If I have a file with pad names and locations, the spreadsheet can be used to bring those names into the pads; likewise, in the spreadsheet, the pads can be made into through-pads if appropriate; the spreadsheet can also be used to bring in drill data (it is not hard to turn a text drill file into a spreadsheet with locations and sizes, which can then be co-sorted with the pad data and merged). I haven't done a major gerber import in some time; but I did use the spreadsheet to assign names to a mass of pads. I was creating a footprint with about 1600 pads (for a MEMS array), and the thought alone of hand-entering all those names made me tired. I had a list of names and locations from the client The spreadsheet could also be used to offset the drill data, if necessary, to match the photoplots; but this can be done in CAMtastic, probably easier. I did just do that with some client gerber, but I was only making a panel, not taking the data into Protel (but I merged it with Protel data for the panel cutouts and holes, CAMtastic is fantastic for that, once one gets behind the weird and poorly documented user interface.) Supposedly this process only worked in version 2.8. Sorry I don't recall the exact process as I was guided through it only once for a very small project. At the time I was assured that it only worked in V2.8 and not any newer versions. As I said, the hard part is getting that file CAMtastic will generate a net list of sorts, that gives pad locations, so one could use the location as the name I don't think that would improve things much. Tango had a nice little pad naming tool that would assign a sequential pad number with a single click per pad. I've missed it quite a number of times, such a simple procedure that is missing from Protel unless I've overlooked it. * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * 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 * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
Re: [PEDA] TO3 footprint
At 04:29 PM 5/23/2002 -0400, you wrote: I fixed the TO3 by assigning only one pad as pin 3. Will multiple pins with one pin number work? Yes. Fully with Schematic/Update PCB, and with a known bug which is harmless once you know what it is with Netlist Load. I have not had a problem with Netlist Load as I force it to browse for the Netlist File not using the netlist it shows. The same bug is in AutoCAD 2000 for inserting a block ...the block does not get updated unless you force it to browse for the file. I think its a Windows type of bug. Am I wrong about this? This is not related. I will try to remember to use the Update PCB. Must I make sure the Rooms crap is turned off?? Yes. And if it loads rooms because you forget, it is fast to delete them. Get used to the synchronizer, it is the way of the future. Netlist load is a remnant of the old batch processing days. But we still need it for foreign netlists. * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * 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 * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
Re: [PEDA] Hole annular ring
At 06:19 AM 5/24/2002 -0700, Embedded Matt wrote: Thanks for all the help on this question. I think the best solution for me is to create a special rule for these pads as some have suggested. I also appreciate the information on non-plated holes. Let me just add that the reason that I wanted a size 0 pad is because we only put non-zero size pads around holes that will be used for grounding. Note that a pad sized substantially less than the hole size is functionally equivalent to a pad of zero size. This is why it was suggested, as one option, that a small pad be used instead of a zero size pad. Zero size pads are not guaranteed to function properly when encountered by various CAM and CAD programs. As for keeping things away from the hole, Protel has other ways I can keep things away from the hole without having to add a big pad -- again as some have suggested. Yes, there are other ways, but a large pad is the simplest and easiest and most straightforward. Personally, I would find another way to indicate ground pads, such as text. (In fact, in my opinion, such pads should actually be footprints and should be in the schematic, for several reasons. This can make the appropriate text almost automatic.) * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * 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 * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
Re: [PEDA] Gerber to Protel, was Boardmaker to Protel
At 02:03 PM 5/23/2002 -0700, Brad Velander wrote: Abd ul-Rahman, the naming is performed on the Gerber data (how I don't remember) such that you have a pad flash with unique names for each different size assignment. Then you can replace those assignments with a multilayer pad globally. I believe there was a manner of making the same thing work for vias as well. It is to bad that I don't recall how it was done because it is ideal for replacing pads (vias?) in the case of a gerber data load. You don't need to remember. The process is almost trivial in Protel, and I described it. But it does not give you pad numbers. There is *no* way to recover pad numbers from gerber unless one applies a great deal of intelligence. E.g., I can recover numbers for a DIP or SOIC (it may be necessary to look at the legend to know the orientation); this could be automated, but it would require something *much* more sophisticated than Protel 2.8, I'm certain of that. The process you described is simply a global edit. While it is possible for gerber to have two different D-codes for the same pad size and shape, I've never seen it and it would be only the result of a manual assignment of names; it could be considered an error, albeit a normally harmless one. So one will get, in the imported file in Protel, a unique size for a unique D-code. So you can globally convert those pads to through-hole pads as appropriate and the pad sizes that correspond to vias can be converted to vias (using the Convert tool, Selected Pads - Vias). The unique names for each different size are not necessary, but someone might create descriptive pad names to help in the process. Once again, the tool is Global Edit. I had simply hoped that someone on the list also knew of this process. I cannot recall the details from the one time I was walked through it by a person who is no longer with our company. We do know the process, and we have been describing it Now, if 2.8 has a pad renumbering tool like that in Tango DOS, this would speed things up, but it would still be a manual process to recover pad numbers. (And there is no way to guarantee that the numbers completely correspond to the original because there is no universal standard for naming the pads of some kinds of components, such as SOT-23s. Fortunately, it is not necessary to completely match the original, one must only match the schematic that one eventually produces, if there is one to be made.) But if you must find the original person, there is a fairly good chance that one of us knows him or her, if you can remember the name * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * 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 * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
Re: [PEDA] Unlocking Spreadsheets
At 01:14 PM 5/29/2002 +1000, [EMAIL PROTECTED] wrote: I just discovered another 'bug' fix for the spreadsheet editor. It always seems to default to locked and therefore any update you try to paste back from Excel (a usable spreadsheet package) causes a crash and suggests a reboot. That the default is locked is an irritating undocumented feature. That an attempt to paste into a locked spreadsheet causes Protel to crash is a bug, and a moderately serious one. It should be added to the bug database. (Bug List at http://groups.yahoo.com/group/protel-users/database , one must be a subscriber to [EMAIL PROTECTED] to access this database. While I'm at it, congratulations to Mr. Wilson for maintaining this file.) (I have experienced this or something like this many times, but I have not specifically verified the behavior on this occasion.) The problem can be overcome by going to : Options -Preferences and unticking Protection. Nice choice of defaults here Protel. Perhaps there is a way to change the default. I find no .ini file in my WINNT directory (Windows for W98 users) for the Spreadsheet Editor, unlike, for example, the Text Editor. Did I miss it? There is a command table (.ins) in the [...]Design Explorer/System directory, which does not establish defaults. There is an option in Spreadsheet: Options/Preferences/[allow editing:]Protection. One would think this has to be checked to allow unlocking the protection, but the on-line help and Mr Broom seem to agree that it must be unchecked. There is another setting: format/Protection/Locked which purports to enable or disable protection for individual cells or a selected block of cells. This is the command which will actually turn off protection. The setting does not appear to be persistent. * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * 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 * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
Re: [PEDA] Gerber to Protel, was Boardmaker to Protel
At 02:25 PM 5/24/2002 -0700, Brad Velander wrote: Abd ul-Rahman, no you are not describing the process that I was trying to recall. Trust me, your description in no way resembles the process, nor is your process limited to Ver. 2.8 is it? No, it is not so limited. The process, as Mr. Velander described it in his last post, is simple in Protel, all versions with global edit. Someone, however, might have written a script or other tool to automate this and speed it up. to recall what was written: the naming is performed on the Gerber data (how I don't remember) such that you have a pad flash with unique names for each different size assignment. Then you can replace those assignments with a multilayer pad globally. I believe there was a manner of making the same thing work for vias as well. It is to bad that I don't recall how it was done because it is ideal for replacing pads (vias?) in the case of a gerber data load. I could do this to a set of imported gerber files, if there was only one size via, in about one minute, except for the naming part, i.e., it is not necessary to assign names to accomplish the conversion to through-hole and vias; to add the holes would take longer, but the basic problem is determining what size holes go with what size pads. CAMtastic could make this reasonably simple, and there might likewise be another utility that would do it; to repeat, I did write such a batch utility for Tango, as I mentioned before. Perhaps Mr. Velander will more accurately describe what the program did, if this is not it. Earlier he had written: Abd ul-Rahman or others, do you know of a process using Protel V2.8 whereby you can read in gerber type data with a unique name applied to pads or vias of certain sizes. Then you can replace these uniquely named pads and via flashes with Protel pads vias through global edits? I don't recall the exact process but I did do it once under the guidance of someone who is not here anymore. We used to do this to return intelligence back to gerber flashed pads and vias in the Protel database. While this speaks of return[ing] intelligence, the intelligence is only pad shapes and via discrimination (pads and vias were much more specifically assigned functions in Protel 2.8 than in 99SE), and the unique name would probably be a name used for reference while deciding which sizes were pads and which were vias. The Query manager in the current version could select pads based on a size less than a certain value, which would, again, speed up the process. Protel 2.8 might have had a pad-renaming utility, Tango did, and this would greatly help in recreating the footprints and opening the way to net intelligence. It continues to astonish me that such a simple tool is missing from Protel. Basically, numbered pads, including numbers as pre or postfix, can be numbered, one click per pad, with controllable increment. But there is nothing that quickly and automatically recovers true pad names, it is a serious bit of AI to do so. But I might be missing something, of course. Don't worry about the original person who told me the process, as I said earlier, it was a former employee of Norsat. I know that nobody on the listserver knows him because he had never been on the listserver. The conclusion does not follow from the premise. I know lots of people who have never been on the listserver, plus there are many people on the listserver who never post, many more than do post, in fact. Further, many of our readers may not be paying much attention to this thread by now, it is still possible that someone knows this person. If he was ever listed as a contact for the license, Protel might have his name. * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * 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 * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
Re: [PEDA] Systematically find unwanted antennas
At 11:07 PM 5/28/2002 -0600, John W. Childers wrote: On a revision of a board, unwanted antennas can remain and must be found and removed. These are tracks that branch out from a net, but don't terminate on a pad, and can generate noise as electromagnetic waves, much like an antenna on a radio. Other than visual search, is there any systematic way to find them? Most stubs can be classified into two kinds: stubs which terminate at a pad and stubs which do not. The latter could fairly easily be found by analyzing spreadsheet data from a PCB; essentially one would be looking for a track which has an endpoint which does not coincide with any other endpoint on the same layer, nor does it coincide with a via or pad. Easy does not mean quick unless the utility has already been written As to stubs which terminate in a pad, a little more analysis would be necessary, but not so much as to become really difficult. However, there are certain kinds of stubs beyond this. For example, if a track connects at one end to a pad and then returns to that pad without connecting anywhere else, this would be a stub as well. Still, it would not be impossible to analyze a database to find stubs. Either Protel will add the tool at some time or a user will write a utility -- it does not have to be a server, though a server would be more convenient -- which would find and flag stubs. Some stubs might be eliminated by the autorouter; autorouter intelligence does encompass most if not all of what is needed to find stubs. I haven't tried it, but the autorouter might already eliminate some stubs, assuming that they are not locked. It seems to me that it once did. Note that connections made at other than pad or via or track endpoint center could make it more difficult to identify stubs And fills and arcs would add more complications * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * 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 * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
Re: [PEDA] New Netlisting Problem
At 01:41 PM 5/31/2002 +0200, Shahab Sanjari wrote: Sorry I was not at work due to an operation on my nose! we won't ask any nosy questions. But thank you all. As I stated, the problem occurs regardless of type or footprint. I will call this Remaining Netlisting Macros. Which means, after execute you see a very few macros still there in the preview changes box. Only when you change these macros in the Netlist manager manually, do they not aprear anymore. Intresting is that these macros asre not unique, several of the same type are done already. I had the same problem with another Protel SP(5), another project on another PC 7. The only common thing in between is me! due to which I think I have to revise my style since no other seems to have faced the problem before. Actually, I may have seen behavior like this. Oscillating macros, for example, will occur if Netlist Load is being used and there are duplicated pad numbers in a footprint on the PCB. I think something like this also happens if there are duplicated reference designators. Duplicated reference designators on the schematic, if not eliminated (pay attention to the ERC!), can produce two instances of a pin in a net or perhaps two different nets with the same apparent pin. Again, a symptom will be persistent macros. And I have seen some persistent macros where I was not able to identify the cause, at least not quickly. It seems to me that once upon a time I did figure out what caused this, but the knowledge, if my impression is even correct, has gone the way of all ephemera. * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * 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 * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
Re: [PEDA] Systematically find unwanted antennas
At 11:45 AM 5/31/2002 -0700, Brad Velander wrote: John, my personal thoughts on the spreadsheet method was that it would only work in the limited case where the track was only connected at one end. In my past I have found a great deal of stubs where this method wouldn't work because there were actually two tracks connected at both ends to tracks atop one another or just slightly misaligned atop each other. If the data is prefiltered to remove the extra track that is fully coincident, the remaining overlapping track will be detected Note that misalignment implies lack of endpoint coincidence (Two identical tracks, however, would cause each track to be considered connected, which is why eliminating the redundant track first would be necessary.) * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * 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 * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
Re: [PEDA] Solder and Paste Masks for Via in Pad BGAs
At 10:57 AM 6/1/2002 -0500, David W. Gulley wrote: I am doing some via-in-pad BGAs and need to figure out if there is a good way to provide the top solder and top paste masks while keeping the bottom solder mask and bottom paste masks off. I defined the BGA pads as multilayer since I am doing via-in-pad (sort of like it was a PGA) except I do not want holes in solder mask on the bottom and I do want holes in the paste mask on the top. I don't think it is a good idea to define any SMT pads as multilayer. There are several reasons, among them the possible buginess of the implementation (which is not unusual when a procedure is not the way people normally do things) Instead, as another suggested, use a surface pad plus via. I haven't tried it just now, but I have no reason to expect that this would be at all complicated..., beyond the known issue of providing netlist connectivity to the via through Update Free Primitives (if the vias are part of the footprint). * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * 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 * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
Re: [PEDA] Problem with Polygon Planes and Pads
At 04:49 PM 6/4/2002 +0300, EDA Software Technical Dpt. wrote: My PCB file contains Polygon Plane with 5 mils Clearance from the 18 mils pads. Ouch! 5 mils clearance from a plane is much more difficult to fab than 5 mils clearance between ordinary objects, because the plane clearance is *everywhere* within the plane. I would normally set a higher clearance for plane pours than for ordinary primitives (the Rules make this possible now, in Protel 98 it was necessary to pour with the larger clearance and then change the rules for the rest of the board). If I need to get plane track between pads and this requires 5 mils clearance, then I might add pieces of track to create the connections. Note that such connections may also be made with thinner track than one would otherwise use, since the failure of an occasional connection like that is not serious, provided that the connections are redundant. I'd more normally use a 12 or 15 mil clearance for polygons from pads, though one might go down from there, especially if the board has fine clearances in general; i.e., I might use 10 mils on a 6 mil board. When I create the gerber file the clearance ring around the pads on the plane appears to be polygonal at the Gerber file (small lines emulating a cicle) and not circular as it is on PCB. As another pointed out, we can now tell that you have software arcs enabled in your gerber settings. This causes the arcs to be drawn with straight line segments, instead of using the newer gerber arc command. NOTE: In the Polygon Plane properties dialog, at the ''Surround pads with'' option I have select Arcs instead of Octagon. Yes; if you selected octagons, they would be drawn with eight pieces of track. I try to convert the polygon plane to a set of primitive objects by selecting Tools » Convert » Explode Polygon to Free Primitives but the problem remains the same when I create the Gerber file. Right. It has nothing to do with the fact that it is a polygon, but only that the polygon pour routine creates arcs or octagons, you had it set for arcs (which is generally the best setting.) What I found is that the voids on a Polygon Plane are converted to the Gerber file as small polygon lines. You mean arcs, not voids. Other programs like Or-CAD, convert the Arc or the Circle exactly as Arc's or Circle's in the Gerber file without using the small polygon lines. Other recent CAD programs have -- or should have -- the option to do it either way, just like Protel. Is there a way or a workaround in order to solve this problem? As was stated by Mr. Hendrix, just change the setting of your gerber control file. CAM Outputs for / gerber file, default name Gerber Output 1/ rt.click/ Properties/Advanced/uncheck use software arcs I use software arcs, but that may simply be an old habit, besides being the default, if I am correct. * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * 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 * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
Re: [PEDA] negation character redux
At 11:02 AM 6/4/2002 -0700, Bruce Walter wrote: Anybody know if there would be a problem using a dash (minus sign) as a prefix? I think it works, but as another mentioned, WR will be sorted in a different place than -WR. Personally, I use an asterisk at the end, not because it is necessarily the best way, but because it worked in other CAD systems and continues to work with Protel. One could also use _not as a suffix, which would be totally explicit. And if some program has trouble with underscore, shame on the programmer! Unless you are going to use a program that has a trouble with backslash in a net name, which is understandable, using single negation to create a bar display is acceptable, but it likewise has the sort problem, or does it? * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * 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 * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
Re: [PEDA] Drawing Dashed Lines in Schematic
At 09:31 PM 6/4/2002 -0400, Mitch Berkson wrote: I'd like to draw graphical dashed lines in a schematic to indicate guard traces which should be placed during PCB layout. Is there a way to do this in Protel 99SE SP6? Others have noted how to place a dashed line, and also that such a line has no incorporated intelligence, it is only a note to the PCB designer. However, it is possible to go further than that. I assume that the guard traces are to be grounded, since they would be positively harmful if they were not. So one would place a jumper at the ground connection (whether this is at the driving end or the receiving end depends on the design, but if it is to be grounded at more than one end, it should be grounded *frequently* along its length to a solid ground, probably a plane). this jumper is what we have called a virtual short. There are two ways to implement it. (1) a jumper footprint can be created that has a gap of, say, 4 microinches between rectangular pads, and a design rule allows that particular footprint to have a gap of 2 microinches. If boards were always fabricated according to nominal values and to the limits of the technology (which is well above the microinch region), this gap would never appear on the finished boards. However, we have seen cases where round-off error in the gerber generation, coupled with poor control of the aperture assignment and other conditions, has resulted in a gap on the order of 1 mil on the gerber, which has then been opened by an assumption-making fabricator to a fabricatable dimension The technique is still useful, but one would want to ensure that the aperture assigned is rounded up, and this is enough of an opportunity for error that I now prefer the second method. (2) a jumper footprint is created that has a shorting bar placed on a mechanical layer. One of the copper layers is chosen as appropriate to which to add the short, and the gerber definition for this layer is eliminated from the CAM manager gerber control file (most of us only have one just file for a design). A different file is created by copying the first, and all other layers are eliminated from that file except for the copper layer in question; then the mechanical layer dedicated to the short is merged in photoplot with the copper layer. this additional CAM control file is given a descriptive name so that future generations do not become confused. (Note, however, that if the shorting bar is forgotten, it should be a simple matter to short the jumper footprint manually on the PCB, assuming that the short lives on an outer layer. I wish all design/fabrication errors were as easy to fix) The mech layer used for the short is also given a descriptive name, such as Top_Layer_Shorts. (Note also that if all the CAM files are checked for plotting and left that way, the copper layer with the short will routinely be plotted with all the other files; this is pretty much set-and-forget.) A combination of the two techniques *could* be used, which would leave it very unlikely that the gap would ever be present. Both these techniques fool Protel into thinking that the net to be controlled is isolated from ground; one controls the grounding point by controlling the placement of the short, which is highly desirable behavior. Protel does not have, unfortunately, a signal pair routing constraint, which would make this process even more controllable. But there is Tools/Outline_Selected_Objects, which would add the guard traces, which could then be selected with select connected copper and globally edited to the appropriate subground net (i.e., the apparently isolated net created by placing the virtual short on the schematic, which would likewise be given a descriptive name, such as DETECTOR SHIELD or the like.) After editing the outline to the appropriate name, the outline would be broken and the virtual short moved into position. DRC will then correctly check the routing. Similar techniques allow the creation and control of other kinds of subnets, such as star grounds, single-point connected analog/digital grounds, etc; also the process has been used to create RF components where copper is physically connected (at DC) but needs to function and be treated as if it were not. * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * 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 * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
Re: [PEDA] changing layer stack looses power plane connectivity
At 11:18 AM 6/5/2002 -0600, Gordon Price wrote: I decided to take a couple of layers and move them around from the way they were and delete one of two ground plane layers( both named GND). [...] I deleted one of the ground plane layers and replaced it with a signal layer. I also moved the layers up and down [...]. In other words, I shuffled the deck of cards, but have the same number of layers with the same net connection names. The auto router now can't seem to find either the GND named plane or the +3.3V plane,(even though they are there in the layer stack manager) and DRC reports a zillion unconnected GND and +3.3V nets. I think there are a couple of possibilities, but first things first: In the Layer Stack Manager, there are two relevant attributes to an internal plane, Layer Name and Net Name. (Highlight the layer and press properties). The two are not automatically connected In other words, you could have a layer named GND, but it might have no net assigned to it, or some other net. Before looking into other possibilities, the above should be checked; likewise one of the isolated ground sections should be examined. Presumably the pad in that section supposedly connects to GND through a via. What net is assigned to the pad, to the track, and to the via? They should all be GND. If they are not, probably Design/Netlist_Manager/Menu/(Update Free Primitives from Component Pads) should be run. I'll also mention the complication of split planes; Mr. Price did not mention these, so I'll leave that out of consideration for the time being * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * 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 * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
Re: [PEDA] how to expend DIGEST mode
At 10:19 AM 6/5/2002 -0400, Darryl Newberry wrote: I switched my list prefs to DIGEST mode, but was annoyed to discover that the digest is a hierarchy of attachments within attachments, to several levels. This means I can't search by topic, and it's ridiculously time consuming to find a particular posting. Is there a way to change this to a single flat email containing all the postings for the day? Subscribe to protel-users-PEDA-Archive mailto:[EMAIL PROTECTED] This list is an echo of the Techserv list, and you can set it for digest mode, which arrives as a single message with a list of message authors and subjects at the beginning, followed by the individual messages. I think that is what you want. However, the easiest way to get the list, in my opinion, is to simply filter all the messages into a single folder, which one can look at or not look at, as often or as rarely as one wants. * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * 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 * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
Re: [PEDA] Power Planes in Layer Stack
What does the Stack Manager show? What shows in the Design/Split Planes dialog? At 10:10 AM 6/6/2002 +0200, [EMAIL PROTECTED] wrote: I set up a board with 5 power planes; lateron I found out that by efficiently using split planes I could reduce them to 4. The obsolete power plane was named Internal Plane 4. So I deleted this plane and renamed Internal plane 5 to Internal Plane 4. All seemed ok, until I called the CAM manager and did Gerbers. Protel still produces 5 power planes, plane 4 being empty, and the real plane 4 still named plane 5. I found no workaround for that so far. apart from renaming Gerber files manually. * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * 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 * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
Re: [PEDA] Protel / MSoft
At 11:24 AM 6/6/2002 +0200, Rene Tschaggelar wrote: Complaining is one thing and acting another. While I tend to think the ATS period of 2k$ to be a bit short with one year, I also have to calculate what this investment brings. Note that the Protel web site now gives US$1495 as the value of the one year maintenance included with a current purchase of P99SE. So I don't expect ATS to be US$2000, in spite of earlier indications to that effect from Protel. 15% would be $1200, and 15% is fairly standard. It will probably be worth it *if* tool productivity continues to improve and serious bugs become an endangered species. Since I would not be surprised to see the full regular price of DXP move to $9995 within a year of release, $1495 would be right on the money. I am concerned, however, about the loss of the low end market. Protel was not the cheapest CAD system around, but it was priced so that most any serious designer could afford it. Accel Tango lost its original customer base by upgrading itself out of reach of many of them. By the time of acquisition by Protel, Accel was losing money, I understand. Coincidence? Definitely, as the tool improves, as it addresses more completely the needs of major users, the value increases; but an upgrade path should be maintained that would allow new startup or even hobby users to become familiar with the package at a price they can afford. I've written in the past that software piracy may, under many or even most conditions, not actually harm the company whose product is illegally used, it may even help. Piracy of software is not like piracy of hard goods, where theft represents real and direct loss; instead, an illegal user of software is not depriving the company of revenue *unless* he or she would have otherwise paid for the program. What is the company which sells the most pirated software? What is the largest and most profitable software company? I think the two are the same, and that this, also, is not a coincidence. My point is not that piracy should be allowed, but that piracy opens a path for a user who might otherwise not become familiar with the program; when he matures to the point where he will buy software, what software will he buy? A program with which he is familiar, or a program that requires him to relearn most everything? There may not be a lot of money, short-term, in the low-end market, but the long term picture may be different. For similar reasons, many software companies give huge academic discounts, to encourage students to use the software. * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * 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 * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
Re: [PEDA] negation character redux
At 06:05 AM 6/6/2002 -0700, Mira wrote: I just tried to debugg a board, which schematic was in Protel and the net names were RESET and RESET_. [...] Due to the way the net labels are attached to the wire in Protel, the underscore overlaps the wire and hardly could be seen. That was what I meant. Good reason to not use underscore as a negation symbol in a net name. But I think the suggestion had been to use a hyphen (or minus, same thing). This would not suffer from that overlap problem. I personally prefer the use of an asterisk, because of the sorting; otherwise I'd go for the slash prefix or the bar over (i.e., backslash in Protel) * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * 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 * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
Re: [PEDA] Splitting a design to two PCBs
At 12:10 PM 6/7/2002 -0400, Richard Sumner wrote: You might simply add the mating connector pair to the schematic, and run all required signals through both connectors. No net name changes needed. Everything else is done in pcb layout. You end up with one board design which is designed to break in two. You would wind up with some traces going right to the board edge (the lines between the 2 connector parts). To avoid this, delete these few trace segments after the board passes drc. Then you will get a few broken net errors. For this kind of application, one might create a dummy Mid copper layer on which these traces are placed. That layer is eliminated from the gerber plot set, in the CAM definitions, so it does not plot. But DRC will think that the boards are connected, so there will be no error created. However, my own preference might be to split the schematic and to design two separate PCBs. They could later be combined back into one board, which would be specially easy if the reference designators are not duplicated. Only if one wanted to fab both boards as a set on the same panel would the above be what I would suggest. To split the schematic, I would probably use hierarchical scope and handle the interconnections on the top level. That way, the whole project can be ERCd, etc., and the same schematic will be ready for final production. To make the two separate boards, the next level down from the top would consist of two schematics, I'll call them A.sch and B.sch, each one of which might be complete or it might be the top level of a lower hierarchy. By simply making a project out of each of the two schematics, one would have the separate schematic for each PCB. The sheet symbols for each sublevel would be placed on the appropriate A or B schematic. The connectors would also be on the A and B schematics, not on the top level; the top level would have only two sheet symbols and interconnecting wiring. For clarity, that wiring should be given descriptive net names, since in hierarchical schematics, nets are only named from the top level on which they occur. In the final combined version, the connectors would simply be deleted, unless one wanted to keep them or their footprints on the boards. * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * 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 * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
Re: [PEDA] Protel / MSoft
At 03:12 PM 6/7/2002 -0700, Brad Velander wrote: Not to argue with you Abd ul-Rahman but Protel customer service has specifically stated to me, a couple of times, with complete sincerity that common CAD maintenance programs are typically 20% - 25% in the industry. Cadence has been 15% for a long time, I think. I've been told for years that 15% was pretty much standard, I guess this was confirmed in my mind by the PADS maintenance, which is also 15%, as I recall. Maintenance that includes major upgrades ading entirely new capabilities might justifiably be more. However, Protel seemed to be charging, in the past, an effective maintenance of about 15%. The $2K upgrade from 99SE to DXP, as announced, represents about two year's period, so it is not entirely out of line with past practice. Essentially, they are making up for the free SE release. TANSTAAFL. ATS *renewal* is now stated as $1495. 15% would be $1200, so they have really only raised the bar a little bit. As long as they do not penalize users who delay upgrading or renewing maintenance, I think they may not be out of line. (A serious penalty would be a maintenance catch-up fee larger than the maintenance arrears. While it might be fair to charge the unpaid maitenance fees in order for a user to catch up, even that would, in my view, be more that would be appropriate; Protel sales has justified to me the complete devaluation of the P99 upgrade by the fact that those who upgraded earlier had the use of the more advanced program for all that time. (To explain this, right now a resale P98 license is worth almost as much as an older P99SE license. This is because the P98 license can be upgraded to 99SE right now for $1995, and this will include DXP no extra charge; whereas the 99SE license has the *same* upgrade price announced for DXP. In other words, those who upgraded from P98 to 99SE early will see the same total cost to get to DXP as those who waited until now. This is zero penalty for delay) It would be more toward parity if the upgrade from P99SE to DXP were, say, $1495, the same price as they have announced will be the ATS price. P99SE licensees have, essentially, already paid part of the upgrade cost, when they upgraded from P98 to P99 or P99SE (or paid the much higher new license price). At least that is how I would urge Protel to look at it. * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * 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 * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
Re: [PEDA] Room Properties (Colors?)
At 05:26 PM 6/7/2002 -0400, [EMAIL PROTECTED] wrote: I have just begun exploring the use of the Rooms feature, which is tailor-made for a current board. I notice that the crosshatching which indicates a room sometimes changes color, from a dark yellow to a dark red. This is an on-line DRC indication that there are Room violations, i.e., components not in a room to which they are assigned. Despite being pretty familiar with Protels oddities in the way of mouse click handling, I can't figure out what the pattern is. More directly, I would like to be able to turn off the hatching for the particular room in which I'm working, to better see what's happening there. I don't know a way to turn off only one room's hatching. However, you can turn off Room display. Tools/Preferences/Show-Hide/Rooms/Final-Draft-Hidden. I forget what draft does for rooms Also, I can't figure out exactly how the Interactive Placement - Place in Room is supposed to work, whether the parts are supposed to be selected, or the room, or what. As usual, the manual and the help text of of little help. Can someone here offer a basic tutorial on how to drive these things? I leave this for someone else to answer, I don't remember. But I do remember that it is not hard to figure out with a little experiment * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * 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 * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
Re: [PEDA] unused QFP pins
At 06:13 PM 6/7/2002 -0700, Dennis Saputelli wrote: i've got a 144 pin PQFP 0.5mm pitch there are only a small number of connected pins, maybe a dozen or so excluding power i am thinking about deleting a lot of unused pads to possibly open up top side routes and reduce inspection and bridging concerns am i crazy? Dennis, yes, you are crazy :-), but that doesn't answer the question Even crazy people sometimes have good ideas do you think the leads will short thru the solder mask to traces below? Mr. Selfridge gave a good answer, I think. But maybe the idea does not have to be completely tossed. is this good practice even if i don't run traces there, i.e. will it solder and align properly with missing pads? As an experiment, you might try this: Determine a set of pads that you want to solder, make it symnetrical so that the part will be firmly held. Maybe most pads would be soldered, or at least more than half. Do leave solder mask openings so that the extra leads are not stressed, but the openings might be reduced a bit. This *might* allow you to run a thin trace between the pads, but I wouldn't be on it. If it will not be enough to allow 1-thrus, I'd leave the mask openings the same as for the pads to be soldered. The only advantage of this, in the latter case, would be less possibility of bridging, but I don't know how much of a factor that is, anyway, my knowledge of current assembly criteria is somewhat in need of renewal In short, however, the whole affair is probably not worth the trouble, but ultimately that is an engineering question which I am sure you are qualified to answer with a little help from your friends. * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * 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 * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
Re: [PEDA] How To Set Defaults
At 07:39 AM 6/10/2002 -0700, Robert Ritchey wrote: This has probably been gone over before but I am just coming up to speed on 99SE. How can I set the default for the pad clearances and reliefs on the inner planes for split planes? Thanks, Design/Rules/Manufacturing/Power Plane Clearance Power Plane Connect Style. If no overriding rule is set, clearances are set by Design/Rules/Routing/Clearance Constraint. * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * 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 * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
Re: [PEDA] Equalize Net Lengths?
At 11:15 AM 6/10/2002 -0700, Joey Nelson wrote: The online help for matched net length rules seems to imply that if I set a rule for a set of nets and then run Tools-Equalize Net Lengths, that the shorter net will be accordioned to make up the difference, space allowing. But this does not seem to be the case. I've checked and the tracks are not locked, and there does seem to be sufficient space, but whenever I run Equalize Net Lengths, I simply get a design rule error. Is there some trick to getting this to work? It certainly seems like something the router should do, and I should not have to do by hand. The tool does not use the router. It will look for space to accordion a track according to the rules set. I can't tell what is wrong with Mr. Nelson's setup, but I can encourage him by noting that the tool *does* work, I've used it a number of times. The most likely cause of failure is insufficient space to add the meanders. They take more space than one might expect The meanders are added, if I am correct, one net at a time, so a set of parallel nets will *not* meander together; rather, one will be meandered and very possibly the second will not have room. But Mr. Nelson seems to be reporting that no meanders at all are created. One would normally setup a Net Class to which the nets to be equalized are assigned. The Match Lengths rule defines the parameters for the meander as well as the acceptable variation in length. If the tool cannot create meanders sufficient to bring the nets into compliance, yes, a DRC error is created. But I recommend experimenting with a very simple PCB with two nets. If you can get it to work there, you may then be able to get it to work on a more complex board. Someone else, of course, may have more experience with the tool than I I did, sometimes, create the meanders myself, relying on the Design Rule only for verification of net length match. * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * 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 * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
Re: [PEDA] How To Set Defaults
At 06:35 AM 6/11/2002 -0700, Robert Ritchey wrote: Hi, Sorry, poorly worded question. How can I set the defaults so that when I do a new PCB I always get what I want on these instead of 20mils as seems to be the hard-coded default. If you find out, let me know! By the way, I think the default clearance is 10 mils, 20 mils would be diametric oversize. I would like to be able to go through everything for a new PCB, set what I want as default and always have that come up when I start a new PCB. The simple way is to set up a PCB file just the way you want it, and import that file and rename it instead of simply creating a new file. Protel *should* have a control file with all the default values; I've never looked carefully to see if it does or if the defaults are coded into the program. Perhaps someone has. But the workaround is pretty easy. Yes, the default values are a tad ... different from what we would desire. For example, 10 mils clearance, on a plane layer. will result in a real clearance of 8.5 mils *nominal* because the clearance is from the hole and the hole is drilled oversize, a fact that Protel does not consider; nor should it consider it unless it takes into account plating thickness and allowable drill size and position error. Factor in drill size tolerance (say, +/- .005 on a large hole) and drill position error (depends partly on board size as I would expect and recall), and you might have a dead short. * Tracking #: 2D048E5397DE58488435624A783E5E8F0BEBE7A1 * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * 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 * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
Re: [PEDA] ''Access violation'' problem
I've never seen anything like this. However, this is what I expect I would do if I encountered this problem. I would immediately take steps to move existing backups to a safe place, where they cannot be subsequently overwritten. Backups exist in two places; in the designated autobackup directory and in the directory in which the .ddb lives. The autobackup is, as I recall, -- in the DDB system -- the whole database. Each file within the database, when overwritten, is normally backed up in the current (DDB) directory. I'd just copy all those files somewhere else, en masse, without worrying yet about details. Likewise the database itself. Now, to attempt to solve the problem: I suspect a trashed executable, so one of the first things I would do is to uninstall and reinstall Protel. I'd try it first in a simple way, and if that does not work, I would then move all the *99SE.* files in the Windows or WinNT directory to somewhere else (make sure the originals no longer live in Windows or WinNT), and then uninstall and reinstall Protel once again. If the problem still exists, I would write the PCB file as the ASCII database if the program lets me. Perhaps a pointer has been trashed and such things are not preserved in the ASCII form, which is human readable. I would then load this ASCII file. I might export it as well. If the problem persists, I would examine the ASCII file with a text editor to see what is going on. As I recall, components are assigned numbers in the component record; this number will then be used in the individual primitive fields. The ASCII database is easier to see and follow than to describe. If I can't recover the data in this way, I would start to look at backups, the latest first. Hopefully the problem was discovered before all good backups were overwritten One good reason to have a relatively long backup cycle, i.e., don't have one or two backups written every five minutes! It is possible that if the component records are intact but the primitives have been trashed, Update from the PCB library will recover them. But this is one of the last things I would try. And if that fails, I think I would be in for some tedious work to recreate my file. However, the very first solution, reinstallation, is quite likely to fix the problem. Just remember to get rid of the *99SE.* files if an installation without moving them fails to fix the problem, they will *not* be removed in the uninstall, and a new installation will respect them if they exist. If you have valuable customizations, you can then restore the files piecemeal until the bad file is found (like half of them at a time, keeping the good half and dividing the bad half again, etc.). At 12:54 PM 6/13/2002 +0300, EDA Software Technical Dpt. wrote: Before 2 days I create a new database with one schematic and one PCB file. Yesterday when I try to open my PCB file I realized that there were missing 9 components but I still had their designators on my PCB (with green color). Those components still exists at the Design Manager list. but when I try to edit one of them I got the following message: ''Access violation at address OE3D7BC6 in module ADVPCB.DLL. Read of address 0044'' If I try to jump to one of them I get a minimized PCB Editor. If I try to move one of them or their designators I've got the message : ''Access violation at address OE3D7BC6 in module ADVPCB.DLL. Read of address 0044'' Exception Occurred in PCB:( What ever the last command was ) Note:After any system crash... Ignore Quit I restarted PROTEL and I try to repair my database but I still got the problem. I try to UPDATE PCB from SCH but I got the same message: ''Access violation at address OE3D7BC6 in module ADVPCB.DLL. Read of address 0044'' Does anybody has any suggestions? I'm using 99SE SP6 with win2000. * Tracking #: 5A8B92A57C66764AB73B89928E2AEB1B4A92DE8C * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * 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 * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
Re: [PEDA] Gerber generation bug?
At 10:06 AM 6/13/2002 -0400, Watnoski, Michael wrote: When the Gerbers are generated without the 'Use Software Arcs' box checked, parts of polygon copper pours become complete arcs where they outline some pads. This is not a problem on the board design. These arcs short to adjacent polygons and tracks. It seems to work OK when the box is checked. I verified the Gerber files using Lavenier ViewMaster and LPKF BoardMaster and they look the same. I have not checked the ASCII output of the Gerber file yet, but I suspect that the angles of the included arc are not generated properly. Has anyone else seen this problem? It will be good to see the answer to Mr. Watnoski's question before going much further; I usually check the box out of long-standing habit (Tango did not even have a gerber arc output option, so all arcs were software arcs.) There may be some problems with variants on RS-274X, as one speculation, sometimes the standard is a bit unclear, it used to be positively ambiguous on the matter of polygonal pads, which is why Protel's octagon plotting is so defective. By all means, I would look at the output code, probably by exploding the polygon on a copy of the board file, deleting everything on the board but the relevant arc, and generating gerber, comparing the Protel arc parameters with those in the gerber. The RS-274X standard is at: http://www.maniabarco.com/transdown/rs274xrevd_e.pdf Abd ul-Rahman Lomax LOMAX DESIGN ASSOCIATES PCB design, consulting, and training Protel EDA license resales Easthampton, Massachusetts, USA (413) 527-3881, efax (419) 730-4777 [EMAIL PROTECTED] * Tracking #: 604CB06782BA634EACE8C1C68843AB771FDEAB1F * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * 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 * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
Re: [PEDA] ''Access violation'' problem
At 01:22 PM 6/13/2002 -0400, Matt Daggett wrote: Title: MDAC Drivers and ODBC Error Messages Date: June 6, 2002 Keywords: ODBC, MDAC Summary:Protel 99 SE uses the Microsoft MDAC drivers for the implementation of the design database storage system. Some versions of the MDAC driver work better with Protel than others. This application note will review some of the errors that can be generated when using an incompatible version of the MDAC drivers Unless I've missed something, the tech note does not relate to the reported problem. An Access Violation is not the same as on ODBC error. [Microsoft][ODBC Microsoft Access Driver]String Data, right truncated[null] I'm certainly not fully conversant with the issues, but it is a coincidence, I think, that both kinds of errors or violations have the word Access in them. In the subject case, Access Violation would refer to an attempt of the program to access memory outside the permitted range, and in the tech note, Access refers to Microsoft Access drivers (Protel 99 and 99SE use the Access database engine from Microsoft, and there can be version compatibility problems if one installs, MS Access as a separate program after installing 99SE. This one bit me most specifically * Tracking #: D702C2817A6AC845891F81615BAD25548BD2A658 * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * 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 * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
Re: [PEDA] Gerber generation bug?
I did not write what Mr. Watnoski attributed to me. Rather it was written by Mr. Elson in response to my own post. I did not think that the problem had anything to do with resolution, Mr. Watnoski was quite explicit in his first post that it was an arc rotation extent problem. The arc is correct on the PCB but is not correct in the gerber, as seen by several viewers. Mr. Elson's question about protel import was a good one, however. If Protel imports the gerber and the arcs are correct, we probably have a case of differing interpretations of the gerber code. It would likewise be interesting to see what CAMtastic shows. (CAMtastic is really an independent program even though it is now sold by Altium/Protel.) No one has come forward with a similar report. At this point, I will underline one of my first comments: it would be useful to see the Gerber output code. I described in my last post in this thread a means of obtaining a test PCB file that could be shared, and the gerber code itself, which would be only one or a few lines, could be included in a post. If we have a test pcb, a small file which shows the problem for Mr. Watnoski, it will be possible to verify the issue, or the converse, to show that the file plots properly for the rest of us. That file could be sent to me personally as an attachment, I could put it up on the protel-users filespace. *Don't try to send attachments to the list.* Bad Feng Shui. (For a long time, the list would forward attachments. Eventually, Techserv figured out that this put a huge burden on the mail server when someone attached a couple of megabyte file to a post, which then was copied to a thousand list members, plus it was poor security -- viruses and all -- and bad policy in general and turned the option off.) A possible workaround is to use software arcs, that is, check the box and allow Protel to generate the arcs as a proliferation of line segments. The only practical difference is the size of the gerber files, which will not be exhorbitantly larger with software arcs unless there are a *lot* of arcs If the problem still exists with software arcs, we have a bug or trashed installation on a whole different level At 02:49 PM 6/14/2002 -0400, Watnoski, Michael wrote: Greetings All, I am generating the Gerbers at 2.4 imp. The problem does not seem to be a round off type, rather the arc portion of the poured polygon around a pad continues for a full 360 degrees. I did not have to import the Gerbers back to Protel. I checked them with several independent viewers. I ran the Gerber generation several times while swapping from software arcs and back. The problem only exists when 'Use Software Arcs' in not checked. Michael Watnoski Abd ulRahman Lomax wrote: One thing he should try is to regenerate the Greber files at the highest numeric resolution (2.5). Roundoff errors could cause the described problem if the arcs were small. He doesn't mention whether importing the gerber files back into Protel shows the problem, or doesn't. That might be useful info. Jon * Tracking #: FFDE52F5867D3849AFE575C2EAB3D9620BCD8CAF * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * 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 * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
Re: [PEDA] Gerber generation bug?
At 01:00 PM 6/14/2002 -0700, Dennis Saputelli wrote: i can see the submil cracks in my defective virtual shorts quite easily in CAMtastic i would agree that it is a better tool for looking at gerbers than protel Just to note, Mr. Saputelli's problem with virtual shorts was due, as I recall, to roundoff error in the gerber generation. The cracks would *also* have been visible, I expect, in gerber reimported to Protel. My point about Protel being better in the submil region is that the display routines are more accurate, even if the gerber generation is a tad shaky at times. The Protel *database* has a substantially finer resolution than what CAMtastic stores, I think, and the display routines are pretty good (though they will sometimes show pixel cracks where none exist, but those cracks do not widen upon zooming in, and sometimes they even disappear at some zoom levels. * Tracking #: 9B6F3A185E8E7048AB780FCCD728F97049C52796 * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * 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 * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
[PEDA] The Protel-Users lists
As some of you know, I'm travelling this month to China; e-mail access may be difficult for me, besides, I'll be occupied with www.texturatrading.com/lucia.html David Gulley [EMAIL PROTECTED] has moderator privileges on *all* the Protel-users lists on yahoogroups.com (*not* this list on Techserv) and should be able to assist if needed. If anyone needs to reach me personally, the best address to use is [EMAIL PROTECTED] Lomax Design Associates mail ([EMAIL PROTECTED]) will be reviewed by a colleague who can handle design and other client issues. I plan to return before the end of July, when I will resubscribe to this list best wishes all. * Tracking #: 8181C11EB22B8845BB1FDA1E08FF65CE69A4EA8F * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * 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 * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
Re: [PEDA] Not DXP or P99SE, but have you seen the Cadence offer! !!!
At 02:49 PM 7/31/2002 -0400, Darryl Newberry wrote: BTW, anybody going to join Altium's DXP list? I have. I bet the real reason they are creating their own list is so THEY can filter and control the distribution. I highly doubt it. Gad, what a paranoid view of the world! The yahoogroups DXP list is open subscription, though they could change that at any time -- and they might, to avoid the autosubscribing spammers, not to prevent legitimate users from subscribing. If Protel used their position as owner of the list to prevent legitimate discussion, they would not be able to keep it secret because of this list and the other yahoogroups lists, it would be next to suicidal, really stupid, and they aren't stupid at all, not to mention *that* stupid. No, they simply responded to a user suggestion that a separate list be formed to deal with a more narrow topic that could otherwise overwhelm this list. I've done that kind of thing in the past and also met with some hostility, though the consensus has been, I think, supportive. I've written many times that I'd see this list as improved if it were to fracture into many lists, each one more focused, but with the provision that, ordinarly, subscribing to a main list automatically subscribed one to the subsidiary lists. I.e., opt-in for the main list, then opt-out for special topic lists. Those who were generally interested in Protel and wanted to read everything would get everything, i.e., it would be, pretty much, as things were when there was only the one Techserv Forum. Those who needed to cut down their mail intake could unsubscribe from the more specialized lists while still being able to get mail on the topics which interested them particularly (for most of us this might be a main user mutual tech-support list, which is the main function of the Techserv list at this time.) The Protel Users Association has a family of lists on yahoogroups, including a list used to make decisions as an association. The Association is not likely to start up a special list in competition with an existing list unless the existing list is being managed abusively. In other words, if enough of us agreed that the Protel-owned DXP list was unjusly censoring posts, we'd simply start our own, or we would simply ignore the Protel list and discuss DXP here, until or unless Techserv decides to shut that down. (Techserv is a private company, a service bureau, and is *not* controlled by Protel users, per se. But mostly they keep their hands off the list.) I prefer to bitch here in a public forum where the world can read about it. That strategy works for some people, or, more accurately, it worked once or a few times, so the person continues to repeat it, i.e., attempts to get better service or products by excoriating the company that provides it or them, and does not notice how rarely it works. More often, it is tilting at windmills which, by and large, tend to ignore all the shouting and continue to turn according to their own ideas. Complaining about Protel software in a public forum can be useful where a consensus develops among users as a result; where such a consensus has been developed and, particularly if it is formally expressed, we have seen Altium staff to be very, very responsive. It is not necessary as part of this process to consider them evil conspirators or incompetent boobs who are ruining the life of all us innocent people by inflicting junk software on us. It is not necessary for us to imply that their work product is junk or trash. If it were junk or trash, we wouldn't be using it! If someone really thinks that there is a better product *for the money*, I, for one, would like to know about it. However, mere bitching rarely results in such an expressed consensus, since bitching does little more than relieve some emotional pressure on the part of the complainer, thus there is *less* energy available for the work of actually facilitating change. As to Cadence, Cadence definitely monitors this list, though that does not mean that they necessarily use addresses here to promote their products. If they did, it would be a violation of list rules as they stand, though it would *not* be, in my opinion, spam. Spam is by definition, not targeted to an audience reasonably likely to have an interest in the product. Personally, if Cadence has offers, I'd like to receive them, though I would caution Protel users that (1) Cadence has a tendency to understate the true cost of ownership of the software in its promotions. For example, they advertised Allegro Studio at $10K at one point, I was seriously considering it. I did not find out until later that the price did not include maintenance, *and the purchase of a year's maintenance was obligatory, part of the deal, and it was $5K.* They've changed, I think, some of the policies, so this is just a head's up. (2) Cadence is not an open design system, and those of us who are
Re: [PEDA] AW: DXP Discussion
At 10:33 AM 7/31/2002 +0200, Gütlein, Ralf wrote: As I recall, 'to bag' by word means 'to put sth. in a bag'. In colloquial language this may stand for 'to snap' or 'to grab', but in different countries there may be different flavors of what it may mean. 'Abandon' makes also sense esp. if the bag is a garbage bag ;-) But I may be totally off the mark, as my native language is german... No, you are spot on. The noun, I think, is the original word, a bag. This noun usually refers to a flexible container, such as a grocery bag, but in usage it also has derivative uses, such as bag used in slang to refer to a person's preferred activities. What's your bag? I like to write about Protel. From this comes the action of putting a thing into a bag. So a bagger at the grocery store is so-called, and what she or she does is to bag groceries. We tend to put trash into bags, so to bag a thing becomes synonymous to trashing it, i.e., discarding it, but trash is also used to refer to severe criticism (it would not be used for constructive criticism), hence the meaning of bag that we encountered from Mr. Wilson. He could have used trash synonymously. We can bag Protel or we can try to improve it. It is true that, in some cases, bagging the program will lead to improvements, but, psychologically, people tend to respond better to constructive criticism than to perjorative denigration, and, for better or for worse, the staff at Altium is all human. Generally, once a person has become known as one who is generally and what might be called abusively critical, that person may not be heard any more by the people who can do something about the problem as well as will be those who are perceived as being friendly and supportive. However, even open and declared enemies can often give us the most useful criticism, thus Altium could be advised to listen well even to the most cantankerous critics, but that would be advice for Altium, not for us as Protel users. Abd ul-Rahman Lomax LOMAX DESIGN ASSOCIATES PCB design, consulting, and training Protel EDA license resales Easthampton, Massachusetts, USA (413) 527-3881, efax (419) 730-4777 www.lomaxdesign.com * Tracking #: 5F9B11A399519549A4C39E7B1E866407BB9918C2 * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * 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 * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
Re: [PEDA] Copper pours on outer layers
At 06:21 AM 7/31/2002 -0400, Frances Wheeler wrote: Question to smartest of smartest designers out there: She's too busy to read this list, so the rest of us will have to do. Copper pours of this size are poured last because they are time consuming. The pours can take 4 hours, and even longer if they are not right the first time. Question to any of the best out there.can we avoid a copper pour and merge a gnd layer to the top? Suppose the worst designer reading this list knows how to accomplish the task? Should he keep it to himself? To the question. First of all, the amount of time that a copper pour takes depends heavily on the settings. Since this is a pour for a no-signal outer layer (a very useful stackup technique, BTW), the pour might be a bit less complex than it would be otherwise. I'd use a relatively large pour track, perhaps 10 mils or maybe even larger. Pour pitch should be set to zero. Protel interprets this as a command to separate the tracks by exactly the track width. I.e., a maximum efficiency pour. It is generally not necessary to pour in more than one direction. If one desired pour track to pass between pins with a narrow width, it is not necessary to set the entire pour to that width. Instead. Make a pass-through pattern for a part and copy that pattern over the part with the pour already done. Protel will assign these copied tracks the proper net. Don't you love it when you ask a question and the answer comes back, Wrong question!? So, here is an answer to the question itself, just in case that pour is just plain too big to be practical: I was a Tango DOS user, and Tango did not have a pour facility, so I used film merge techniques. In fact, I literally wrote the book on this for Accel. I'll modify the process to match what I would do with Protel: First, route the ground (if that's the net being used) with track entirely on the layer to be poured. You may be able to use the autorouter to do this; since there are no signal tracks on the layer (other than via fanouts), the routing is trivial. This track is going to become the ties on the thermal reliefs around each pad, so you might want to extend the track beyond the pad. I could give a way to speed up this process as well, but that is not important in understanding how to make the merge. This process will satisfy DRC (with, perhaps, appropriate top layer width settings). It will be plotted in the positive. For the negative, you can't use a Protel inner plane for reasons that have already been given: the plane is created based on specified clearance from holes, and SMT pads don't even have holes, plus the thermal reliefs, if you specify them, will be based on relieving a round hole and pad, the external pad shape is ignored. What you want is a plot of the pads and vias, albeit expanded by a given clearance. You could use a padmaster plot, but there is no provision in such a plot for expansion. You could provide the photoplotter people with expanded flash definitions, but I'd rather see all of what is necessary incorporated into the board file itself, plus, perhaps, plot definitions (in the CAM Manager.) What works is a solder mask plot, since it is pad-based, and I think expansion can be controlled layer-wise. Paste mask would only clear the SMT pads. You may need to set up separate design rules for plotting the blowout negative and for plotting the actual solder mask negative, and enable the appropriate rule before generating the corresponding plot. I don't see a way around that, perhaps someone can think of one. Typically, on an SMT job, the solder mask settings would be substantially smaller (say, 2 to 4 mils) than what one would use for a plane blowout. (at least 10 mils) If you want to add blowout areas to the ground plane, I'd suggest using a mechanical layer. When the films are merged, the sequence of plotting is crucial. The negative must be plotted first to subtract copper, then the positive, with the connection tracks, must be added to it. I gave simple written instructions to the photoplotters and they never got it wrong. (Like Plot FileA negative, add Plot B positive.) I don't think that Protel allows us to control the plot file names; that is unfortunate, I've seen a number of frustrating situations arise out of this. Sure it is easy to rename the files, but the goal is a design that, next time, will photoplot the same without any special manipulation, i.e., opportunity for error). CAMtastic, I think, can be used to correctly view such merged plots. I used to use Tango itself, which, like Protel, imports its own gerber, to view the merges, but using a CAM program is a little better. Now, there is a complication. What about fanout track or other non-ground track on the layer? Using global edits, all non-ground track on the layer should be selected and copied to the blowout mech layer and then expanded appropriately. This part of the process is
Re: [PEDA] DXP NOT MADE FOR WINDOWS NT
At 10:20 AM 8/29/2002 -0400, Narinder Kumar wrote: Protel has no plan to run this new Protel DXP to run under Windows NT. Not a good thing Perhaps. Perhaps not. It is additional work, certainly, to make a program function properly under multiple operating systems. Windows 2000 could be considered to be the current version of Windows NT. Its cost is trivial compared to the cost of DXP. If Protel software is to run under multiple systems, and if it were a matter of choice, I think I'd rather see the effort go into Linux instead of NT. On the other hand, perhaps there could be good reasons for staying with NT instead of upgrading to W2000. However, a good place to discuss that, particularly if one wants a response from Altium staff, would be the DXP list. Altium people do read this list (techserv) but they, up to and including the top officials, have responded far more frequently on the DXP list. Abd ul-Rahman Lomax LOMAX DESIGN ASSOCIATES PCB design, consulting, and training Protel EDA license resales Easthampton, Massachusetts, USA (413) 527-3881, efax (419) 730-4777 www.lomaxdesign.com * Tracking #: C54A62434D9763439906223B9EFE6D8F6AB4D100 * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * 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 * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
Re: [PEDA] 45 degree pad problem !
The best way to learn is to make mistakes. To learn big, make big mistakes. (Of course that isn't the whole story!) At 12:29 PM 10/16/2002 -0700, JaMi Smith wrote: Even if it is done at gerber time, it may make a difference in how Protel defines the pad to the gerber file based upon whether it is encountered as part of the design or part of a component, either of which should be different than a fill which it will most certainly draw. There are a couple of misconceptions here. Protel does not understand RS-274X rotations. It has been recommended that this be fixed! Fills are normally created by using a flash. I.e., Protel treats a fill, which is always rectangular, as if it were a rectangular pad. It creates an aperture for it. However, because Protel can't rotate this, it must draw rotated non-circular pads. I do not recall how to control the draw width You can build up pads with fine draws if you really need them, as part of the library part, I've done this for critical RF parts. Yes, it's a pain As to whether or not it is necessary for a particular design, that's an RF engineering decision that is outside my realm. I'm told that it might be important in some cases. Abd ul-Rahman Lomax LOMAX DESIGN ASSOCIATES PCB design, consulting, and training Protel EDA license resales Easthampton, Massachusetts, USA (413) 527-3881, efax (419) 730-4777 www.lomaxdesign.com * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * To post a message: mailto:proteledaforum;techservinc.com * * To leave this list visit: * http://www.techservinc.com/protelusers/leave.html * * Contact the list manager: * mailto:ForumAdministrator;TechServInc.com * * Forum Guidelines Rules: * http://www.techservinc.com/protelusers/forumrules.html * * Browse or Search previous postings: * http://www.mail-archive.com/proteledaforum;techservinc.com * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
Re: [PEDA] [dxp] Control Thermal Reliefs by Area
At 10:26 PM 1/7/2004, Hamid A. Wasti wrote: Abd ul-Rahman Lomax wrote: In 99SE, this would be controlled by a Design Rule, and the choices for scope are Board, Footprint, Component/Class, Net/Class, Pad Class and Specification. I'm a little surprised not to see via there Look harder. It is there and always has been. It is located just below Pad Specification duh. as is the rest, i.e., Via Specification, Footprint-Pad, and Region. I overlooked the slider Now, in DXP, it seems to be a little more complicated. I looked and could not come up with a way to do it, so I gave up after wasting an hour. So much for the claim by the Protel sales person that if you are an experienced user of 99SE, there is absolutely no learning curve to be just as productive in DXP. I'd say that was puffery. A learning curve is involved only if you chose to take advantage of additional powerful features. Would you call that a blatant lie, an ignoramus telling the truth as he knew it, or in our politically correct world a poor victim of capitalist society merely taking liberties with the truth in order to earn enough commission to feed his family? I'd say somewhere between the second and the last, it can be hard to tell the difference (though I don't know if Protel salespeople get commissions). It is not entirely false, i.e., much of the basic functionality is the same, but enough functions have changed in some way to cause delay as one figures out how to do it in DXP. How much impact this has on productivity, I can't personally say, because I haven't pushed a job through DXP yet. But it will have an impact in the short term, I have no doubt. In real life, I'd ask the question on the DXP list, not here, if I wanted to get the fastest and best answers. What I was specifically trying to do in DXP was to have all vias connect to the planes without thermal reliefs. Well, I defined a via specification scope direct-connect rule in 99SE (unchecking all the specifications so that it applied to all vias), then I imported the board to DXP. I did get a rule with the same name, but the scope did not mention vias... just All. And I don't see via or pad scopes in DXP Power Plane Connection Style rules. What am I missing? (In 99SE, to reiterate, one may, for example, give free pads a PadName and then use Free-PadName in the scope, allowing one to control connection style and other characteristics like Solder Mask Expansion, pad-by-pad simply by editing the pad name. Or one could have one size of via that is, say, tented, and one size that is not.) The DXP way, as I understand it, would be to create a Query that selects the objects to be affected by the rule. I can create a Query that selects Vias with the Build Query command, but I don't see how to connect this with the Rule, the Query Builder button in the Rule window does pop up a query dialog, but the required options (Via, for example) are not there There has got to be a way. If I were trying to get a job out, having managed to get it designed in DXP and now I'm just trying to finish the details, I'd be fairly upset! (And, as I said, I'd ask on the DXP list. But my own motive here is to explore a bit what it is like to move to DXP as an old hand with 99SE, to find the rough edges.) And I'm not thrilled that the rule from the 99SE file did not survive import. (But maybe it did and I'm just not understanding what I'm seeing) * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * 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] * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
Re: [PEDA] Difference between Gerber file drill symbols and fabrication output print file drill symbols and inability to print either character or hole size drill indicators
At 08:00 PM 1/7/2004, you wrote: In Protel DXP, SP2 - After generating gerber files I select fabrication outputs - final to generate printed facsimiles of the gerber files. THE DRILL SYMBOLS IN THE PRINT PREVIEW ARE DIFFERENT THAN THE GERBER FILES!!! Irritating, I'm sure. The same symbols are used, but they are assigned to different holes! This is completely unacceptable. I thought maybe I could switch to characters as drill size indicators - this works fine for the gerber files, but when selecting fabrication outputs - final, it comes back with the same old symbols. I'd suggest, frankly, that you abandon symbols, and possibly also characters (i.e., letter codes). It is far, far easier to read a fabrication drawing -- for checking purposes -- if the hole sizes are actually printed instead of some code that requires you look at a chart. Letters are easier than symbols, and the actual size is even easier. Originally, symbols were used because they were designed to be bombsightable. I.e., the photoplots were digitized to create a drill file. That isn't done any more. The fabrication drawing, as far as the holes are concerned, has become merely a reference. So why not make it easy? (If holes are very close together, you may want to make the character size for the numbers very small, though there is little harm of they sometimes overlap, you should still be able to read them.) This means the only way to be assured I'm getting correspondance is to dxf out from Camtastic. This means I cannot print to Acrobat Distiller like I want to. Anybody had a similar problem?? and does anybody know of a way around it?? Consider the gerber files to be the true output, not some reference prints made from Protel. Then print the gerber files. You can do it with CAMtastic, or you can do it from Protel by importing the gerbers back into a file and printing that. I don't know if or why you can't print to Distiller from CAMtastic, but I assume you can from Protel. (I print to PDF Writer) Problems with assigning drill symbols have been around for quite some time. Protel does not allow control over this (unlike some cad systems which make the symbol part of the padstack) -- unless you want to dedicate a mech layer and incorporate drill symbols in your footprints -- and I do recall encountering some inconsistencies in the past. Assignment of symbols is, obviously, arbitrary, but one would think that they would be assigned according to the same procedure in photoplot generation and in printing, but it appears that they may not be. Each of the drawings would be correct, however, considered by itself, so I'm not sure why it is so important! * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * 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] * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
Re: [PEDA] [dxp] Control Thermal Reliefs by Area
At 01:58 AM 1/8/2004, JaMi Smith wrote: It would have been nice to be able to just select a single via, as it appears that you can do with pads. There are at least four ways, one of which you noted. As you mentioned, one can create a via different in diameter or hole size (better the former), and then use via specification scope. One can use the net to affect all vias on that particular net. (But one should probably have all vias set for direct connect anyway. That ought to be the Protel default. A situation would be rare where the best solution is to thermal-relieve a via.) One can use a free pad instead of a via; that way one can name the little beastie, and one can create as many varieties as you like. And one can define a region which is tight around the via. Back to the Area question, the Region seems to be the answer. Footprint won't work with a BGA, since most vias related to a BGA are actually free vias, which are part of the fanout, and not the Footprint. If the fanout is part of the library part, they should be affected by Footprint scope. If not, there might be some combination scope (i.e., Footprint = X and Via Specification). But, really, one ought to direct-connect all vias, I can't think of a reason not to do it. Now the only question is can I do this in DXP? I'd be astonished if it couldn't be. But it is not clear to me how to do it. The question really should be asked on the DXP list, but I think Mr. Smith, if I recall correctly, may have burned his bridges there For me, the matter of interest is that it is not easy to figure out how to do it in DXP. Maybe I should read the manual, a cursory scan did not pick up the needed information. I'm pretty sure that the procedure would be to define a Query that selects the objects in question. That I can do with Vias generically, which would solve the present problem. However, some of the possible scopes in 99SE seem to be missing in DXP, in the Query Builder (under Edit). There may well be some way to manually create them, but, again, this is already a fair amount of work compared to the few keystrokes required in 99SE. But the query in the Rule Wizard (Advanced/Start with a blank Query) has even fewer scope options than the already reduced set in Query Builder. I've suggested in the past that there be a user panel to provide suggestions and guidance to Protel as they chart the future of the software, and I know the matter was under consideration. The Query technique is a great idea, conceptually. But I don't think it was necessary to kill the old functionality in order to implement the idea, and a user panel would almost certainly have recommended keeping it, at least as an option, or would have otherwise ensured that (1) full functionality and efficiency was maintained, and (2) retraining was made relatively painless. The situation *should* have been as the salesperson claimed, and I see no reason why that could not have been done. It could still be done, not all the horses have left the barn. The user panel should be chosen by users; its function would be advisory; Protel would necessarily retain, however, veto power over nominations to the panel, though I doubt that users would recommend members for the panel who would necessitate vetos. (Veto would properly be exercised where there was a concern regarding non-disclosure; being a hard critic of Protel would not necessarily disqualify one, and, in fact, listening to the hardest critics can be very useful. But if a critic was so angry that non-disclosure or advisory process were threatened, yes, exclusion would be appropriate.) I do have ideas as to how users could *all* be represented on the panel if they so choose Imagine what it would be like if the company could communicate with its users as if they were a single customer. There are those who think this would be hard on the company, but, personally, I prefer to have intelligent customers who know what they want and who are also amenable to suggestions. They are much easier to please than a faceless crowd. * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * 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] * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
Re: [PEDA] [dxp] Control Thermal Reliefs by Area
At 01:58 AM 1/8/2004, JaMi Smith wrote: ... and while I too had never before investigateed the full list allowed by the slider, right there at the bottom is what I am looking for This is an example of why I consider it quite useful when I make a public mistake. I'm not entirely dim, at least not yet, and when I err, often there are others who have similarly overlooked something, and exposing it helps all of us. (I had been aware of the additional scope possibilities in the past, I had used them, I just didn't see them when I looked into it while writing my post) * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * 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] * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
