Re: [PEDA] Gerber Import / Viewing in P99SE
I did wonder, but the original request just mentioned importing Gerber files to view in P99SE . Obviously mine *was* a silly question :-) Andy -Original Message- From: Brad Velander [mailto:[EMAIL PROTECTED]] Sent: 21 January 2003 18:00 To: 'Protel EDA Forum' Subject: Re: [PEDA] Gerber Import / Viewing in P99SE Andy, I believe you can surmise from various details of Terry's comments, he is loading some fabricator's Gerbers into Protel to create a new database. So he wants the Gerber in Protel to form his traces or to act as a template layer for his routing and generation of a new database. Sincerely, Brad Velander. Lead PCB Designer Norsat International Inc. Microwave Products Tel (604) 292-9089 (direct line) Fax (604) 292-9010 email: [EMAIL PROTECTED] http://www.norsat.com -Original Message- From: Andy Gulliver [mailto:[EMAIL PROTECTED]] Sent: Tuesday, January 21, 2003 9:31 AM To: Protel EDA Forum Subject: Re: [PEDA] Gerber Import / Viewing in P99SE OK, this may be a silly question... but how about using that free copy of Camtastic that came with P99SE to view the Gerbers? The 'auto load' works with just about everything I've thrown at it so far. Regards, Andy Gulliver * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * 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] Polygon Filled Planes
Bob, Please see below, JaMi - Original Message - From: Robert M. Wolfe [EMAIL PROTECTED] To: Protel EDA Forum [EMAIL PROTECTED] Sent: Tuesday, January 21, 2003 7:34 PM Subject: Re: [PEDA] Polygon Filled Planes JaMi wrote And speaking of Protel reliability, I am not quite sure what exactly Bob ment in his earlier post respecting an exception error about a .dll with respect to pcb which he thought was related to the Polygon Plane, and which apparently no one has really addressed, and just where that plugs into the who issue of Polygon Planes and reliability. Well Guys, I am still getting that error on this one design. It is an exception error and a .dll is mentioned. Can't actually say whether it is related to the polygon filled plane. But whenever there is an attempt to rebuild the large one this error shows up. It can be ignored or close the application. I can capture the exact text of the error tomorrow as I do not have that design home at this time. I was just trying to see if I was missing a step that needed to be done, or if there might be other issues at play. I will try to spend a bit more time with that design tomorrow to possibly shed some more light on this error. It cropped up again because the footprints needed to be unlocked to take care of assembly drawing, an dwhen that is done it wants to rebuild check everything so the error comes back. Thanks Bob It sounds like you may be having some of the same types of crash that have always plagued me in Protel with large Polygon Planes, except that you are getting an exception error message, whereas on my system, Protel would just lock up the system and go south for the winter, forcing me to reboot, which sometimes meant actually pulling the plug out of the wall. The first thing I would ask, is what type of system and what version of Windoze are you using. The second thing, and this actually may be more important, is what are the Plane Settings set at in your Polygon Plane Dialogue Box? If your Grid Size, Track Width, and Minimum Primitive Size, are all set too small, then the actual number of actual little primitives in the Polygon Plane can actually become so massive, that Protel appears to become completely overwhelmed, and crashes as a result. These sizes of the individual primitives, and their resultant number, also can sometimes make Protel appear to go south, even to the point of Not Responding in the Task Manager (possibly dependant on version of Windoze), when in reality it is just temporarily lost in space doing calculations on the massive number of little goodies in the Plane, and given enough time, Protel has actually been known to have returned from such excursions, on occasion. However, if you get an error message, you can be sure it has no intention of returning from being spaced out. Try making the Track Width a little larger, with the Grid Size just a few mils smaller than the Track Width. I typically use a Track Width of 20, and a Grid Size of 15. This may not be optimal, but it works on most of my Planes, although you may need to experiment with even larger numbers to see what works for you. You might actually want to use some real large numbers, including trying a Grid Size that is larger than your Track Width, just to see how it affects your getting the exception error, and then optimize things if that resolves the problem. I am curious to know if this will help. JaMi * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * 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] Polygon Filled Planes
Well, For now, The version of OS is Win2000 ProServer Win 2000 Pro Pro Server is a slower 500MHz machine w/128M mem, the Pro is a 1.6G P4 unit with 128M mem. I have not seen it happen yet on XP which at home here. As far as plane settings go I will look and get back to you but in all honesty I have done quite few other large pos planes with grid at zero and say .010 or .020 track widths with no ill affects or slow down. I will dig deeper though. I did not get into office today where that design is so will have some info in am about this. Thanks Bob * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * 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] General component data tracking and library management questions
Hi all, I have several questions oriented around the general theme of library organization and component data tracking (part #, distributor, price, etc.). I don't expect anyone to answer all of these, but opinions regarding any points here are most appreciated. One way or another, any re-organization will be labor intensive so we're looking for gotcha's first. We're using Protel99SE SP6. As we all know, component data tracking in Protel is awkward. Currently, we're using a convoluted procedure of tracking data in Sch Part Fields and importing/exporting the database via the Protel spreadsheet editor (performing sweeping changes in Excel external to Protel). While this does work and allows speadsheet format editing, it's labor intensive and leaves the door wide open to major errors upon re-import. The list of work-arounds involved is endless. We'd like to come up with new techniques that are as bullet-proof as possible. We're considering changing to a system where each Sch component's data is tracked in its Library Fields. This means that each value of a resistor (for example) will have to have a different Sch library entry. A benefit here is that we research the part info just once when we make the Sch component and that data is always brought to the schematic. Furthermore, each component (in Sch lib) will have only one footprint assigned to it (with the same name as the Sch component). A separate footprint then exists for each Sch component. This gets around several possible errors that can occur when one footprint is assigned to multiple Sch symbols. Obviously, a major drawback to this technique is that we make a zillion footprint entries - many identical except for the name. That's not quite as bad as it sounds as we don't use *that* many different components. The main question regarding this technique: Is there a limit on the number of symbols in a schematic library or footprints in a PCB library? We don't want to get mostly done to find that Protel has a weird bug with too many components in a library. I would guess we're still talking fewer than 300 components per library but I'd be interested to know if there's any amount that's problematic. We've also been considering use of software called Parts and Vendors (http://www.trilogydesign.com/main.htm). Does anyone out there have any experience with this or are currently using it with Protel? It appears to cross reference to your own in-house part # and allows many component data tracking options. I don't know yet if it can be linked to Protel other than through more manual interactions with the spreadsheet function. It looks like it will take notable time even to evaluate this software so I thought I'd ask here first. How about the Visual Basic scripts that Protel supports? Although doing complex macros seems like a big undertaking, is this how many people are solving these problems? I've heard about one script that does something with library fields but can't remember who made it or what it actually does. From the looks of it, knowledge of VB seems mandatory for getting into this side of Protel. Any opinions or info on scripts and their use is invited. And the dBase database linker: does it even work? Does it work *well*? Or is it an unusable feature like the 3D PCB viewer. We're wondering if switching to dBase and using the linker is a better overall alternative. I realize lots of this has been covered here in the past but it was hard to narrow down the archive search engine to bring it all up. In general, any commentary on component data tracking or related is greatly appreciated - how you do it, would like to do it, whatever. Thanks one and all! Buck Buchanan * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * 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] General component data tracking and library management questions
Buck, I am sending you an email that I have shared with others asking some similar questions. Won't repost the same thing over again here. Sincerely, Brad Velander. Lead PCB Designer Norsat International Inc. Microwave Products Tel (604) 292-9089 (direct line) Fax (604) 292-9010 email: [EMAIL PROTECTED] http://www.norsat.com -Original Message- From: Buck Buchanan [mailto:[EMAIL PROTECTED]] Sent: Wednesday, January 22, 2003 3:18 PM To: Protel EDA Forum Subject: [PEDA] General component data tracking and library management questions Hi all, We've also been considering use of software called Parts and Vendors (http://www.trilogydesign.com/main.htm). Does anyone out there have any experience with this or are currently using it with Protel? It appears to cross reference to your own in-house part # and allows many component data tracking options. I don't know yet if it can be linked to Protel other than through more manual interactions with the spreadsheet function. It looks like it will take notable time even to evaluate this software so I thought I'd ask here first. SNIP And the dBase database linker: does it even work? Does it work *well*? Or is it an unusable feature like the 3D PCB viewer. We're wondering if switching to dBase and using the linker is a better overall alternative. * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * 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] General component data tracking and library management questions
On 03:18 PM 22/01/2003 -0800, Buck Buchanan said: Hi all, I have several questions oriented around the general theme of library organization and component data tracking (part #, distributor, price, etc.). I don't expect anyone to answer all of these, but opinions regarding any points here are most appreciated. One way or another, any re-organization will be labor intensive so we're looking for gotcha's first. We're using Protel99SE SP6. As we all know, component data tracking in Protel is awkward. Currently, we're using a convoluted procedure of tracking data in Sch Part Fields and importing/exporting the database via the Protel spreadsheet editor (performing sweeping changes in Excel external to Protel). While this does work and allows speadsheet format editing, it's labor intensive and leaves the door wide open to major errors upon re-import. The list of work-arounds involved is endless. We'd like to come up with new techniques that are as bullet-proof as possible. We're considering changing to a system where each Sch component's data is tracked in its Library Fields. This means that each value of a resistor (for example) will have to have a different Sch library entry. Yep - many people work this way. A read only (Sch Lib) field holds the company part number and can then be used as key to everything else. A benefit here is that we research the part info just once when we make the Sch component and that data is always brought to the schematic. Furthermore, each component (in Sch lib) will have only one footprint assigned to it (with the same name as the Sch component). A separate footprint then exists for each Sch component. This part (a different footprint is not really necessary, or at least many companies don't go this far. They will have, for instanc, one 0805 footprint or maybe one 0805REFLOW and one 0805WAVE etc. I use this technique but am quite explicit in my footprint naming - eg SO20.3WAVE for a wave footprint version of an S0-20 with a 0.3 inch body. This gets around several possible errors that can occur when one footprint is assigned to multiple Sch symbols. Obviously, a major drawback to this technique is that we make a zillion footprint entries - many identical except for the name. That's not quite as bad as it sounds as we don't use *that* many different components. The main question regarding this technique: Is there a limit on the number of symbols in a schematic library or footprints in a PCB library? Not that I know of. We don't want to get mostly done to find that Protel has a weird bug with too many components in a library. I would guess we're still talking fewer than 300 components per library but I'd be interested to know if there's any amount that's problematic. 300 should not be an issue I would think. We've also been considering use of software called Parts and Vendors (http://www.trilogydesign.com/main.htm). Does anyone out there have any experience with this or are currently using it with Protel? It appears to cross reference to your own in-house part # and allows many component data tracking options. I don't know yet if it can be linked to Protel other than through more manual interactions with the spreadsheet function. It looks like it will take notable time even to evaluate this software so I thought I'd ask here first. How about the Visual Basic scripts that Protel supports? P99SE does *not* support VB scripts. It has its own internal Client Basic macro language (looks like traditional BASIC essentially). But this is very limited in what access you can get to internal database data. For deeper work you need Delphi (V5 for P99SE SP6). Although doing complex macros seems like a big undertaking, is this how many people are solving these problems? I've heard about one script that does something with library fields but can't remember who made it or what it actually does. I wrote a server that allows you to update all non-readonly fields for Sch components from an Excel spreadsheet. This includes footprints etc. It works *much* faster than the DB linking feature in P99SE. It can key off essentially any field but is most useful when you have the unique company part number in a SchLib (read-only) field. This allows you to bring in all the descriptions, footprints etc from the external Excel database. Server can be found at http://www.considered.com.au/Protel01.html From the looks of it, knowledge of VB seems mandatory for getting into this side of Protel. Any opinions or info on scripts and their use is invited. Delphi is needed for any significant work at the component level - either that or some small servers (in Delphi) that can expose the data you want to the Client Basic scripts. And the dBase database linker: does it even work? Does it work *well*? Works to its limits and is very slow. It does not allow the footprint to be updated, for instance. Or is it an
Re: [PEDA] General component data tracking and library management questions
At 10:43 AM 23/01/2003 +1100, Ian Wilson wrote: Server can be found at http://www.considered.com.au/Protel01.html It was pointed out to me that I don't know my own site very well :-) There is no 'l' on the .html Correct link is: http://www.considered.com.au/Protel01.htm Ian * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * 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 * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
