[PEDA] Problem with PLD Design (GAL16V8)
Hello, I have a problem with Protel 99 SE SP6. I have build an PLD Design with a GAL16V8. Nearly everything works correct with Protel but I cannot build a JEDEC-File. The Option is activated in the compiler setup ! When I compile one of Protels demo then a JEDEC-File will be generated for this demo. Does anybody know whats wrong ??? Posted from Association web site by: markus desgronte __ Sie surfen im Internet statt im Meer? Selbst schuld! Auf zum Strand: http://lastminute.de/?PP=1-0-100-105-1 * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * 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] Problems when pouring polygons
Hello everybody, we have some problems when pouring polygons. On our multilayer board the top and bottom layer should be connected to GND. For that purpose we have placed polygons on both layers. The polygons are connected to the GND net. The pads should be surrounded by arcs. Grid Size = 0.2 mm, Track Width = 0.22 mm When protel is pouring the polygon, we have rectangles around some pads. Also we have rectangular openings in the polygon itself! We have tried to fix the problem by using a different track sizes / track width. Some of the problems disappeared - but not all. Does anybody knows how to get rid of that problem? (We are using Protel 99SE SP6). Thanks, Florian * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * 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] Polygon connections
Hi guys can anyone explain this simple problem for me? On my current board i have several polygon fills for different grounds eg Gin Gout etc. All of the polygons pour over fine except one which point blank refuses to play ball. It won't even draw the outlines around pads, the polygon just dissappears like the net name is incorrect (remove dead copper is on). I have checked and double checked the net names but they are right. it does this even if there are no other polygons on the board. I have even tried removing all unnecessary rules etc. anyone else had problems like this? Rich Thompson * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * 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] Problems when pouring polygons
Which hatching option are you using - horizontal/vertical/90deg./45deg. ? I've seen small gaps in polygon pours which go away (or sometimes move!) depending on hatching option and track/grid settings. As you've found, it's sometimes a matter of trial and error to find the best combination. Regards Andy Gulliver -Original Message- From: Florian Finsterbusch [mailto:[EMAIL PROTECTED]] Sent: 05 September 2001 08:56 To: Protel EDA Forum Subject: [PEDA] Problems when pouring polygons Hello everybody, we have some problems when pouring polygons. On our multilayer board the top and bottom layer should be connected to GND. For that purpose we have placed polygons on both layers. The polygons are connected to the GND net. The pads should be surrounded by arcs. Grid Size = 0.2 mm, Track Width = 0.22 mm When protel is pouring the polygon, we have rectangles around some pads. Also we have rectangular openings in the polygon itself! We have tried to fix the problem by using a different track sizes / track width. Some of the problems disappeared - but not all. Does anybody knows how to get rid of that problem? (We are using Protel 99SE SP6). Thanks, Florian * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * 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] Problems when pouring polygons
Re: [PEDA] gerber gen troubles
On 05:41 PM 4/09/2001 -0700, Brad Velander said: Dennis, I think that something is hooped in your Protel. I do the sort of thing that you are talking about but have not seen the issue you have. Oh, hold it,stop the presses. Dennis, I believe that you may find that it is not regenerating the all the Gerbers. Could it just be re-exporting with a new date and time stamp, the previous Gerbers when it exports the newly generated Gerbers? Are you looking at the date and time stamps only or have you viewed the Gerbers and noted changes? I bet the export facility, exports everything in the internal DDB directory, everytime it is run. Rename the old Gerber files within the DDB directory and then do a test again, I bet it exports the old DDB cam files with their new name when you generate a new set of cam files. I am thinking that the export function just blindly dumps all the files contained in the CAM directory out to the external directory and the OS puts a new date and timestamp on them. Brad Velander, Brad, that was my thought, it might be an export bug rather than a gerber generation bug. Which ever - it sounds like a bug. As Dennis worked through - it can have disconcerting and worse results. So there ought to be a CAM option to clean the CAM folder first - or manually clean it before you re-run the CAM generator. If it really is an export issue is it pretty amateurish, don't you think. What thinking programmer would really feel happy that they had done their job well. It doesn't take much thought to figure that CAM output will typically be generated multiple times in the final stages of preparing a release. I despair sometimes. I am waiting for the day when engineering is really part of software engineering. Ian Wilson (I hope that I haven't just shot my mouth off over something unwarranted...still the comments can apply to some other part of Protel. Ahh, the luxury of being a consumer of a product rather than the producer.) Considered Solutions Pty Ltd mailto:[EMAIL PROTECTED] ABN: 96 088 410 002 5 The Crescent CHATSWOOD 2067 Ph: +61 2 9411 4248 Fax: +61 2 9411 4249 * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * 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] Polygon connections
Hm. I restarted my machine and it still did it but, if I closed the database and restarted my machine and it is now fine. *#%;! protel. Thanks anyway people. Rich -Original Message- From: Richard Thompson Sent: 05 September 2001 10:58 To: 'Protel EDA Forum' Subject: Polygon connections Hi guys can anyone explain this simple problem for me? On my current board i have several polygon fills for different grounds eg Gin Gout etc. All of the polygons pour over fine except one which point blank refuses to play ball. It won't even draw the outlines around pads, the polygon just dissappears like the net name is incorrect (remove dead copper is on). I have checked and double checked the net names but they are right. it does this even if there are no other polygons on the board. I have even tried removing all unnecessary rules etc. anyone else had problems like this? Rich Thompson * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * 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] Problems when pouring polygons
On 09:56 AM 5/09/2001 +0200, Florian Finsterbusch said: Hello everybody, we have some problems when pouring polygons. On our multilayer board the top and bottom layer should be connected to GND. For that purpose we have placed polygons on both layers. The polygons are connected to the GND net. The pads should be surrounded by arcs. Grid Size = 0.2 mm, Track Width = 0.22 mm Try using a grid size of 0 mm (yes zero). This places tracks so they just meet. It may improve the pour. Also, are you using 90 hatching, as Andy Gulliver pointed out? I wonder as well if it might not be worth trying a pour with imperial measures rather than metric, some metric measures can not be represented exactly in the unit scheme used by Protel. Also, the track and grid you are using is quite fine. Does it need to be this fine? I usually use a track size of 15 or 20 mil (about 0.45mm) and then use fills and track segments to bridge into areas that would be dead copper, based on the poly clearance design rule and the largish track size. It is a fiddle, but I have not seen the problems you noted. I have seen some other odd pour effects including outline tracks outside the poly area if a via is at particular (small) distance from a 135 degree corner in a fill. If you find out what gives can you let us know, sounds like another poly bug to me.. Ian 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] Gerber clearance violations not found by Protel DRC
I have had this very problem when I had metric and inch mixed and the gerbers were done in 2.3 format, I then changed to 2.4 or 2.5 and the same file produced usaeble gerbers. So now whenever I have something with primitives smaller than 10 and 10 I use 2.4 or 2.5 format. Roundup error will kill you when your at clearances of 5 mils. Rob * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * 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] Process Identifiers
creatures. Sadly to say, there is no right-thinking about it, though I would not suggest any such solution, either. Perhaps there is a third, like: Tools-configuration-menu Or like Microsoft does and right-click menu bar then select customize in the context sensitive menu. Rob * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * 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] 3d Solids Modelling pkg
Tomorrow I hope to wear my Power Shorts ;-) depending if Tomorrow's day is sewn onto the tag Although, it is starting to get cold here in New Hampshire as Autumn approaches brr I was planning on going with solid works... but I was also planning on building a timber frame house in the next year and need to start the design. Solidworks will export (with some post processing translation by their cad package) to the files used by the automated timber cutting machines at the company I hope to go with -chris -Original Message- From: Don Ingram [mailto:[EMAIL PROTECTED]] Sent: Tuesday, August 28, 2001 6:18 PM To: Protel EDA Forum Subject: [PEDA] 3d Solids Modelling pkg P.S Nice to see that at least Chris Mackensen had his 'virtual sense of humour' with him when reading the 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/proteledaforum@techservinc.com * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
Re: [PEDA] gerber gen troubles
thanks! i never thought of that in fact i never looked at the internal files at all, ever yes was only looking at time stamps i will check this out and report back Dennis Saputelli Brad Velander wrote: Dennis, I think that something is hooped in your Protel. I do the sort of thing that you are talking about but have not seen the issue you have. Oh, hold it,stop the presses. Dennis, I believe that you may find that it is not regenerating the all the Gerbers. Could it just be re-exporting with a new date and time stamp, the previous Gerbers when it exports the newly generated Gerbers? Are you looking at the date and time stamps only or have you viewed the Gerbers and noted changes? I bet the export facility, exports everything in the internal DDB directory, everytime it is run. Rename the old Gerber files within the DDB directory and then do a test again, I bet it exports the old DDB cam files with their new name when you generate a new set of cam files. I am thinking that the export function just blindly dumps all the files contained in the CAM directory out to the external directory and the OS puts a new date and timestamp on them. Brad Velander, Lead PCB Designer, Norsat International Inc., #300 - 4401 Still Creek Dr., Burnaby, B.C., V5C 6G9. Tel. (604) 292-9089 direct Fax (604) 292-9010 website www.norsat.com -Original Message- From: Dennis Saputelli [mailto:[EMAIL PROTECTED]] Sent: Tuesday, September 04, 2001 5:14 PM To: Protel EDA Forum Subject: Re: [PEDA] gerber gen troubles anyone noticed: when you hit F9 to make gerbers it makes ones that you have previsouly selected but have currently deselected very aggravating and a potential source of trouble scenario 1 (i dbl checked this) made a simple bd, plotted and reviewed in camtastic made some changes and decided not to make a top overlay unchecked top overlay, and there it was made anew anyway, checked file dates etc could not make it stop producing what it first produced yes saved and reopened the .cam file scenario 2 (worse) 4 layer bd w/ paste masks, extra assem note layers, pik place etc every time we replotted it made all new files of all the types including the drill and pik files which were specifically unchecked wiped the folder clean (external copy on hard drive, we never use the cam output in the DDB, what good is that anyway?) tried again with only gerbers checked, no drill, no pik it made them all again of course this has the effect of overwriting the pik files which had plotted differently at another iteration we renamed the PCB (the only PCB in the DDB) and ran the F9 it properly prompted for a target board since the former one no longer existed selected the board and it then made TWO sets of Gerbers with the both old name and the new name! 47 files in all, all made in one pass, all in the same folder more bush league behavoir IMHO Dennis Saputelli -- ___ 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] 3d Solids Modelling pkg
Hi: We also don't do much 3D modeling. So we picked up TurboCAD. It's a little clunky, but it will do everything we need. Another alternative that you might look into is AutoCAD Lite. Regards, Scott Oliver From: Don Ingram [EMAIL PROTECTED] Reply-To: Protel EDA Forum [EMAIL PROTECTED] To: Protel EDA Forum [EMAIL PROTECTED] Subject: [PEDA] 3d Solids Modelling pkg Date: Wed, 29 Aug 2001 08:17:57 +1000 Hi All, We are looking for a 3D cad pkg for generating components enclosures etc for product design. $7K is a bit steep for us for Autocad or Solidworks given the frequency of use. ( at least for now ) Does anyone have any suggestions on a useful package that lives a bit further down the price scale, but is not a complete dog. I accept that you get what you pay for so we are attempting to locate a happy medium. Cheers Don P.S Nice to see that at least Chris Mackensen had his 'virtual sense of humour' with him when reading the post. ;-) - Original Message - From: Richard Bruer [EMAIL PROTECTED] To: 'Protel EDA Forum' [EMAIL PROTECTED] Sent: Wednesday, September 05, 2001 6:11 AM Subject: Re: [PEDA] None Rather than putting down a regular keepout, put down a couple of layer-specific keepouts (on the outer layers). Richard Bruer, P.E. Chief Engineer Instrument Division American Magnetics, Inc. 112 Flint Road Oak Ridge, TN 37830 Phone: (865) 482-1056 Fax: (865) 482-5472 mailto:[EMAIL PROTECTED] http://www.americanmagnetics.com -Original Message- From: Evan Scarborough [mailto:[EMAIL PROTECTED]] Sent: Tuesday, September 04, 2001 3:55 PM To: Protel EDA Forum Subject: [PEDA] None Greetings all, Is there a way to set up a design rule so that the defined keepout areas only affect the outer layers (other than ignoring or turning off online DRC)? I am routing an 8 layer pcb and the surfaces have rather complicated keepout areas for a metal frame that mounts flush, but internally I have no need to stay out of these areas but I can't seem to convince the DRC that this is so (and I'm not sure I want to see what the autorouter does with this - it'll be bad enough with a 680 pin 1mm pitch BGA). Any help is appreciated! Thanks Best Regards - Evan Scarborough www.e-cadds.com _ Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp _ Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * 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] Diode pads
In the mean time, the following perl script could translate those A and
K to numbers (I assume the choke is from an alpha character and not a
numerical pin number)
**Note** I do not know what file you are *actually* sending to the test
engineer that is choking so this script may not completely fit the bill...
save an original copy of whatever file you are using
#!C:\perl\bin\perl
#hash symbols are comments in perl, however, the line above
#does have significance and is not necessarily a comment..
#this should replace all pin occurances of A with 1 and K with 2
# means get the filename on the command line as arg1, open it,
# slurp it, and run it through the while loop line by line
while ()
{
#note: each line of the text file is stored in a hidden
# variable called $_ inside this loop, each
# time through the loop
# perl regular expression search and replace operator:
# s/_replace-string_/_with-string_/_operators_
# search and replace operates on each line as stored
# in the hidden variable $_
# replace a 'dash A' pin with -1 (g in the _operators_
# means do this globally on this line)
s/-A\w+/-1/g; # \w means word bounary i.e., a comma, space,
# non alphaword character, etc.
# The '+' means, match one or more times (for the
# word boundary)
s/-K\w+/-2/g;
print;
}
this is really a 4 or 5 line script that usually takes only half a minute or
so to write (without all the comments). This could be considered a throw
away script with potential to beefed up to be part of finished process for
passing files back and forth to the fixture...
save this file as myScript.pl (in this example... or whatever your heart
desires)
to invoke the script, install perl (www.activestate.com... perl for win32...
or www.perl.com for unix), run the script as follows...
C:\perl myScript.pl AKNetlist.txt AKNetlist_fixed.txt
if you want to get more complicated (like remembering which pins were
changed such that you can go back from the test fixture back to the original
file etc., or to tweak the script for the *actual* file you send to the
fixture, let me know)
Cheers,
-chris
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
Sent: Wednesday, September 05, 2001 11:01 AM
To: Protel EDA Forum
Subject: Re: [PEDA] Diode pads
Hello all,
I just had our test engineer come and complain that his test software chokes
on the use of A and K for diode pad identifers. I have used A and K for
15 years and know many others that use the same convention. I assume it
originated so there is no confusion with C meaning collector. No matter, the
test software they use is called CBTEST in conjunction with GenRad. They
have not moved up to the new version which is Navigator and I hope that this
will be resolved, but in the mean time. Has anyone else run into this
problem and have any comments on the diode convention.
Your input would be greatly appreciated.
PS My test engineer is from Nortel, so this may be my problemhaha.
Lloyd Good
Engineering Systems Co-ordinator
GE Substation Automation Systems
2728 Hopewell Place NE
Calgary, Alberta, Canada
T1Y 7J7
Tel: (403) 214-4777
Fax:(403) 287-7946
email: [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] Diode pads
Lloyd, I never use the A, K, or E, B, C, conventions myself. I stick to numbered pins. Many years ago (on another CAD package) I had seen some problems and issues with alpha designated pins and just ran away from them as fast as I could go. Today I set out a convention for diodes with pin 1 as Cathode or Anode (depends on the CAD system and the company past history) and go from there. Same for transistors. In a lot of cases I build special diode or transistor symbols just to take care of the myriad of packaging options. More symbols in the library to manage but it avoids some of the stupid wrong symbol, wrong footprint problems with discrete semi devices. Your test engineer is from where? Nortel? Never heard of them, who are they, what do they do? Are they one of those penny hi-tech stocks? 8^ Brad Velander, Lead PCB Designer, Norsat International Inc., #300 - 4401 Still Creek Dr., Burnaby, B.C., V5C 6G9. Tel. (604) 292-9089 direct Fax (604) 292-9010 website www.norsat.com -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] Sent: Wednesday, September 05, 2001 8:01 AM To: Protel EDA Forum Subject: Re: [PEDA] Diode pads Hello all, I just had our test engineer come and complain that his test software chokes on the use of A and K for diode pad identifers. I have used A and K for 15 years and know many others that use the same convention. I assume it originated so there is no confusion with C meaning collector. No matter, the test software they use is called CBTEST in conjunction with GenRad. They have not moved up to the new version which is Navigator and I hope that this will be resolved, but in the mean time. Has anyone else run into this problem and have any comments on the diode convention. Your input would be greatly appreciated. PS My test engineer is from Nortel, so this may be my problemhaha. Lloyd Good Engineering Systems Co-ordinator GE Substation Automation Systems 2728 Hopewell Place NE Calgary, Alberta, Canada T1Y 7J7 Tel: (403) 214-4777 Fax:(403) 287-7946 email: [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] Creating/implementing IC socket PCB decals
At 08:56 AM 9/5/01 +1000, Ian Wilson wrote: Abd ul-Rahman, I agree with your comment that it can be depressing when you are told not to do something rather than how...but... I agree completely with: We take the view that any socketed items are actually part of a higher level assembly than the PWA (printed wiring assembly). The PWA includes just the items that are run through the soldering process. Any extra things like ROMs or socketed protection components appear on the next higher level assy parts list. We use the Sch as the primary source for the PWA parts list but this has extra bits added, like the PCB. We usually do not try to include all PWA bits in the Sch, but I am aware that some people do. Doing this would certainly be easier if we had Sch symbol and PCB footprint attributes to prevent them being involved in synchronization and to be ignored during netlist import - as has been discussed recently. I want to underscore the point that in nearly every case the PCB is itself a component belonging to a higher-level assembly. And the unstuffed board belongs on the BOM for the assembly. That a Protel schematic will generate a BOM is a tool properly used in two ways: (1) For an informal environment where BOMs are not necessarily complete, or (2) to generate data which can be used to prepare a formal and complete BOM. We have seen posts on this list as to how to transfer the Protel Schematic BOM data to other programs. Trying to prepare a formal and complete BOM in Schematic would be like trying to use Protel PCB for architectural drawings. You can do it, but not if one wants to make a living at it! [...] As for the original question, what about: 1) Create socket footprint with all the pins/pads, but a minimum of overlay 2) Create IC footprint which is just overlay/silkscreen (no pins/pads) 3) Position together on PCB carefully 4) Create a union to ensure they move together Yes. This is a very good way to do it. It also applies to other parts. For example, one may make a heat sink footprint and unite it with a power transistor, or a light pipe footprint and unite it with an LED. 5) Pressure Protel to allow correct handling of negative component clearances to allow for overlapping components, I have an yone else want to add a voice Yes, the component clearance rule needs work. This should be added to the bug database. I consider it a bug because most designers work with some footprints that would normally have zero clearance on the outline when placed (and because the outline has a line width, this becomes overlap). Some outlines are designed to be butted up against each other when packed on-grid. (i.e., the outline includes tolerances). So the existing component clearance DRC is often unusable. http://groups.yahoo.com/group/protel-users/database (one must be a member of [EMAIL PROTECTED] to access the database, and a log-in is required and at least a session cookie accepted, I think.) Please do not post directly to the bug database but submit bugs or suggestions to Mr. Wilson: [EMAIL PROTECTED] [EMAIL PROTECTED] Abdulrahman Lomax Easthampton, Massachusetts USA * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * To post a message: mailto:[EMAIL PROTECTED] * * To leave this list visit: * http://www.techservinc.com/protelusers/leave.html * * Contact the list manager: * mailto:[EMAIL PROTECTED] * * Forum Guidelines Rules: * http://www.techservinc.com/protelusers/forumrules.html * * Browse or Search previous postings: * http://www.mail-archive.com/proteledaforum@techservinc.com * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
Re: [PEDA] Problems when pouring polygons
At 09:56 AM 9/5/01 +0200, Florian Finsterbusch wrote: On our multilayer board the top and bottom layer should be connected to GND. For that purpose we have placed polygons on both layers. The polygons are connected to the GND net. The pads should be surrounded by arcs. Grid Size = 0.2 mm, Track Width = 0.22 mm First of all, set the grid to zero. I also recommend using imperial units for the track width, though I am not sure that this will make a difference; it's just that the Protel internal database is imperial so you might get a slightly better pour. When protel is pouring the polygon, we have rectangles around some pads. Also we have rectangular openings in the polygon itself! Something like this is to be expected under some conditions. For some reason the pour routine is unable to place the fill tracks; if an arc is missing, any opening left will be rectangular, if one has 90 degree hatching selected. Mr. Finsterbusch did not state his setting for the minimum primitive size. If this is too large there will likely be missing primitives. This would only get worse with a fixed grid size. A minimum length of zero seems to work fine. However, under some conditions this could result in too many pour tracks and I would not be terribly surprised if Protel crashed. I leave it at 1 mil. One could make it smaller than that. Try setting hatching style to No Hatching and turn off Remove Dead Copper. This will show you only the pad clearance outlines and the outline of the polygon. With this setting, polygon pour will surround each pad with an arc or octagon (octagons may reduce plot size if software arcs are used) *if* the clearance rules will allow it. The grid size has no effect on this. If you are not getting an outline around a pad, there are two possibilities: (1) your clearance rules will not allow it. (2) there is a bug. I think I have seen some circumstances where the pour outlines are incomplete, but it is difficult to reproduce and I don't have an example handy. Number (1) is the most likely cause. Try placing a line or arc primitive where you think a missing primitive would be. Assign it the GND net. Does this create a clearance violation? If so, no wonder the pour does not complete the fill! Then, if hatching is turned on, fill track will be added. This track is *on grid*. If your grid setting does not meld well with the pad placements, some fill tracks will be missing, causing rectangular holes in your pour. For this reason, set the grid to zero. Protel properly interprets this as meaning fill gridless. This is generally recommended, it should be the default setting! There is little reason to use cross-hatching (90 degrees or 45 degrees) when grid is set to zero and a very small primitive length is used. It will just add extra lines. Note, however, that lines which are precisely butted up next to each other can display a very fine gap, either in PCB or in some gerber viewers. That is not real, it is a display artifact. But if one is not willing to tolerate the appearance of this false gap -- it should not be on the film -- then using cross-hatching will eliminate it. That may be a better solution than using a pour grid and a slightly oversize track. There are other possible causes for missing track. For example, there might be a layer-specific keepout primitive that is invisible, or some other rule interaction. Note that there are design rule clearance settings for polygons which are in addition to the other clearance rules. (Most designers would prefer larger clearances on polygons than elsewhere on a layer because the polygon clearances are everywhere and thus more likely to cause fabrication or soldering problems.) If the cause of the problem is not found, I recommend creating a small file that shows the problem. (Edit down your existing file). This will help Protel, but before sending it to Protel, submit it to me or to another user who has indicated a willingness to look at it -- don't attempt to send it to the list!) If there turns out to be a bug here, we can then add this to the bug database. [EMAIL PROTECTED] Abdulrahman Lomax Easthampton, Massachusetts USA * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * To post a message: mailto:[EMAIL PROTECTED] * * To leave this list visit: * http://www.techservinc.com/protelusers/leave.html * * Contact the list manager: * mailto:[EMAIL PROTECTED] * * Forum Guidelines Rules: * http://www.techservinc.com/protelusers/forumrules.html * * Browse or Search previous postings: * http://www.mail-archive.com/proteledaforum@techservinc.com * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
Re: [PEDA] 2 P99 quirks
Brad Velander wrote: Jon, your DXF problem is not so strange at all. Because of the complexities of differing DXF versions and different tools generating the DXFs, reading them into Protel can be real hit and miss. For example, I have one DXF that reads perfectly into P98. Reading the same file into P99SE a bunch of features are jostled all around the area and the file makes no sense whatsoever. With DXF always try using ACAD version 12 or at least 13 DXF first. If it doesn't work you can try reading those into P98, doesn't work then you can try V2.8. If all of those fail then I usually try running it through Camtastic before importing into Protel. Well, I discovered that reading it into 2.8 works perfectly for my application. it is just a lot of fooling around to get simple info into Protel, though. Thanks, Jon * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * 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] the letter i in gerber, was 2 P99 quirks
Abd ul-Rahman Lomax wrote: Indeed, with the default font, the dot on the i is missing in gerber. It also disappears in draft display mode. I looked directly at the gerber file; there is no attempt to draw the dot. It is not a case of a zero-length draw. I know this is correct, as my photoplotter will produce zero-length draws, and the dot does not show up. I made a crude temporary fix on the front panel artwork by putting a tiny arc right over the letter's dot, and the plot came out right. Hopefully, this is a fairly simple fix to the text-to-vector conversion routine that they use. Jon * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * 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] Diode pads
Brad Velander wrote: Lloyd, I never use the A, K, or E, B, C, conventions myself. I stick to numbered pins. Many years ago (on another CAD package) I had seen some problems and issues with alpha designated pins and just ran away from them as fast as I could go. Today I set out a convention for diodes with pin 1 as Cathode or Anode (depends on the CAD system and the company past history) and go from there. Same for transistors. In a lot of cases I build special diode or transistor symbols just to take care of the myriad of packaging options. More symbols in the library to manage but it avoids some of the stupid wrong symbol, wrong footprint problems with discrete semi devices. UGH! THe problem is there is no standard on transistor packages for which pin is 1,2,3. There are so many different packages. Also, there is no standard for the E,B,C order. When you have two things that are both not locked to some standard, it gets pretty confusing. Now, if you rigorously create a schematic part and a PCB part for each component, so that if you have 200 standard transistors you use, you also have a matching set of 200 schematic components and 200 PCB footprints that have matching pin numbers, that will work reliably. But, when you select a schematic part, it is possible to specify one that can be bought in several different packages. This is where it gets confusing. I use the EBC (or GDS) pin label, generally cause the schematic part to display the pin labels as an assurance that the schematic part will export those alpha labels to the netlist, and then use a modified PCB footprint that has the pins labeled with the appropriate alpha names. I find, at least for the way I do things that I end up having to twist transistor leads a lot less with this approach than with the numeric method. Jon * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * 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] Altera 144Pin TQFP Landing Pattern
Re: [PEDA] Gerber clearance violations not found by Protel DRC
Good to here that your issue is solved Ken. Yeah you have to watch that Gerber round off with 2.3 data format these days. It is becoming more and more of an issue with smaller parts, tracks and off-grid routing. Many years ago I ran into this for the first time, since then I adapted the standard rule of using 2.4 data, someday possibly I will see the need for 2.5 data on soft PCBs before I retire. Brad Velander, Lead PCB Designer, Norsat International Inc., #300 - 4401 Still Creek Dr., Burnaby, B.C., V5C 6G9. Tel. (604) 292-9089 direct Fax (604) 292-9010 website www.norsat.com -Original Message- From: Ken Pelic [mailto:[EMAIL PROTECTED]] Sent: Wednesday, September 05, 2001 1:22 PM To: Protel EDA Forum Subject: Re: [PEDA] Gerber clearance violations not found by Protel DRC We re-generated using 2.4 format and our gerbers now match our Protel PCB. Thanks to all for your feedback, especially to Rob and Brad V! Ken Pelic * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * 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 routing nets and poly pours...and maybe a bug for the bug list?
Phillip, looking at just your comment below, seems that you had accomplished your task. However, it sounds like you did not assign the correct netname to your polygon pour or you did not check the pour over same net checkbox in the polygon pour control, when you made that attempt. Brad Velander, Lead PCB Designer, Norsat International Inc., #300 - 4401 Still Creek Dr., Burnaby, B.C., V5C 6G9. Tel. (604) 292-9089 direct Fax (604) 292-9010 website www.norsat.com -Original Message- From: Phillip Stevens [mailto:[EMAIL PROTECTED]] Sent: Wednesday, September 05, 2001 1:23 PM To: Protel EDA Forum Subject: [PEDA] Not routing nets and poly pours...and maybe a bug for the bug list? Not seeing a direct way to do this, I tried a few things like making rules for VCC/GND nets to be 0 width traces. If you do this, when you do the pours, you get whatever the clearance is on both sides of a 0 width trace, so you end up with holes in the poly pour around a 0 length trace. In a way what I told it to do I guess, but not what I really wanted... Anyway, I finished my board. Wanted to report the router bug, and ask if there is a more direct path I can use for this next time. ---Phil * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * 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] Diode pads
At 01:23 PM 9/5/01 -0700, Brad Velander wrote: With your method, which works just fine, I find that having EBC, GDS or AK on the schematic is just too stupid and redundant. Who needs it? Well, EBC etc. is explicit, whereas 1,2,3, etc. depend on additional context. If you have to work with other people, it is much less likely that an error will be made if the letters are used. Is pin 1 of a diode the anode or the cathode? There are two reasonable ways to think about it, and I have seen both. I not uncommonly receive net lists from clients and I don't have the schematic. If the pins are numbered on a transistor it can be a real nuisance to resolve. If the pins are lettered appropriately to indicate function, the intention is crystal clear even if I have to mess with the pad names. As to stupid and redundant, redundancy is *intelligent.* Far fewer errors are made when information is redundant, because contradictions stand out. But if you don't want to see the letters, you can simply suppress their display. That's what I normally do for diodes. Now, if it is stupidly redundant to display the *letters* for a transistor, it is only *not* redundant to display the *numbers* because the numbers are not explicit. In other words, to avoid redundancy, one has added another level of complexity, i.e., the correlation between numbers and pads or pad functions. The assignment of numbers to these parts is quite arbitrary, as many of us have discovered to our chagrin. However, for transistors and especially for FETS, I prefer that the names of the pins be displayed. Sure, I know what pin is what function from the symbols, but I am less likely to get confused with redundant information, and using names or abbreviations is simple and cannot cause confusion. Numbers are only appropriate (1) Where the numbering proceeds from the physical layout of the part, preferably according to an industry standard. And I've been bitten on this one more than once (I once laid out a DIP relay -- creating the symbol and footprint -- using a catalog photo of the part, and on the top of the relay was an explicit pinout diagram. Very nice. What I could not read on the catalog photo was that the diagram was a bottom view) (2) Where they are arbitrary and swapping them makes no difference. As with a resistor. (3) Where using letters would make no improvement because there are no standard, readily recognisable names for the functions. The majority of parts most of us use fall into category 1, i.e., DIPS and SOICs etc., and some early CAD systems could only handle numbers, which, I think, is the only reason we think that using numbers for polarized parts is acceptable. [EMAIL PROTECTED] Abdulrahman Lomax Easthampton, Massachusetts USA * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * To post a message: mailto:[EMAIL PROTECTED] * * To leave this list visit: * http://www.techservinc.com/protelusers/leave.html * * Contact the list manager: * mailto:[EMAIL PROTECTED] * * Forum Guidelines Rules: * http://www.techservinc.com/protelusers/forumrules.html * * Browse or Search previous postings: * http://www.mail-archive.com/proteledaforum@techservinc.com * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
Re: [PEDA] Not routing nets and poly pours...and maybe a bug for the bug list?
At 04:23 PM 9/5/01 -0400, Phillip Stevens wrote: How does one specify a Net not be routed, but still be checked for in the ERC? I have a pretty simple 2 layer board. 2 X 2.7 with a few parts on it. I'm using P99SE SP6 on Win98 What I wanted to do was to route all the signal lines first and then poly pour VCC/GND. (This is a simple, low speed, low cost, 2 layer design btw..) If the design is so much low speed that you need not pay attention to power routing topology, then it is so much low speed that probably doing pours is unnecessary. The same arguments apply to both! Not seeing a direct way to do this, I tried a few things like making rules for VCC/GND nets to be 0 width traces. If you do this, when you do the pours, you get whatever the clearance is on both sides of a 0 width trace, so you end up with holes in the poly pour around a 0 length trace. In a way what I told it to do I guess, but not what I really wanted... Mr. Velander inferred from this, I think correctly, that Mr. Stevens had not set pour over same net, which would have accomplished what he wanted. A *direct* way to not route VCC and GND would be to delete the nets using the Netlist Manager. Then resynchronize the PCB and schematic But I would suggest, for a board like this, unless there is some condition which has not been explained, that power and ground be routed *first*, manually, which is the only way you are going to get a good low-impedance power route (it might not be necessary, but it won't hurt, for sure), then route the signals (and if this is a very small design one might skip the autorouter anyway, but to each his own...), then do ground pours. Don't do a VCC pour. It's been noted that there is no ground but there sure is when one is considering possible shorts to a case or what can happen with a careless screwdriver. Then I tried making the trace width impossibly large. It's a 2 X 2.7 board, so I made the (min/max/pref) trace width all 5. That way it can't _possibly_ route those nets then I'll just do the poly pour over it... The router happily placed 3-4 VCC/GND tracks down on the board. At maybe 50-100 mil width. This has to be a bug? The router should not put down tracks that fail to meet the design rules? Hmmm, a designer considers the program's behavior a bug; perhaps the program would have the right to call the designer's behavior a bug! Feeding a program data which is outside what would have been thoroughly tested is a good way to discover unanticipated results. If it works, great! But don't be surprised when it doesn't work! Another way to prevent the routing of a net, with a through-hole design, is to create an inner plane for the net But there was no good reason I can see to prevent the routing of those nets. The pour, if one insists on having one, can then be poured over the existing nets. The only problem with this is that there will likely be extra copper ties to the pour, which is harmless but unsightly. If the original track is highlighted -- which could be easily done with a global edit of track with the appropriate net as a selection criterion -- and then deleted, this would quickly clean that up. I also tried net unroute, but this seems to just take out a segment of the net, and not the whole net (though I think this may have worked in the past). Even had this worked though, the traces would not have been as direct as they could have been without the VCC/GND nets in the way. And since it is a low-speed design, why care about that? [EMAIL PROTECTED] Abdulrahman Lomax Easthampton, Massachusetts USA * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * To post a message: mailto:[EMAIL PROTECTED] * * To leave this list visit: * http://www.techservinc.com/protelusers/leave.html * * Contact the list manager: * mailto:[EMAIL PROTECTED] * * Forum Guidelines Rules: * http://www.techservinc.com/protelusers/forumrules.html * * Browse or Search previous postings: * http://www.mail-archive.com/proteledaforum@techservinc.com * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
Re: [PEDA] Diode pads
On 01:23 PM 5/09/2001 -0700, Brad Velander said: With your method, which works just fine, I find that having EBC, GDS or AK on the schematic is just too stupid and redundant. Who needs it? They are not on the Sch, they are hidden. In my case, at least. I hide pin numbers and names on simple components. We use EBC, GDS, AK (and things like A1/K1A2/K2 etc for series diodes...) works well for us. But doesn't clutter the SCH as the pin names and numbers are hidden. We have had to buy reversed pin versions of some SOT-23 in the distant past. One stuff-up was enough for me. Ian 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] Altera 144Pin TQFP Landing Pattern
Use my QFP generator, just enter the dimensions provided in Altera's Device Package Catalog. Sites: Altera package specs - http://www.altera.com/literature/ds/dspkg.pdf Just copy this link location into your internet explorer address bar: ftp://ftp.point-lab.com/quartus/Public/ProtelUsers/ Take these 2 files: QFPfootprintGeneratorScript.bas - Protel ClientBasic script. QFPfootprintGeneratorScript.txt - added documentation. enter: 36, 22, 0, 36, 22, 0.5, 0.27, 0.75, 1, 2, 0.04, 0 for Altera's 144 pin TQFP If you want a thinner footprint, minimal pad meat, change: 0.27 - 0.22 0.75 - 0.60 Goodluck. Brian Guralnick - Original Message - From: [EMAIL PROTECTED] To: Protel EDA Forum [EMAIL PROTECTED] Sent: Wednesday, September 05, 2001 4:21 PM Subject: [PEDA] Altera 144Pin TQFP Landing Pattern | Hi, | | I need a landing pattern for Altera p/n EP1K30TC144-2. The package is a 144 | Pin TQFP package. | | I typically use the recommended landing pattern from the manufacturer; | however, Altera only provides the physical dimensions of the part itself. I | attempted to use the land pattern calculator, on the IPC website, using these | dimensions, but the pad size was clearly calculated incorrectly (one | dimension of the pad was the width of the entire part). | | At this point, I think I'll return to the IPC website to isolate my problem. | I'd appreciate learning how others handle this situation. | | Thanks, | Steve Allen | | | | * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * 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 routing nets and poly pours...and maybe a bug for the bug list?
On 04:23 PM 5/09/2001 -0400, Phillip Stevens said: How does one specify a Net not be routed, but still be checked for in the ERC? I have a pretty simple 2 layer board. 2 X 2.7 with a few parts on it. I'm using P99SE SP6 on Win98 I have not tried it but, under the Design Rules|Routing|Routing Layers rule, add a new rule. Specify Net scope and then disable all the layers. This should prevent the routing routing this net. What I wanted to do was to route all the signal lines first and then poly pour VCC/GND. (This is a simple, low speed, low cost, 2 layer design btw..) If you specify Pour over net then it should not matter if the router has routed the nets - you can still pour the poly over the top (just make sure you specify Pour Over and the correct net name. Not seeing a direct way to do this, I tried a few things like making rules for VCC/GND nets to be 0 width traces. If you do this, when you do the pours, you get whatever the clearance is on both sides of a 0 width trace, so you end up with holes in the poly pour around a 0 length trace. In a way what I told it to do I guess, but not what I really wanted... As Brad says, sound like you might like to investigate the pour options you used. Then I tried making the trace width impossibly large. It's a 2 X 2.7 board, so I made the (min/max/pref) trace width all 5. That way it can't _possibly_ route those nets then I'll just do the poly pour over it... The router happily placed 3-4 VCC/GND tracks down on the board. At maybe 50-100 mil width. This has to be a bug? The router should not put down tracks that fail to meet the design rules? I agree. Sounds like a bug. I have had problems with the rules at times, mostly order of priority issues. What is specified as the width rule for the Whole Board? Maybe the router is incorrectly picking up the whole board scope and using it. Does sound like a bug. I also tried net unroute, but this seems to just take out a segment of the net, and not the whole net (though I think this may have worked in the past). Even had this worked though, the traces would not have been as direct as they could have been without the VCC/GND nets in the way. Traces should not be in the way of a polygon pour with the same net and pour over option set. If you can investigate further whether the router was picking up another width constraint rule and let me know I will get on and add the report to the bug list. I have about 10 bugs and possible bugs to add I think at this stage, all reported over the past couple of months on this list, but not yet added to the bug list. Ian 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 * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
[PEDA] Bug List - better implementation desired
Hello all, I am searching (part time) for a better method of maintaining the bug list. I am thinking something along the lines of the Bugzilla project as used by the Mozilla people (http://www.mozilla.org/bugs/). Or something similar. What I would like is: 1) easy entry and editing (by one or more admin people) 2) able to act as store for more than just bugs, also suggestions 3) ability to maintain a status on each bug/suggestion - such as fixed and in what version it was fixed 4) more powerful search 5) Maybe the ability to accept ongoing comments from users (possibly moderated) and maintain the thread to allow issues to be discussed. (This should not be confused as another mailing list, that is not the function.) 6) ability to include graphics in posts maybe to allow screen shots to be included - although these could be links to external pages. My problem is I do not know much about Perl/CGI/webby stuff. So I am not sure how one would go about installing this, getting the source etc. I am enlisting a couple of people who think they can offer some time and expertise to help set up a better bug/suggestion tracking system. Frankly I do not want to get too involved in the nitty gritty apart from commenting on the solutions that others dig up. Anyon got the skills required? I am not too interested in I would like to help but have not got the time. None of us have. If you were going to write along those lines just don't write, thanks. Where it gets hosted is another discussion that will no doubt get a lively discussion going (my thought www.protelusers.net - but that doesn't exist...yet. protelusers.net should no be tied too closely to any company. Ian Wilson Considered Solutions Pty Ltd mailto:[EMAIL PROTECTED] ABN: 96 088 410 002 5 The Crescent CHATSWOOD 2067 Ph: +61 2 9411 4248 Fax: +61 2 9411 4249 * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * 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] Re[2]: Not routing nets and poly pours...and maybe a bug for the bug list?
AuRL If the design is so much low speed that you need not pay attention to power AuRL routing topology, then it is so much low speed that probably doing pours is AuRL unnecessary. The same arguments apply to both! Well, the design presented an excellent opportunity to experiment with poly pours, which I took advantage of. Low cost, 2 layer, in-house, low speed proto. Where better to do some experimenting? (was well worth it too, as I learned several things.) AuRL A *direct* way to not route VCC and GND would be to delete the nets using AuRL the Netlist Manager. Then resynchronize the PCB and schematic The schematic was imported in from an Orcad design. We did this a few times, as someone else did the schematic in Orcad. There was also a problem where the net labels were not attaching themselves to the wires.. AuRL Don't do a VCC pour. Good advice. Yeah, a good board to experiment on... :) AuRL Another way to prevent the routing of a net, with a through-hole design, is AuRL to create an inner plane for the net There were no inner planes here, just a cheap 2 sided board. AuRL But there was no good reason I can see to prevent the routing of those AuRL nets. The pour, if one insists on having one, can then be poured over the AuRL existing nets. The only problem with this is that there will likely be AuRL extra copper ties to the pour, which is harmless but unsightly. It was a combination of the stepping on of the thermal relief by the routed net, along with having some wide VCC tracks on the GND pour side (and vice-versa) from the routing. Either by itself might have been good enough for proto work. Indeed we almost shipped it. But I decided to look for a way to make it a bit less unsightly. AuRL [EMAIL PROTECTED] AuRL Abdulrahman Lomax AuRL Easthampton, Massachusetts USA * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * To post a message: mailto:[EMAIL PROTECTED] * * To leave this list visit: * http://www.techservinc.com/protelusers/leave.html * * Contact the list manager: * mailto:[EMAIL PROTECTED] * * Forum Guidelines Rules: * http://www.techservinc.com/protelusers/forumrules.html * * Browse or Search previous postings: * http://www.mail-archive.com/proteledaforum@techservinc.com * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
Re: [PEDA] AW: Problems when pouring polygons
The best thing is to set your grid to zero, I know this seems counter intuitive but unless you actually want a lattice type plane, setting the grid to zero will use a gridless route to lay the plane with no gaps, regardless of track size and clearance settings HTH Gerhard - Original Message - From: Florian Finsterbusch [EMAIL PROTECTED] To: Protel EDA Forum [EMAIL PROTECTED] Sent: Thursday, September 06, 2001 1:15 AM Subject: [PEDA] AW: Problems when pouring polygons | Thank you all for your recipes to workaround the polygone problem. | But till now no of them works. | | We have contacted Protel to investigate the problem. | | I have tried different hatchings, different track sizes, track widths, etc. | but the problem stays the same. | When i set the hatching to only horizontal, i get unplated rectangular areas | up to half as wide as the board! | | | Under two circumstances the error disappeared: | | 1.) Increasing the width of the lines used for the fill to more than 0.5 mm | (20 mil) | | 2.) Using a clearance design rule, which forces the polygon to stay away | more than 0.4 mm (16 mil) from pads and vias. | | Both solutions have the disadvantage, that the polygon does not pour | high-density connectors. | | | I will inform you if i know something new about the polgon-mysterie. | | Florian | | | -Ursprungliche Nachricht- | Von: robi artwork [mailto:[EMAIL PROTECTED]] | Gesendet: Mittwoch, 5. September 2001 13:38 | An: Protel EDA Forum | Betreff: Re: [PEDA] Problems when pouring polygons | | | Hi Florian, | | I believe to know what you're talking about. | | As I'm kind of to lazy tonight, to work out the metric equivalent - | please try the following. | Hit the Q-Button on the keyboard - that switches over to Imperial Mode. | Then go back to your polygon-setup and type in the figures. | 5, for the Grid size | 6, for the track width | 3, for the Minimum Primitive Size. | | As someone just mentioned that the hatching style may have an | impact, which | I can't confirm - | set the hatching style to, 90Degree Hatch. | Besed on these figures I never had any bad results. | | This should clean up your polygon. | Cheers | Robi | Robi Artwork - PCB Design Bureau | PO-Box 199,Lot 33 Jamaica Drive | Deception Bay Q4508Australia | -- | C/o Robi Bittler | Ph: 07-3203 0634 | Fx: 07-3203 3958 - only on request | * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * 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 * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
