Re: [PEDA] [PROTEL EDA USERS]: Did SP6 break the Inversion facility
I used to be able to show an inverted signal name on the schematic using an overbar. Depending on the settings of the options, I could overbar single letters or an entire name. This no longer seems to work, at least not on the part type field of the connector (testpoint) where I'd like to apply it. Or am I imagining things? Did it only work on net labels before? Steve Hendrix I am pretty sure that the overbar has only ever worked with net labels. (But I am also sure that someone will correct me if that was not in fact the case. :) ) Regards, Geoff Harland. - E-Mail Disclaimer The Information in this e-mail is confidential and may be legally privileged. It is intended solely for the addressee. Access to this e-mail by anyone else is unauthorised. If you are not the intended recipient, any disclosure, copying, distribution or any action taken or omitted to be taken in reliance on it, is prohibited and may be unlawful. Any opinions or advice contained in this e-mail are confidential and not for public display. * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * This message sent by: PROTEL EDA USERS MAILING LIST * * Use the reply command in your email program to * respond to this message. * * To unsubscribe from this mailing list use the form at * the Association web site. You will need to give the same * email address you originally used to subscribe (do not * give an alias unless it was used to subscribe). * * Visit http://www.techservinc.com/protelusers/subscrib.html * to unsubscribe or to subscribe a new email address. * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * To leave the EDAFORUM discussion list, send a email with 'leave edaforum' in the body to '[EMAIL PROTECTED]' More Information : http://www.dolist.net
Re: [PEDA] [PROTEL EDA USERS]: How to include P99SE Mech layers inFinal Prints.
Alright, forget my message unless it is just to confirm that the automatic process for adding Mech layers to printouts is broken. I found the work-around by adding the layers within the individual drawing prints within the Browse PCB Print. Hi all, now I believe a fair while ago I had seen references on the listserver to bugs in the print servers for P99SE. Does this possibly include a bug that does not allow mechanical layers to be added to all plots? If not, in Final Plots, how do you get the Layers To Add When Creating Plots to work after selecting/checking the mech layers that I want added to my plot? I have tried checking any number of these mechanical layers and they never seem to get added to my plots. I have rebuilt and re-processed the plots. Brad Velander Printing can be undertaken using either the Power Print Server or the old fashioned way. When using the Power Print Server, it is possible to add to, or remove, layers from the list of those (layers) which will be printed with each Printout definition that has been created within a Printout Configuration file. There is a dialog box which can be used to select which Mechanical layers will be included in Printout definitions. But the layers so selected apply only *after* these have been set up, and as such, are not applied retrospectively to any currently/previously defined set of Printouts. When using the old fashioned procedure (the PCB:SetupPrinter Process invokes the Printer Setup dialog box, which is of a base camp nature in this regard), there are problems associated with selecting which Mechanical layers have their contents included in printouts of a Final Mode nature, and there are also problems associated with including any Mechanical layers in printouts of a Composite Mode nature. In that regard, a PcbAddon server which I have released incorporates Processes in which the associated dialog boxes *do* work as envisaged; this server also supports configuring printouts of a Composite Mode nature using parameters (so avoiding the invocation of the associated dialog box). If you have some reason for wanting to use the old fashioned method, then you should consider downloading a copy of this Server. As advised in a recent post, I have provided one version (the original of this) for use with SP5, and another (more recent) version for use with SP6. (If appropriate, email me for URLs for acquiring these Servers, but I did provide the associated details in a fairly recent posting.) I would not be too surprised if the old fashioned procedure was no longer supported *at all* in the next major version of Protel. As it is, with the current SP (SP6), and at least some of the previous SPs (for Protel 99 SE), Final Mode printouts from the Drill Drawing and Drill Guide plotlayers are no longer supported, and that is also the case for (Pen) Plotter printouts of either Final Mode or Composite Mode nature. (In other words, you have to use the Power Print server to produce printouts from the Drill Drawing or Drill Guide layers, and if you want to produce any penplots, you have to install and then select an appropriate printer driver.) Regards, Geoff Harland. - E-Mail Disclaimer The Information in this e-mail is confidential and may be legally privileged. It is intended solely for the addressee. Access to this e-mail by anyone else is unauthorised. If you are not the intended recipient, any disclosure, copying, distribution or any action taken or omitted to be taken in reliance on it, is prohibited and may be unlawful. Any opinions or advice contained in this e-mail are confidential and not for public display. * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * This message sent by: PROTEL EDA USERS MAILING LIST * * Use the reply command in your email program to * respond to this message. * * To unsubscribe from this mailing list use the form at * the Association web site. You will need to give the same * email address you originally used to subscribe (do not * give an alias unless it was used to subscribe). * * Visit http://www.techservinc.com/protelusers/subscrib.html * to unsubscribe or to subscribe a new email address. * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * To leave the EDAFORUM discussion list, send a email with 'leave edaforum' in the body to '[EMAIL PROTECTED]' More Information : http://www.dolist.net
Re: [PEDA] [PROTEL EDA USERS]: How to include P99SE Mech layers inFinal Prints.
snip Configuration file. There is a dialog box which can be used to select which Mechanical layers will be included in Printout definitions. But the layers so selected apply only *after* these have been set up, and as such, are not applied retrospectively to any currently/previously defined set of Printouts. snip Geoff Harland. With hindsight, it would have been more appropriate for me to have said that: . There is a dialog box which can be used to select which Mechanical layers will be included in *all* Printout definitions. ... In my experience, these settings do not apply to all sets of Printout definitions which the user is able to select from. But in spite of the fact that there are still some aspects in which the Power Print Server could be improved, these settings (in the Mechanical Layers Tab in the Preferences dialog box) can still save the user some time in some circumstances. Regards, Geoff Harland. - E-Mail Disclaimer The Information in this e-mail is confidential and may be legally privileged. It is intended solely for the addressee. Access to this e-mail by anyone else is unauthorised. If you are not the intended recipient, any disclosure, copying, distribution or any action taken or omitted to be taken in reliance on it, is prohibited and may be unlawful. Any opinions or advice contained in this e-mail are confidential and not for public display * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * This message sent by: PROTEL EDA USERS MAILING LIST * * Use the reply command in your email program to * respond to this message. * * To unsubscribe from this mailing list use the form at * the Association web site. You will need to give the same * email address you originally used to subscribe (do not * give an alias unless it was used to subscribe). * * Visit http://www.techservinc.com/protelusers/subscrib.html * to unsubscribe or to subscribe a new email address. * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * To leave the EDAFORUM discussion list, send a email with 'leave edaforum' in the body to '[EMAIL PROTECTED]' More Information : http://www.dolist.net
Re: [PEDA] [PROTEL EDA USERS]: Suggestions for improving Protel... (exgraphic images lost)
. And GC-Prevue also concurs with Camtastic on this matter.) Regards, Geoff Harland. - E-Mail Disclaimer The Information in this e-mail is confidential and may be legally privileged. It is intended solely for the addressee. Access to this e-mail by anyone else is unauthorised. If you are not the intended recipient, any disclosure, copying, distribution or any action taken or omitted to be taken in reliance on it, is prohibited and may be unlawful. Any opinions or advice contained in this e-mail are confidential and not for public display. * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * This message sent by: PROTEL EDA USERS MAILING LIST * * Use the reply command in your email program to * respond to this message. * * To unsubscribe from this mailing list use the form at * the Association web site. You will need to give the same * email address you originally used to subscribe (do not * give an alias unless it was used to subscribe). * * Visit http://www.techservinc.com/protelusers/subscrib.html * to unsubscribe or to subscribe a new email address. * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * To leave the EDAFORUM discussion list, send a email with 'leave edaforum' in the body to '[EMAIL PROTECTED]' More Information : http://www.dolist.net
Re: [PEDA] [PROTEL EDA USERS]: Attachments to posts (ex: importing anetlist to Protel)
At 01:47 PM 2/13/01 -0800, Forum Administrator wrote: There are many alternatives to attaching a file to a discussion group post, but if you feel you really must, at least be considerate of your fellow subscribers and keep attachments under 50K and ALWAYS compress (zip) the file. Let me put it this way. If that file had gone through, it would have tied up my phone line for a few minutes. Not nice. Even small attachments clutter up my disk. Please, I don't want to receive *any* uninvited attachments. Abdulrahman Lomax There is an alternative option available to adding attachments to posts to this forum. Users can sign up with Yahoo mailing lists and then become a member of the protel-users mailing list hosted there; that mailing list is in fact the backup list for this mailing list (for use when this mailing list is not functional for whatever reason, and someone urgently needs an answer to some query). Like all mailing lists hosted by Yahoo, this mailing list has 20MB of capacity available for members to upload files to. So if someone wants users to look at some file for some reason, this should be uploaded to the appropriate location (URL: http://groups.yahoo.com/group/protel-users/files , but you will need to sign in before you can upload any files), and a post then made to this forum in which users are provided with details of what problem they are encountering, and an URL provided (in the same post) so that each user can then download the file concerned in the event that he or she is so interested in doing so (and *only* if they are so interested). That way, files are not forced upon other members of the forum (in the form of attachments), and ultimately, that is the considerate thing to do in the circumstances. To avoid generating traffic on the protel-users Yahoo mailing list while this mailing list is functional, anyone uploading files to Yahoo should *de*-select the option of generating an automated email message (notifying the availability of the file for downloading). And although only a fraction of the total 20MB available is currently used by files that are available for downloading, it is also considerate to subsequently delete the file (from where you uploaded it to) when the time comes that its continued provision serves no purpose. (That could occur if you wanted users to answer questions about a particular file, and you received answers which satisfactorily answered the question(s) you had posed. Another example is if you provide some utility or addon server for general use, and at some later time update this; at that stage, the earlier version should be removed.) Regards, Geoff Harland. - E-Mail Disclaimer The Information in this e-mail is confidential and may be legally privileged. It is intended solely for the addressee. Access to this e-mail by anyone else is unauthorised. If you are not the intended recipient, any disclosure, copying, distribution or any action taken or omitted to be taken in reliance on it, is prohibited and may be unlawful. Any opinions or advice contained in this e-mail are confidential and not for public display. * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * This message sent by: PROTEL EDA USERS MAILING LIST * * Use the reply command in your email program to * respond to this message. * * To unsubscribe from this mailing list use the form at * the Association web site. You will need to give the same * email address you originally used to subscribe (do not * give an alias unless it was used to subscribe). * * Visit http://www.techservinc.com/protelusers/subscrib.html * to unsubscribe or to subscribe a new email address. * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * To leave the EDAFORUM discussion list, send a email with 'leave edaforum' in the body to '[EMAIL PROTECTED]' More Information : http://www.dolist.net
Re: [PEDA] [PROTEL EDA USERS]: Component part names
There is some preliminary info and screenshots at: http://www.ionos.com/addins/protel/protel.htm The version Phil is talking about has been in beta for 3 months or so, and the released version will be available within a week. Because of the beta trial period, there is no link on the IONOS site. Troy Magennis I have visited the URL advised above, and noticed that it states that Protel 99 SE with SP5 or later is required to run the associated server. As such, I am wondering whether the *same* server can be used with both SP5 and SP6, given that Protel has updated two .BPL files with SP6 (which has implications for addon servers). Perhaps there are no problems in this regard, but Protel (and I) have had to update some addon servers with the release of SP6. Regards, Geoff Harland. - E-Mail Disclaimer The Information in this e-mail is confidential and may be legally privileged. It is intended solely for the addressee. Access to this e-mail by anyone else is unauthorised. If you are not the intended recipient, any disclosure, copying, distribution or any action taken or omitted to be taken in reliance on it, is prohibited and may be unlawful. Any opinions or advice contained in this e-mail are confidential and not for public display. * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * This message sent by: PROTEL EDA USERS MAILING LIST * * Use the reply command in your email program to * respond to this message. * * To unsubscribe from this mailing list use the form at * the Association web site. You will need to give the same * email address you originally used to subscribe (do not * give an alias unless it was used to subscribe). * * Visit http://www.techservinc.com/protelusers/subscrib.html * to unsubscribe or to subscribe a new email address. * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * To leave the EDAFORUM discussion list, send a email with 'leave edaforum' in the body to '[EMAIL PROTECTED]' More Information : http://www.dolist.net
Re: [PEDA] [PROTEL EDA USERS]: Resizing fills in PCB files (exSuggestions for improving Protel...)
On 02:58 PM 1/03/2001 +1100, Geoff Harland said: - (Pcb Server): Add support for *resizing* of a currently-focused fill primitive using the *mouse*. That is, if you click on an edge or corner of a currently-focused fill, then you can change the location of that (by dragging it with the mouse) (rather then repositioning the entire fill, without changing its overall width or height, which is the current behaviour). If you want to reposition the fill (current behaviour), then click on the *centre* of this (and then drag it). Click once and then drag the sizing handles - function is already there. But the behavior is possibly not obvious. The resizing and rotation handles are only used if you click (and release) once more on one of the handles. In other words the resizing and rotations only occur if you are not holding the mouse button down. Ian Wilson I have just confirmed that what you described above does in fact occur. OK, one less item to add to the list of suggestions. (But I do still wonder how many users are aware of what you just described; as should be obvious, I was not previously aware of this... So thanks for the tip, as it has been a real pain, in the past, resizing fills via the dialog box.) Regards, Geoff Harland. - E-Mail Disclaimer The Information in this e-mail is confidential and may be legally privileged. It is intended solely for the addressee. Access to this e-mail by anyone else is unauthorised. If you are not the intended recipient, any disclosure, copying, distribution or any action taken or omitted to be taken in reliance on it, is prohibited and may be unlawful. Any opinions or advice contained in this e-mail are confidential and not for public display. * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * This message sent by: PROTEL EDA USERS MAILING LIST * * Use the reply command in your email program to * respond to this message. * * To unsubscribe from this mailing list use the form at * the Association web site. You will need to give the same * email address you originally used to subscribe (do not * give an alias unless it was used to subscribe). * * Visit http://www.techservinc.com/protelusers/subscrib.html * to unsubscribe or to subscribe a new email address. * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * __ To post a message: mailto:[EMAIL PROTECTED] To unsubscribe or subscribe we recommend using the form at our web site: http://www.techservinc.com/protelusers/subscrib.html You may also unsubscribe directly by email: mailto:[EMAIL PROTECTED]?body=leave%20edaforum however this may fail if you're trying to unsubscribed an old email address, an alias mail account, or if your mail client uses an unusual encoding format. To contact the Forum Administrator: mailto:[EMAIL PROTECTED]
Re: [PEDA] [PROTEL EDA USERS]: Client Basic/Server gurus: port-matchscript for Sheet Symbols/Port Connections scope?
I posted a couple of weeks ago regarding ERC and its lack of reporting on unmatched ports and sheet entries, to find that a) this is a problem and b) people solve it by using other scopes. I'm now interested in writing a script to drill through the hierarchy and match up the ports with corresponding entries and report unmatched instances. I think I can see how to navigate around the hierarchy, but can anyone tell me how to get all the port names on a sheet (and sheet entry names on a sheet symbol)? Drew Lundsten Someone else may contradict me, but AFAIK, it is not possible to implement what you are hoping to achieve with the use of a Basic macro. However, it is almost certainly possible to create an addon server containing a process which would achieve your objective. But, ... , that path requires the developer to download the SDK files released by Protel, and the two updates also released for these. The developer also needs to have a copy of Delphi 5, and the awareness of how to use both that and the SDK files provided by Protel. I speak as someone who has downloaded the files provided by Protel and acquired a copy of Delphi 5, but who has only *some* understanding of how to use that and Protel's SDK files. At present, I have no experience in navigating a project hierarchy, but I could probably gain some insight into how to do that by studying examples of source code provided by Protel (with the SDK files). Consequently, the bottom line is that I probably could assist you, but because of my current level of understanding, I would not be in a position to produce a suitable addon server within a short period of time. But other members of this forum might be in a better position to provide assistance. Another possibility is to save your schematic files in ASCII format, and write a script (Perl, for instance) which parses the contents of each file and subsequently generates a report. If you have experience in doing work of this kind, that may be another way to achieve the outcome you are looking for. (It would not be as user-friendly to apply, and would be more time consuming, but it would be one way to check your schematic files.) So what you are looking for could be achieved; it is a question of how much development effort (and on-the-job learning) would be required. Regards, Geoff Harland. - E-Mail Disclaimer The Information in this e-mail is confidential and may be legally privileged. It is intended solely for the addressee. Access to this e-mail by anyone else is unauthorised. If you are not the intended recipient, any disclosure, copying, distribution or any action taken or omitted to be taken in reliance on it, is prohibited and may be unlawful. Any opinions or advice contained in this e-mail are confidential and not for public display. * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * This message sent by: PROTEL EDA USERS MAILING LIST * * Use the reply command in your email program to * respond to this message. * * To unsubscribe from this mailing list use the form at * the Association web site. You will need to give the same * email address you originally used to subscribe (do not * give an alias unless it was used to subscribe). * * Visit http://www.techservinc.com/protelusers/subscrib.html * to unsubscribe or to subscribe a new email address. * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * __ To post a message: mailto:[EMAIL PROTECTED] To unsubscribe or subscribe we recommend using the form at our web site: http://www.techservinc.com/protelusers/subscrib.html You may also unsubscribe directly by email: mailto:[EMAIL PROTECTED]?body=leave%20edaforum however this may fail if you're trying to unsubscribed an old email address, an alias mail account, or if your mail client uses an unusual encoding format. To contact the Forum Administrator: mailto:[EMAIL PROTECTED]
Re: [PEDA] [PROTEL EDA USERS]: Give up, there is no point
Off topic a little... But the metre (and hence inch) are derived quantities (variables) so all our footprints are totally useless! Do you hear - *useless*! The speed of light, c, is constant. Any improvements in the how fast light travels does not affect the number in metres per second. The length of the metre is changed instead. So there is no point in trying to design footprints as the next time a physicist improves the estimate of c we have to go back and update all out libraries. I'm giving up and going to the beach Ian Wilson Actually, my impression was that changes in c result in corresponding changes to *both* the length of the meter *and* the duration of the second; an increase in c both increases the meter slightly and decreases the second slightly, and vice versa during times (?) of depression for c. And to avoid detection of these changes by other means of measurment, there are also changes to the mass of the kilogram, current of the ampere, intensity of the candela, and temperature of the kelvin. :-^) On a slightly more serious note, I used to have a subscription for Electronics World and Wireless World. But I had to buy a copy of the January 2001 issue after browsing through it recently in a local newsagency, as a detailed explanation was provided as to the why of gravity. It seems the expansion of the universe results in a reactive force within the ether, and gravity is the manifestation of that. And compliance with Newton's inverse square law is achieved by a formula which involves, amongst other things, the mass of the entire universe and the (inverse?) square of Hubble's constant. So, in some ways, it might be a good thing if the universe stops expanding just as you fall out of a window, but overall, a whole lot of things would doubtless happen after that which might not be so good after all... I have yet to study the article in detail, and such study might reveal some holes in the argument. I recall another article (late 80's or early 90's) which postulated that momemtum and angular momentum could be interchanged (instead of the more commonly held belief that each of these are invariant, or at least within an appropriate isolated context). My study of that article suggested that you shouldn't rush out and buy stock in solar panel propelled spacecraft... Regards, Geoff Harland. - E-Mail Disclaimer The Information in this e-mail is confidential and may be legally privileged. It is intended solely for the addressee. Access to this e-mail by anyone else is unauthorised. If you are not the intended recipient, any disclosure, copying, distribution or any action taken or omitted to be taken in reliance on it, is prohibited and may be unlawful. Any opinions or advice contained in this e-mail are confidential and not for public display. * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * This message sent by: PROTEL EDA USERS MAILING LIST * * Use the reply command in your email program to * respond to this message. * * To unsubscribe from this mailing list use the form at * the Association web site. You will need to give the same * email address you originally used to subscribe (do not * give an alias unless it was used to subscribe). * * Visit http://www.techservinc.com/protelusers/subscrib.html * to unsubscribe or to subscribe a new email address. * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * __ To post a message: mailto:[EMAIL PROTECTED] To unsubscribe or subscribe we recommend using the form at our web site: http://www.techservinc.com/protelusers/subscrib.html You may also unsubscribe directly by email: mailto:[EMAIL PROTECTED]?body=leave%20proteledaforum however this may fail if you're trying to unsubscribe an old email address, an alias mail account, or if your mail client uses an unusual encoding format. To contact the Forum Administrator: mailto:[EMAIL PROTECTED]
Re: [PEDA] [PROTEL EDA USERS]: Power Print Server / Multiple Printersunder PowerPrint
I am generating a PowerPrint setup to print the various documents and overlays that I require for my latest PCB. I need some of these documents printed out as hard copy (laser printer) and others output as PDFs. Is it possible to setup multiple printers within the one .PPC file or do I need a separate .PPC file for each printer type I wish to use? It would be nice to be able to hit one button and have it all happen. The setup for layers, etc. withing the .PPC file I can handle OK, its just the printer issue I can't find any info on. LINDEN DOYLE AFAIK, it is necessary to set up a distinct .PPC file for each different printer driver that you want to use. Given the topic, what do you, and others, think of the Power Print Server? My view is that the functionality that it provides is, overall, far superior to that provided by the old fashioned printing method. However, there are times when I wonder whether it would be possible to make this more user-friendly than is currently the case. Perhaps discussion on this matter could establish some consensus on aspects where it could be improved. As one example, it is currently possible to print all of the defined Printouts, or just one of these, or just one page/selected pages of a multiple-page Printout. How much merit would users see in also being able to print *some* of the defined Printouts (rather than all of these or just one of these)? (The CAM Manager Server permits the user to select which CAM definitions will be enabled when the associated files are actually produced.) And as another example, I typically want to have two Printouts of an Assembly nature, *and* a number of Printouts of a Final nature, within the *same* .PPC file. Implementing such a .PPC file is arguably not as straightforward as it possibly could be. (I either have to add Assembly type Printouts to a set of Final type Printouts, or add Final type Printouts to a set of Assembly type Printouts, or otherwise merge two different .PPC files into one .PPC file while using a text editor. Although things are easier after having done this, because .PPC files can be recycled between different PCB files, it is still less than user-friendly when doing this the first time around.) And when one of the options of gray colours or full colours is selected (rather than the other possible option of black and white), the set of gray colours and the set of full colours which are used is a *Server* setting. Is there merit in being able to define a set of colours for each PPC file, or even for each Printout that is defined within these? (And how much merit is there in being able to save and load sets of colours in the event that this otherwise remains a Server setting?) There are yet other examples that I could add, but the above can be regarded as a start. As I said before, I think that there is a lot to be said for the Power Print Server. But is there any consensus on aspects in which it could be made yet easier to use, and/or provide yet more functionality then is currently the case? Regards, Geoff Harland. - E-Mail Disclaimer The Information in this e-mail is confidential and may be legally privileged. It is intended solely for the addressee. Access to this e-mail by anyone else is unauthorised. If you are not the intended recipient, any disclosure, copying, distribution or any action taken or omitted to be taken in reliance on it, is prohibited and may be unlawful. Any opinions or advice contained in this e-mail are confidential and not for public display. * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * This message sent by: PROTEL EDA USERS MAILING LIST * * Use the reply command in your email program to * respond to this message. * * To unsubscribe from this mailing list use the form at * the Association web site. You will need to give the same * email address you originally used to subscribe (do not * give an alias unless it was used to subscribe). * * Visit http://www.techservinc.com/protelusers/subscrib.html * to unsubscribe or to subscribe a new email address. * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * __ To post a message: mailto:[EMAIL PROTECTED] To unsubscribe or subscribe we recommend using the form at our web site: http://www.techservinc.com/protelusers/subscrib.html You may also unsubscribe directly by email: mailto:[EMAIL PROTECTED]?body=leave%20proteledaforum however this may fail if you're trying to unsubscribe an old email address, an alias mail account, or if your mail client uses an unusual encoding format. To contact the Forum Administrator: mailto:[EMAIL PROTECTED]
Re: [PEDA] [PROTEL EDA USERS]: Representing Distances (ex ConfusedNewbie on Footprints)
Using 2/3 of an inch or .67 of an inch, its obvious which one is the more accurate. Maybe fractions rather than rounded decimals used in conversions would allow better accuracy. Clive Broome In other words, rational numbers (i.e. the ratio of one integer to another). Conceptually, this could be done. However, the addition of numbers with different denominators typically results in a number with a still larger denominator (i.e. the LCM of the original two denominators). This is one reason why rational numbers are not normally used, per se, in PCs or PC applications. As I previously mentioned, I consider that the adaptation of an Internal Measurement Unit that is a metric distance would significantly reduce the extent of the situations currently experienced, in which metric distances can get changed. An inch is *exactly* 25.4 mm, but it is not possible to express a mm in terms of an inch without using a recurring decimal representation (1 mm ~ 0.0393700787401574803... inches) (or a rational number representation, to wit 5/127 inches). Regards, Geoff Harland. - E-Mail Disclaimer The Information in this e-mail is confidential and may be legally privileged. It is intended solely for the addressee. Access to this e-mail by anyone else is unauthorised. If you are not the intended recipient, any disclosure, copying, distribution or any action taken or omitted to be taken in reliance on it, is prohibited and may be unlawful. Any opinions or advice contained in this e-mail are confidential and not for public display. * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * This message sent by: PROTEL EDA USERS MAILING LIST * * Use the reply command in your email program to * respond to this message. * * To unsubscribe from this mailing list use the form at * the Association web site. You will need to give the same * email address you originally used to subscribe (do not * give an alias unless it was used to subscribe). * * Visit http://www.techservinc.com/protelusers/subscrib.html * to unsubscribe or to subscribe a new email address. * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * To post a message: mailto:[EMAIL PROTECTED] * * To join or leave this list use the web site: * http://www.techservinc.com/protelusers/subscrib.html * - or - * mailto:[EMAIL PROTECTED]?body=leave%20proteledaforum * * Contact the list manager: * mailto:[EMAIL PROTECTED] * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
Re: [PEDA] Suggestions for improving Protel...
I don't think that this item has been listed previously during this thread: - (Pcb Server): When a pad uses the Pad Stack feature (i.e. when the Use Pad Stack checkbox in the Properties Tab of the Pad dialog box is checked), the X-Size and Y-Size distances displayed in the Properties Tab (of the Pad dialog box) are *always* the same as the corresponding distances displayed for the *Top* layer within the Pad Stack Tab (of the Pad dialog box). That is indeed appropriate if the pad concerned is on one of the top layers, i.e. the Top Overlay, Top Solder Mask, Top Paste Mask, or Top signal/copper layer. However, a good case could be made for saying that this is *not* appropriate if the pad is on any of the other layers. If the pad concerned is on one of the bottom layers, i.e. the Bottom Overlay, Bottom Solder Mask, Bottom Paste Mask, or Bottom signal/copper layer, then the distances displayed in the Properties Tab should *instead* be the same as the corresponding distances displayed for the *Bottom* layer within the Pad Stack Tab. And if the pad concerned is on any of the remaining layers, then the distances displayed in the Properties Tab should be the same as the corresponding distances displayed for the *Middle* layer within the Pad Stack Tab. Another aspect of the current situation is that if the Use Pad Stack checkbox (in the Properties Tab of the Pad dialog box) is changed from a checked state to an unchecked state, then the dimensions of the pad on *all* layers (top, middle, and bottom) are changed to the previous dimensions of the pad on its Top layer (as previously listed in the Pad Stack Tab of the Pad dialog box). Again, that should only be the case if the pad is on one of the top layers. Maybe not the biggest of issues. But still annoying in some situations when de-pad-stacking pads that are not on one of the top layers. Pcb files that were previously created using Adv Pcb 2.8 can be problematic in this regard. Regards, Geoff Harland. - E-Mail Disclaimer The Information in this e-mail is confidential and may be legally privileged. It is intended solely for the addressee. Access to this e-mail by anyone else is unauthorised. If you are not the intended recipient, any disclosure, copying, distribution or any action taken or omitted to be taken in reliance on it, is prohibited and may be unlawful. Any opinions or advice contained in this e-mail are confidential and not for public display. * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * To post a message: mailto:[EMAIL PROTECTED] * * To join or leave this list visit: * http://www.techservinc.com/protelusers/subscrib.html * - or email - * mailto:[EMAIL PROTECTED]?body=leave%20proteledaforum * * Contact the list manager: * mailto:[EMAIL PROTECTED] * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
[PEDA] Updated PcbAddon Servers released for use with Protel 99 SE
Re: [PEDA] Use Pad Stack
At 11:17 AM 3/14/01 +1100, Geoff Harland wrote: Out of curiosity, what do you suggest should be done in a situation where someone wants an unplated hole through a PCB, and this hole is to pass through the middle of a pad on the bottom (copper) layer? Before making a suggestion, I would preferably want to know *why* the user wanted such a feature. It might affect the answer. But let me imagine one. One needs to solder a wire or part to the board and needs the hole to mount the part, but other constraints, perhaps very tight trace density in the area, only allows a minimal hole to be placed in the area, and there is no room for a pad on any other layer than, say, the bottom. I did describe a scenario myself, further on in my previous post, in which the designer might want such a feature. This scenario concerned the pads used in a footprint for a through-hole crystal, where pads on the top side of the PCB (were these to be provided) could short with the body of the crystal, or at least if these were of the same diameter as the pads on the bottom side of the PCB. (I also said that I use plated pads on the MultiLayer layer myself, and use the padstacks feature so that the pads on the top side of the PCB are much smaller in diameter then the pads on the bottom side (and middle layers) of the PCB.) First of all, it should be noted that such a structure could be quite weak. This is effectively a single-sided PCB, as far as that part is concerned, and pad sizes for single-side PCBs are typically made quite a bit larger in order to provide better adhesion of the pad to the board. Even then, failure rates where there is any stress on the lead at all will be very high. I've had a number of consumer audio products fail because the adhesive did not hold and ultimately the pad or the track attaching to the pad (more likely) cracked. Clinched leads can help, but if there is room for a clinched lead there is probably room for a pad. It is not the plating that is so important, but having a pad/solder fillet on both sides, which, with the lead itself, makes a rivet that is not easily dislodged. The observation that the presense of a pad/solder fillet on both sides of the PCB makes a rivet of robust nature is very pertinent in the circumstances. It definitely vindicates my usage of plated through pads that use the padstack feature (over the alternative option of using bottom side only pads with unplated holes). Other things being equal, plated-through pads should be used in preference to single layer pads with unplated holes; the former are more reliable for the reason described. But my experience with de-soldering through-hole components from PCBs using plated-through multilayer pads indicates that the superiority of this type of pad is not unconditional. (That is an observation rather than an attempt to advocate that single layer unplated pads be used instead. If you have the right equipment, and keep it in proper order, de-soldering such components is less of a hassle than is otherwise the case.) Having said that it is probably foolish, I would then go ahead and suggest there are a number of ways to accomplish the matter. Putting a hole in an SMT pad, as I recall, can confuse Protel in a number of ways, I'm not sure it works. Obviously, one might use a padstack and define the pad as non-plated, but there are complications with that as well. I'd be tempted to place a surface pad and an additional pad in the same location which would be through-hole, nonplated. I'm not sure what pad size I would use. Zero is too small; it is tempting to make the pad size the same size as the hole, but this has a reputation of generating little slivers of copper, not from the hole drilling, since the holes are generally drilled first, before any pattern has been established, but from misregister between the hole and the film. Perhaps it might be better to make the pad 5 mils smaller than the hole (10 mils diametric). With appropriate clearance rules it would serve as a routing obstacle. Because the hole is non-plated, it could come very close to a track without harm, perhaps as close as a mil or two, I don't know how close I would want to push it. I concur that this method should work, but my sentiment is that it should not be necessary to have to use two pads; I would prefer that I could configure just *one* pad as required. Or one could use a single padstack with pads defined in a similar way. If the pad's plated property is set false, I think that there would be problems with routing to it. And if its plated property is set true instead, you would have a plated through hole which would have no copper surrounding it on the internal and top layers. That would be undesirable (as the rivet aspect of a multilayer pad would be lost, amongst other things). Of course, if the hole is surrounded by a minimal amount of copper on those layers, then you would have a multilayer pad using
Re: [PEDA] Irregular pad shapes in Protel
(and not the 2A, 2B, etc, as well, which would occupy similar locations as the 2 text, and thus render printouts of the schematic file as less readible, not to mention less agreeable from an aesthetic and professional perspective as well). Adopting this procedure means that when a netlist file is produced, the supplementary pins will all be assigned to the appropriate net, i.e. the same net that is assigned to their corresponding flag-ship pins. That way, DRC errors are not generated, and no separate step is required to assign the appropriate net to the supplementary primitives that make up each complex pad shape. Protel is supposed to be working on supporting multiple pins/pads having the same designator/name (within the same component). IME, that state has yet to be fully achieved. A such, adopting my policy of unique designators/names for each pin/pad keeps you out of the pooh. I would like to say more, but I have work to return to. If some of the above is not clear, I and/or others can assist as required. Regards, Geoff Harland. - E-Mail Disclaimer The Information in this e-mail is confidential and may be legally privileged. It is intended solely for the addressee. Access to this e-mail by anyone else is unauthorised. If you are not the intended recipient, any disclosure, copying, distribution or any action taken or omitted to be taken in reliance on it, is prohibited and may be unlawful. Any opinions or advice contained in this e-mail are confidential and not for public display. * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * To post a message: mailto:[EMAIL PROTECTED] * * To join or leave this list visit: * http://www.techservinc.com/protelusers/subscrib.html * - or email - * mailto:[EMAIL PROTECTED]?body=leave%20proteledaforum * * Contact the list manager: * mailto:[EMAIL PROTECTED] * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
Re: [PEDA] OT: Unused CMOS inputs (was: Reference)
For some logic device families the input current is much smaller in the high state than in the low state . Matt Tudor , MSEE I would have thought that this would *normally* be a pretty academic consideration. Any contemporary series of logic devices has very low input currents for both Vss level inputs and Vdd level inputs, like less than 1 uA. So unless you have a shoe-string current budget, e.g. running logic from a battery with a limited Ah capacity and/or for extended periods, other factors would also influence which level that otherwise unused inputs are tied to. This is my one and only post on this thread to this forum. I concur with Andrew Jenkins, who previously suggested that this thread should be moved to the OT forum. Regards, Geoff Harland. - E-Mail Disclaimer The Information in this e-mail is confidential and may be legally privileged. It is intended solely for the addressee. Access to this e-mail by anyone else is unauthorised. If you are not the intended recipient, any disclosure, copying, distribution or any action taken or omitted to be taken in reliance on it, is prohibited and may be unlawful. Any opinions or advice contained in this e-mail are confidential and not for public display. * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * To post a message: mailto:[EMAIL PROTECTED] * * To join or leave this list visit: * http://www.techservinc.com/protelusers/subscrib.html * - or email - * mailto:[EMAIL PROTECTED]?body=leave%20proteledaforum * * Contact the list manager: * mailto:[EMAIL PROTECTED] * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
Re: [PEDA] Problems With Gerbers Generated With Protel 99SE SP5......
I was just in the process of going over some gerbers for our latest board design. I was looking at Mid Layer 1, where in my design I have placed circular traces (8 mil wide tied to a internal ground plane with 30 mil diameter pad with a 15 mil hole) around areas where summing junctions of OP Amps pass from the top of the board to the bottom of the board. I noticed that in some cases there were some pads missing. Some of these guards have pads connecting them to an internal plane and some just have a drill hit. No pad what so ever. The pads are there in all cases when I look at the PCB in Protel. Has any one else seen this phenomenon? Shouldn't there be a pad everywhere there is a trace that passes through the board even on in internal signal layer? John Branthoover I suspect that the option of including unconnected mid layer pads has not been selected. I don't have Protel 99 SE open at present, but in the CAM Manager server, the dialog box provided for setting up Gerber files has a number of tabs, and on one of those, there is a checkbox provided for controlling that setting. Check that checkbox and then re-generate your Gerber files. Regards, Geoff Harland. - E-Mail Disclaimer The Information in this e-mail is confidential and may be legally privileged. It is intended solely for the addressee. Access to this e-mail by anyone else is unauthorised. If you are not the intended recipient, any disclosure, copying, distribution or any action taken or omitted to be taken in reliance on it, is prohibited and may be unlawful. Any opinions or advice contained in this e-mail are confidential and not for public display. * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * To post a message: mailto:[EMAIL PROTECTED] * * To join or leave this list visit: * http://www.techservinc.com/protelusers/subscrib.html * - or email - * mailto:[EMAIL PROTECTED]?body=leave%20proteledaforum * * Contact the list manager: * mailto:[EMAIL PROTECTED] * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
Re: [PEDA] [PROTEL EDA USERS]: Deleted Power Planes
I did and it won't go away! I have done a select all on that layer and deleted everything. It won't go away. Micky Blain To summarise the procedure which *should* work: 1. Delete all items present on the layer. 2. Deassign any net assigned to the layer. 3. Delete the layer from the layers listed in the Layer Stack Manager. Item 1 above *should* deal with any split power planes placed on the layer, but that is yet another aspect that should be specifically checked if any such items had in fact previously been placed on that layer. If doing *all* of the above does not result in the layer being purged from the list of available layers, then there is a problem somewhere. Regards, Geoff Harland. - E-Mail Disclaimer The Information in this e-mail is confidential and may be legally privileged. It is intended solely for the addressee. Access to this e-mail by anyone else is unauthorised. If you are not the intended recipient, any disclosure, copying, distribution or any action taken or omitted to be taken in reliance on it, is prohibited and may be unlawful. Any opinions or advice contained in this e-mail are confidential and not for public display. * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * To post a message: mailto:[EMAIL PROTECTED] * * To join or leave this list visit: * http://www.techservinc.com/protelusers/subscrib.html * - or email - * mailto:[EMAIL PROTECTED]?body=leave%20proteledaforum * * Contact the list manager: * mailto:[EMAIL PROTECTED] * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
Re: [PEDA] 'Mirror' component doesn't move the text
At 10:58 AM 4/5/01 +0200, Joop Reekers wrote: In Schematic it is harmless to mirror a part and text is staying close to the part, unmirrored. That seems to be OK to me, because I don't want mirrored text in my circuit diagrams. That much is agreed. However, there is still a problem, a little different than that posed in this thread. If one places text in a symbol, when the symbol is rotated the effective text position changes, because the text is moved and rotated around its reference point, which is the lower left for horizontal text. snip Because of the way that text primitives are stored in the database, to properly rotate text that is going to stay upright-reading, the reference point must be shifted to what was the relative position of the *end* of the text instead of remaining where the beginning was. Obviously, this is not high on my wish list. But it is irritating when one tries to put text into parts that may be rotated. It's been some time since I worked with this and I might have it all confused and don't have time to check Abdulrahman Lomax I have also commented on this previously. When doing so, I have typically referred to my past experience with using Autocad and Pcad, which each support text strings having left, right, or centre justification. (Pcad also supports text strings having either top, centre, or bottom justification.) As I see it, it would be nice if both Schematic and PCB files supported text strings with centre and right justification, in addition to the existing left justification. But such a feature is not especially high on my wish list either. However, given a choice as to which files did support this enhancement, I would opt for schematic files supporting this, so that when parts are mirrored, text strings (within parts) that were previously left justified become right justified, and vice versa (while text strings with centre justification change neither location nor justification). The text strings of *names* (as opposed to *numbers*) assigned to pins within parts have a hard-wired justification: when the pin is on the left hand side of a component, this text string has left-justification; when the pin is on the right hand side of a component, this text string has right-justification. When a part is placed in a schematic file and then mirrored, these justifications toggle as well; that is desirable behaviour in the circumstances. However, it would be nice if *other* text strings within parts behaved similarly whenever a part is mirrored. And there can be circumstances when users would like to be able to place text strings with centre justification or right justification within parts that are *not* mirrored. (From what has been stated, it is obvious that such strings would take on centre justification and left justification, respectfully, when such a part *is* mirrored.) I have an idea that I have previously requested this feature (for Schematic files) as part of the Suggestions for improving Protel thread (currently dormant) on this forum. (If so, I would have pointed out that it was only moderately high on my wish-list rather than close to the top of this, but I fully concur that the current implementation of the Schematic and Schematic Library editors can be irritating, in terms of where text ends up within mirrored parts.) I think that it is not unrealistic to assume that if Protel did improve things in this regard, then this will occur in a succeeding major version of Protel, rather than in a succeeding SP for Protel 99 SE. There are database considerations in this regard... (The same would also be true if text strings within *PCB* files were to be similarly enhanced.) Regards, Geoff Harland. - E-Mail Disclaimer The Information in this e-mail is confidential and may be legally privileged. It is intended solely for the addressee. Access to this e-mail by anyone else is unauthorised. If you are not the intended recipient, any disclosure, copying, distribution or any action taken or omitted to be taken in reliance on it, is prohibited and may be unlawful. Any opinions or advice contained in this e-mail are confidential and not for public display. * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * To post a message: mailto:[EMAIL PROTECTED] * * To join or leave this list visit: * http://www.techservinc.com/protelusers/subscrib.html * - or email - * mailto:[EMAIL PROTECTED]?body=leave%20proteledaforum * * Contact the list manager: * mailto:[EMAIL PROTECTED] * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
Re: [PEDA] Bug - Move Selection (and flipping layers) SP6
been repoured, and as such, the PCB *can* still differ from what it was like before invoking the Move Selection command and then undoing it.) Further discovery: even if you *don't* mirror the selected items (using the X key or Y key) while moving these, the locations of any non-repoured polygons are again *not* restored if the undo procedure is subsequently invoked. I suspect that Protel envisaged that users would use the L key *only* while moving a *single* component (or a *single* primitive item occupying a layer of a paired nature). The outcome of using the L key while moving selected items (instead) is definitely defective, as Ian has reported. But my subsequent investigations have revealed that polygons are definitely problematic as far as the undo procedure is concerned. It is not unreasonable to observe that recording the before and after locations (and other properties) of each constituent primitive object within each polygon object could involve logging no small amount of associated data, in the event that an user *does* select the option of repouring polygons while moving selected items; this logging would be necessary to support a totally kosher undo procedure in the event that polygons (for which repouring has been selected) are amongst items being moved by a Move command. (An argument could be advanced that future versions of Protel should *not* support polygons being repoured while *any* Move command is occurring. However, a counter-argument is that a genuine undo procedure should (still) be capable of undoing a specific polygon repour command; as such, any polygons that do get repoured (as a consequence of the user selecting that option) during a Move command should (also/then/similarly) be un-repoured if the user then undoes that Move command.) For all that, in the event that the user does not select the option of repouring polygons during a Move command, and once again does not select that when subsequently undoing that Move command, then the polygons should be restored *exactly* to where they were previously. The polygons have merely been *moved* (and perhaps mirrored); they have *not* *also* been *repoured*. As such, it is much, much, easier to *just* unmove a polygon than it is to un-repour it (as well). As far as I am concerned, the ideal outcome is for SP7 to support un-repouring of polygons during undo procedures. That said, I would place greater value on non-repoured polygons being restored to their former locations by undo procedures, as I appreciate that un-repouring polygons would not necessarily be straight forward to implement. As far as usage of the L key is concerned, it is now known that there are problems (and of a distinct nature) associated with its usage. Again, the ideal would be to fix the L key. However, there are many associated issues: would it perform a deep inversion, a standard inversion, or otherwise? Would it invert around a horizontal axis or a vertical axis? (Maybe the L key would invert around a horizontal axis, while the K key gets to be assigned to inverting around a vertical axis; that would have similarities to the X key mirroring about a vertical axis, while the Y key mirrors about a horizontal axis.) Such issues are of themselves worthy of further discussion. For the time being though, it is quite clear that the L key should be used with due care. I could say more, but I have said quite a bit already. Like I said before, please read carefully if you want to respond to this message. Regards, Geoff Harland. - E-Mail Disclaimer The Information in this e-mail is confidential and may be legally privileged. It is intended solely for the addressee. Access to this e-mail by anyone else is unauthorised. If you are not the intended recipient, any disclosure, copying, distribution or any action taken or omitted to be taken in reliance on it, is prohibited and may be unlawful. Any opinions or advice contained in this e-mail are confidential and not for public display. * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * To post a message: mailto:[EMAIL PROTECTED] * * To join or leave this list visit: * http://www.techservinc.com/protelusers/subscrib.html * - or email - * mailto:[EMAIL PROTECTED]?body=leave%20proteledaforum * * Contact the list manager: * mailto:[EMAIL PROTECTED] * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
Re: [PEDA] [PROTEL EDA USERS]: test: my posts make it to the forum,right?
For some reason I get all posts except my own, and I receive replies to my posts so somebody out there gets them. Why don't I? Drew It has been my *normal* experience that I receive a copy of each post that I send. As I mentioned in one previous post, I regard this as helpful, as it indicates that my post actually was received by the mail server (and has since been reposted). However, in the past couple of days, I have *not* received copies of *four* different posts which I sent. Two of these posts provided assistance to Mickey Blain on how to totally purge power plane layers from a PCB file. Another post thanked John Haddy for reporting how to print schematic files without having overbars on text misplaced, and suggested that David Cary add that solution to his Protel FAQ. And the other post described situations where different SPs (for Protel 99 SE) could be installed on different PCs (connected to the same network). Given the nature of these posts, it is not out of the question that nobody would have had reason to respond to them, assuming that they had even seen them. It might alternatively have been the case that they were never received by the mail server in the first instance. (I have occasionally received automated posts from my company's email Daemon, reporting when such posts were not successfully received by the EDA Protel Users mail server, and that another attempt to achieve that outcome was currently underway. However, I did not receive any such posts for any of those four posts described.) As such, I would be interested to learn if anyone sees this post, and whether they saw any/some/all of the four posts just described. (If there was a momentary hiccup, it is not out of the question that I will see this post as well, and if so, I will subsequently report that fact.) Regards, Geoff Harland. - E-Mail Disclaimer The Information in this e-mail is confidential and may be legally privileged. It is intended solely for the addressee. Access to this e-mail by anyone else is unauthorised. If you are not the intended recipient, any disclosure, copying, distribution or any action taken or omitted to be taken in reliance on it, is prohibited and may be unlawful. Any opinions or advice contained in this e-mail are confidential and not for public display. * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * To post a message: mailto:[EMAIL PROTECTED] * * To join or leave this list visit: * http://www.techservinc.com/protelusers/subscrib.html * - or email - * mailto:[EMAIL PROTECTED]?body=leave%20proteledaforum * * Contact the list manager: * mailto:[EMAIL PROTECTED] * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
Re: [PEDA] Bug - Move Selection (and flipping layers) SP6
At 12:49 PM 4/6/01 +1000, Geoff Harland wrote: However, I have been requested by fellow employees to create Acrobat files in which the pages of Assembly printouts (also) contain searchable text. (There are umpteen hundred components installed on this PCB. Now, exactly where on the PCB is component R104 installed? ...) To achieve this, I select the option (provided by the Power Print Server) of using *Windows* fonts rather than *Protel* fonts. However, as I have reported previously, both to this forum and directly to Protel, text strings can be displaced (from their actual locations) within the resulting *actual* printouts, *unless* the printout is of a mirrored nature. This means mirroring the entire PCB file to produce (acceptable) Top side Assembly printouts. (Arrrgh!!) :( I do bottom assembly drawings by making mirrored bottom padmaster and bottom legend gerber photoplots and then importing them to an assembly drawing layer. I also do this with the top assembly, and I then have top and bottom assembly drawings side-by-side on a single assembly drawing. (The top assembly is typically co-located with the actual PCB.) It's nice that Protel allows pads on mech layers Abdulrahman Lomax That is all very well, but text information is lost when you create Gerber files and then import them back into Protel again (on a different layer); each letter within each string gets converted into strokes (within the Gerber files), and as such, gets converted into non-text material. If I were to then create Acrobat files from such a PCB file, other users would not be able to search for R104 (say) on the Assembly drawing page(s) while using Acrobat's (text) searching feature (and that would be the case regardless of whether I selected the use of Windows fonts or Protel fonts when producing the printouts concerned). Re pads on Mechanical layers. Maybe things have changed with SP6, but with at least some of the earlier versions of Protel 99 SE (and earlier versions of Protel), each pad on a Mechanical layer would be flashed in a Gerber file if that (Gerber) file was produced from the *same* (Mechanical) layer that the pad was located on, but would *not* be flashed within any Gerber file produced from any *other* layer (and regardless of whether that (Mechanical) layer had been selected for inclusion in all Gerber files or otherwise). That is a trap for the unwary (because *other* types of primitives on those Mechanical layers do end up within the Gerber files) ... Regards, Geoff Harland. - E-Mail Disclaimer The Information in this e-mail is confidential and may be legally privileged. It is intended solely for the addressee. Access to this e-mail by anyone else is unauthorised. If you are not the intended recipient, any disclosure, copying, distribution or any action taken or omitted to be taken in reliance on it, is prohibited and may be unlawful. Any opinions or advice contained in this e-mail are confidential and not for public display. * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * To post a message: mailto:[EMAIL PROTECTED] * * To join or leave this list visit: * http://www.techservinc.com/protelusers/subscrib.html * - or email - * mailto:[EMAIL PROTECTED]?body=leave%20proteledaforum * * Contact the list manager: * mailto:[EMAIL PROTECTED] * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
Re: [PEDA] Assembly Drawings (ex Bug - Move Selection ...)
At 03:32 PM 4/6/01 +1000, Geoff Harland wrote: That is all very well, but text information is lost when you create Gerber files and then import them back into Protel again (on a different layer); each letter within each string gets converted into strokes (within the Gerber files), and as such, gets converted into non-text material. If I were to then create Acrobat files from such a PCB file, other users would not be able to search for R104 (say) on the Assembly drawing page(s) while using Acrobat's (text) searching feature This is correct. If you want more than graphics, the gerber import method I use would be less than satisfactory. However, this is a case where it would not be difficult to write a server or utility that would place text strings as needed on the mech layer of choice, from the relevant overlay layer. Abdulrahman Lomax Food for thought. I reported the problem concerning the usage of Windows fonts (to both Protel and this forum) before SP6 was released, and had hopes that this problem would be rectified by SP6. (Regrettably, that was not the case.) An optimistic interpretation would be that my report occurred too late in the piece for Protel to rectify the associated problem in SP6, but that this will be rectified in SP7. However, if for whatever reason this is *not* rectifed in SP7 (such as Protel not regarding this problem of being of sufficient seriousness to rectify, for instance), then the longer it takes for me to create a suitable process in an addon server, the longer I will have to keep on mirroring PCBs in order to produce top side Assembly Drawings of a satisfactory nature. So at the risk of spending some time on a process which might not be required after SP7 is released, I will at least consider creating something which will create a mirrored image of the Top Overlay layer (and the pads on the Top signal and MultiLayer layers) on one (or two?) of the Mechanical layers. Such a process would also allow me to create both the Top side Assembly Drawing and the Bottom side Assembly Drawing in one hit (and if I so wanted, on the *same* page rather than on separate pages). It shouldn't take an undue amount of time to write the associated code... Would such a process be of interest to you, or other users, as well? (You could avoid the requirement of having to generate Gerber files and then importing them back onto one or more Mechanical layers.) If I have reason to believe that other users would also be interested in this capability (even if it is used for other reasons), I would be more motivated to put the required time in. Regards, Geoff Harland. - E-Mail Disclaimer The Information in this e-mail is confidential and may be legally privileged. It is intended solely for the addressee. Access to this e-mail by anyone else is unauthorised. If you are not the intended recipient, any disclosure, copying, distribution or any action taken or omitted to be taken in reliance on it, is prohibited and may be unlawful. Any opinions or advice contained in this e-mail are confidential and not for public display. * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * To post a message: mailto:[EMAIL PROTECTED] * * To join or leave this list visit: * http://www.techservinc.com/protelusers/subscrib.html * - or email - * mailto:[EMAIL PROTECTED]?body=leave%20proteledaforum * * Contact the list manager: * mailto:[EMAIL PROTECTED] * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
Re: [PEDA] Assembly Drawings
snip There are two desireable utilities, really. (1) Make a fabrication drawing: create drill symbols and a drill chart on a specified layer. (2) Make an assembly drawing: take a layer, mirrored or not mirrored, and copy it to a specified layer. We've been discussing item 2. A top or bottom overlay, plus a top or bottom padmaster, usually will make a pretty good basic assembly drawing; one adds format and notes, etc. snip The existing tools work, but it could be a smoother process, and being unable to see the drill chart in the PCB editor is a general nuisance. I can understand why they did it, though. Abdulrahman Lomax While the initial idea was to facilitate creating Assembly Drawings, layer imaging could certainly be generalised to support copying/imaging any source layer to any destination layer, and with optional mirroring (and an optional offset, especially when mirroring is *not* selected, but arguably also relevant even when mirroring *is* selected); in other words, item 2 above. A case could probably also be made for being able to qualify which primitives on the source layer get to be imaged to the destination layer, such as arcs, fills, ... , polygons, component Designator strings, etc. That suggests a dialog box with similarities to the one provided for configuring layers (within Printout definitions) in the PCB Power Print Server. (My preference would be for additionally providing support for parameters so that users could then avoid having to invoke that dialog box, should they so wish.) I confess to having mused about item 1 above, or functionality of a similar nature, from time to time. In particular, my vision has been of creating full circle-arcs on a particular layer whose locations and diameters match all holes in the PCB file; i.e. such a full-circle arc for each (and every) hole. A printout from such a layer would differ from printouts from Drill Drawing and Drill Guide layers, but still be similar, in the sense that it would also document holes in the PCB file. But while the Power Print Server does provide enhanced capabilities as far as printouts in general are concerned, perhaps there is something to be said for users being able to acquire yet more capability when it comes to creating customised printouts that document holes/drilling information. So I will also give some thought to the idea of adding assorted types of primitves to a particular layer to document such details (and of being able to update such information when so requested?). It is also fair enough to say that highly-polished products would not necessarily be released first-time. But certainly these could evolve as users acquire experience in using these... Regards, Geoff Harland. - E-Mail Disclaimer The Information in this e-mail is confidential and may be legally privileged. It is intended solely for the addressee. Access to this e-mail by anyone else is unauthorised. If you are not the intended recipient, any disclosure, copying, distribution or any action taken or omitted to be taken in reliance on it, is prohibited and may be unlawful. Any opinions or advice contained in this e-mail are confidential and not for public display. * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * To post a message: mailto:[EMAIL PROTECTED] * * To join or leave this list visit: * http://www.techservinc.com/protelusers/subscrib.html * - or email - * mailto:[EMAIL PROTECTED]?body=leave%20proteledaforum * * Contact the list manager: * mailto:[EMAIL PROTECTED] * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
Re: [PEDA] Running different SPs (ex Multiple License Message)
snip I am not sure how the different service packs work alongside each other...but I wouldn't run that way... it just sounds like it is asking for trouble but I never tested it so who knows ;) Colby There is a lot to be said for installing the most recent SP on all PCs on which Protel (99 SE) has been installed. However, I would argue that any installation of Protel (99 SE) *should* be able to run satisfactorily on any PC, regardless of whether the SP that has been installed on that PC is the same as the SP that has been installed on any other PC that is connected to the same network. However, just because I have said that that is what *should* happen, does not necessarily equate what actually *does* happen in those circumstances, though. It might strike some as self-obvious that this should be supported, but others may wonder how situations could exist where users might want to have different SPs installed on different PCs. In that regard, I consider that there really are times when this situation could come about. When Protel releases a prerelease version of a SP, this is normally released on a NDA basis. Amongst the conditions associated with downloading this, is one in which the downloaded file can be installed on *one* PC only. To avoid breaching this condition, premises with multiple installations of Protel (99 SE) could download a separate copy of the SP for each PC on which they want to evaluate it (but I suspect that Protel would not vigorously pursue this aspect of violating the NDA if the premises concerned complied with the remaining aspects of this). However, because that SP is then in a prerelease status, and thus might contain software of a less than fully tested nature, many premises would prefer *not* to test that version of the SP on *all* of their PCs (which have Protel (99 SE) installed on them). And even after a SP has been released in its final form, some premises might want to evaluate this on some (/one) of their PCs, before making a decision as to whether it gets installed on *all* of their PCs. Although each SP released normally results in some improvement to Protel's performance and behaviour, many users subscribe to the view that many SPs are of a two/three steps forward, one step back nature. Although they would appreciate the two/three steps forward, there could be times when they regard the one step back as imposing unacceptable drawbacks on their usage of Protel, and so they might consequently make the decision to *not* install that SP on *all* of their PCs. (In the event that such a decision was made, it would typically be made with some reluctance, because they could be missing out on other features that they value and would otherwise enjoy. And in some cases, the SP might be installed on all PCs at a later date, if someone figured out some way of reducing the drawbacks (from their perspective) associated with doing that.) Extending the above scenario, it is not of the question that there could be cases where the most recent SP has *not* been installed on all PCs at a given location, and then *another* SP is then released. Regardless of whether this new SP is tested in its prerelease form or its final form (or both) on just some/one of the PCs concerned, the situation can then exist where there is a gap that is *two* SPs wide between different PCs. And that scenario could, in some cases, extend yet further... (if the new SP does not overcome the (perceived) drawbacks of the SP, or SPs, that preceded it). Although this situation may sound far-fetched, or even contrived, I suspect that it still does occur, and as such, it is something which should subsequently be taken into account by Protel. I also have no experience with running different SPs on different PCs (connected to the same network), and it is not out of the question that that aspect, in itself, is in fact not problematic. But then again, anyone running such a setup should not discount the possibility that this situation might be problematic. Regards, Geoff Harland. - E-Mail Disclaimer The Information in this e-mail is confidential and may be legally privileged. It is intended solely for the addressee. Access to this e-mail by anyone else is unauthorised. If you are not the intended recipient, any disclosure, copying, distribution or any action taken or omitted to be taken in reliance on it, is prohibited and may be unlawful. Any opinions or advice contained in this e-mail are confidential and not for public display. * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * To post a message: mailto:[EMAIL PROTECTED] * * To join or leave this list visit: * http://www.techservinc.com/protelusers/subscrib.html * - or email - * mailto:[EMAIL PROTECTED]?body=leave%20proteledaforum * * Contact the list manager: * mailto:[EMAIL PROTECTED] * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
Re: [PEDA] SolderMask and PasteMask expansion values (ex Protelfeatures...)
snip As one example, I am thinking of how to set Solder Mask and Paste Mask expansion values. In AdvPcb 2.8, users set these on a pad-by-pad basis (though the global editing feature made it easier to set (and/or check) these properties on a multiple-pad basis). With Protel 3, 98, and 99 (original version), these values were set by Design Rules. With Protel 99 SE, it is now possible to set these values either by a pad-by-pad basis (like in AdvPcb 2.8) *or* by the use of Design Rules (like in intermediate versions). Personally, I think this is a commendable enhancement, and I was actually one of those who requested this. That said, there are times when I wonder if the current implementation is as good as it could be. I can't help thinking that if a user changes one (or both) of these values from a Pad dialog box, then perhaps that change should also result in the creation (or modification) of a Design Rule which (co-)records/logs/documents the user changing that setting in this manner. When a user places a Room (object) in a PCB file, that results in a corresponding Design Rule being created; I envisage something similar for Solder Mask and Paste Mask expansion settings. In other words, there would be two-way synchronisation between Design Rules and settings changed on a pad-by-pad basis. By all means object if you think that what I am saying there is a load of c***. But the point I am trying to make is that Protel's efforts to accommodate users' requests can sometimes result in them having to cope with conflicting aspects and/or concepts. snip Geoff Harland. I'm following up with a response to my own previous post. Thinking more about it, one issue which would be problematic with what I suggested is what would happen when pads are not uniquely identified, and different pads sharing the same identity (e.g. Free-1 or U4-B) have distinct solder mask and/or paste mask expansion values, which can presently occur when these are set by using the Pad dialog box. One way of coping with this situation would be to have the software monitor for it, and when it is detected, a warning box is invoked. This would alert the user that there are *other* pads having the same identity, and the change that the user is currently making will *also* apply to them if the user continues with it. If the user then wants to continue, that will then happen, otherwise, the change will then be abandoned. Alternatively, any Design Rules while were created (or modified) for such pads (and/or vias) (as a consequence of changing these values by the dialog box) would need to be labelled/tagged/qualified in some manner, to indicate that the pads (vias) specified by that Rule are not unique, *and* that the associated Rule does not apply to *all* of the pads (vias) concerned. Perhaps a supplementary feature could be provided in which the pads (vias) which are *not* subject to the Design Rule concerned could be placed into a selected state, to facilitate their identification by the user. This complication could of course be avoided if my suggestion was not acted upon at all. But I consider that we currently have a situation where the (Pad/Via) dialog box depicts the expansion values for a given pad or via, but the Design Rules, by themselves, do not *always* do so as well (/instead). What do others think? (Your 2c worth of thought on this matter would be appreciated.) Regards, Geoff Harland. - E-Mail Disclaimer The Information in this e-mail is confidential and may be legally privileged. It is intended solely for the addressee. Access to this e-mail by anyone else is unauthorised. If you are not the intended recipient, any disclosure, copying, distribution or any action taken or omitted to be taken in reliance on it, is prohibited and may be unlawful. Any opinions or advice contained in this e-mail are confidential and not for public display. * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * To post a message: mailto:[EMAIL PROTECTED] * * To join or leave this list visit: * http://www.techservinc.com/protelusers/subscrib.html * - or email - * mailto:[EMAIL PROTECTED]?body=leave%20proteledaforum * * Contact the list manager: * mailto:[EMAIL PROTECTED] * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
Re: [PEDA] Protel features and negative objects (ex Solder Paste ...)
sometimes result in them having to cope with conflicting aspects and/or concepts. Enough for the time being. There is a fair bit of material here for anyone who wants to run with it... Regards, Geoff Harland. - E-Mail Disclaimer The Information in this e-mail is confidential and may be legally privileged. It is intended solely for the addressee. Access to this e-mail by anyone else is unauthorised. If you are not the intended recipient, any disclosure, copying, distribution or any action taken or omitted to be taken in reliance on it, is prohibited and may be unlawful. Any opinions or advice contained in this e-mail are confidential and not for public display. * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * To post a message: mailto:[EMAIL PROTECTED] * * To join or leave this list visit: * http://www.techservinc.com/protelusers/subscrib.html * - or email - * mailto:[EMAIL PROTECTED]?body=leave%20proteledaforum * * Contact the list manager: * mailto:[EMAIL PROTECTED] * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
Re: [PEDA] Export an IPC-D-356 format Netlist for PWB MFG circuittesting
I am using Protel99SE SP6. I have a request from a board manufacture to generate a Netlist for them to use for their test lab for the bare boards. The netlist they are asking for is in the IPC-D-356 format. (IPC-D-356A = Bare Board Electrical Test Information in Digital Form) HOW DO I EXPORT THIS NETLIST IN THIS FORMAT? CAN PROTEL DO IT? Michael Biggs Michael, The following URL provides some information on the IPC-D-356 format (though this is not necessarily the last word on this): http://www.aceeng.com/ipc-356.html It might be possible to create an utility which uses a PCB file, saved in ASCII format, as an input, and which creates a corresponding output file in IPC-D-356 format. (A Perl script, for instance.) Alternatively, perhaps there is some Gerber file viewing utility available which supports exporting files in IPC-D-356 format. I will let you know if I find anything further of possible interest to you. Regards, Geoff Harland. - E-Mail Disclaimer The Information in this e-mail is confidential and may be legally privileged. It is intended solely for the addressee. Access to this e-mail by anyone else is unauthorised. If you are not the intended recipient, any disclosure, copying, distribution or any action taken or omitted to be taken in reliance on it, is prohibited and may be unlawful. Any opinions or advice contained in this e-mail are confidential and not for public display. * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * To post a message: mailto:[EMAIL PROTECTED] * * To join or leave this list visit: * http://www.techservinc.com/protelusers/subscrib.html * - or email - * mailto:[EMAIL PROTECTED]?body=leave%20proteledaforum * * Contact the list manager: * mailto:[EMAIL PROTECTED] * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
Re: [PEDA] Protel flyer in the mail
According to Rick Wilson, Manager of Corporate Services, from whom I just received training at a seminar, the upgrade price will be $795 to $995. Jim Muehlberg Let's hope that the next version (apparently due for release some time this year) will have enough bug fixes and new/enhanced features to make the upgrade price worthwhile. I'm not sure how my boss would respond to a request from myself to purchase an upgraded version of Protel. That said, I would regard the provision of SDK files (with the new version) to be a very important factor, and if not right from the start, then as soon as possible afterwards, as in before the release of the first SP for the new version. (Such files were never released for use with the original version of Protel 99, and while they have been released for use with Protel 99 SE, they are still in a pre-release state, and as such, anyone who downloads these has to agree to comply with an associated NDA.) And while I don't object to Protel providing yet more services and Servers per se, this should not be at the expense of not improving the core Schematic, PCB, and Autoroute Servers as much as possible as well. I haven't seen any recent flyer myself, but I have visited Protel's Website recently. It seems that from July 1 this year, the pricing schedule for Protel 99 SE will change as follows: New license price: from US$5,995 to US$7,995. Protel 16-bit user upgrade price: from US$2,995 to US$3,995. Protel 98 user upgrade price: from US$1,495 to US$1,995. Protel has released a number of SPs for use with Protel 99 SE, and has not charged users for these; nor were users charged for Protel 99 SE if they had purchased Protel 99 previously, and nor were users charged for the CAMtastic! 2000 Designers Edition (first provided last year to those owning a copy of Protel 99 SE). But everyone is going to have to decide for themselves how to interpret a one-third increase in price for those purchasing (or upgrading to) Protel 99 SE after the end of June (this year)... Regards, Geoff Harland. - E-Mail Disclaimer The Information in this e-mail is confidential and may be legally privileged. It is intended solely for the addressee. Access to this e-mail by anyone else is unauthorised. If you are not the intended recipient, any disclosure, copying, distribution or any action taken or omitted to be taken in reliance on it, is prohibited and may be unlawful. Any opinions or advice contained in this e-mail are confidential and not for public display. * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * To post a message: mailto:[EMAIL PROTECTED] * * To join or leave this list visit: * http://www.techservinc.com/protelusers/subscrib.html * - or email - * mailto:[EMAIL PROTECTED]?body=leave%20proteledaforum * * Contact the list manager: * mailto:[EMAIL PROTECTED] * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
Re: [PEDA] Protel flyer in the mail
Geoff wrote I'm not sure how my boss would respond to a request from myself to purchase an upgraded version of Protel Tell you boss to price out any compitetors product and see if he has a change of mind. That is the poorest argument I have ever heard for boosting your productivity. I finnally convinced some designers to start using 99SE over 98. One comment was 98 was a dinasour by comparision, I tried to convince them a year ago, and now we are ready for new version. I wonder what these dinaosur designers are going to do next. Mike Reagan Yeah well I had a boss that just like that. They may be shortsighted, but they are everywhere Tony Karavidas Yeah, short-sighted but never in short supply! 8^ I am sure we all have very similar war stories. Brad Velander I have reason to believe that I have a reasonable chance of having my request for upgrading Protel accepted, as opposed to a slim chance or no chance at all. That said, there are some factors which could result in my request being declined. The PCBs which I design are not pushing the envelope as far as Protel's capabilities are concerned, and I have managed to enhance the capabilities of the existing version of Protel by using the SDK files to create customised Processes within addon Servers. And there is a question mark over whether the next version of Protel will run on Windows 98 or not. At present, I am using Win 98 at work, and while I have heard noises to the effect that everyone will be upgrading to Win 2000 at some stage, there could be a problem in that regard if I am still using Win 98 when the next version of Protel is released, if that won't run on Win 98. However, I am not unhappy with my present employer, in spite of the fact that I am presently using Win 98, and that it is not absolutely certain that I will get to upgrade to the next version of Protel. Before I started my present job, I applied for a job with a company (, in one of Sydney's northern suburbs, ) which was still using Adv Pcb 2.8 at that time (and maybe still is). Ugh!!! (That was even worse than my previous employer, in that I was at least using Protel 3 at the time, even though it was not at all likely that I would ever have got to have upgraded to still later versions.) And if it was not uncool to bad-mouth past employers, I could tell assorted tales about some of mine... but I will resist the temptation, and all the more so (for this forum), given that the tales concerned are of a non-Protel nature. :) So I will give my best shot to getting the next version of Protel. But it would help things in that regard if Protel also comes to the aid of the party by releasing a new version which is not too buggy (or bloated), and which provides sufficient bug fixes/new features/enhanced features/productivity enhancements to justify the expenditure concerned. Regards, Geoff Harland. - E-Mail Disclaimer The Information in this e-mail is confidential and may be legally privileged. It is intended solely for the addressee. Access to this e-mail by anyone else is unauthorised. If you are not the intended recipient, any disclosure, copying, distribution or any action taken or omitted to be taken in reliance on it, is prohibited and may be unlawful. Any opinions or advice contained in this e-mail are confidential and not for public display. * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * To post a message: mailto:[EMAIL PROTECTED] * * To join or leave this list visit: * http://www.techservinc.com/protelusers/subscrib.html * - or email - * mailto:[EMAIL PROTECTED]?body=leave%20proteledaforum * * Contact the list manager: * mailto:[EMAIL PROTECTED] * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
Re: [PEDA] Export an IPC-D-356 format Netlist for PWB MFGcircuittesting
WOW guys how did we miss this export feature? I certainly would have welcomed someone from Protel to join us in this conversation about Protels ability to generate a 356 netlist. I have also been asked for these netlists by fab houses. Im going directly to my 99SE to verify Mr. Dolyes findings. Hold the presses Mike Reagan I did see some reference to exporting IPC-D-356 files from CAMtastic! 2000 Designers Edition when this thread was somewhat younger, and actually had a go at doing this. However the outcome was not particularly edifying, as the file concerned, although created, was virtually a null file in nature. Perhaps I did not do everything beforehand that I should have done. I do not use CAMtastic! 2000 Designers Edition overly much, so it might be a different story for someone who really does know their way around this product. I primarily use Graphicode's Gc-Prevue application to preview Gerber and NC-Drill files, but this does not support exporting any types of files. However, I have reason to believe that there are other (Gerber file) previewing applications which do support exporting assorted files types, and that in some cases IPC-D-356 files are amongst the types of exported files supported. So if anyone can assist in informing us of such applications, and how they perform in this regard, then I suspect there would be considerable interest by many of us in learning about these. Regards, Geoff Harland. - E-Mail Disclaimer The Information in this e-mail is confidential and may be legally privileged. It is intended solely for the addressee. Access to this e-mail by anyone else is unauthorised. If you are not the intended recipient, any disclosure, copying, distribution or any action taken or omitted to be taken in reliance on it, is prohibited and may be unlawful. Any opinions or advice contained in this e-mail are confidential and not for public display. * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * To post a message: mailto:[EMAIL PROTECTED] * * To join or leave this list visit: * http://www.techservinc.com/protelusers/subscrib.html * - or email - * mailto:[EMAIL PROTECTED]?body=leave%20proteledaforum * * Contact the list manager: * mailto:[EMAIL PROTECTED] * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
Re: [PEDA] [PROTEL EDA USERS]: PDF and/or Postscript generation withover-bars?
I have found that I can avoid the relocated overbars by ensuring that PDFwriter is configured to embed all fonts, with no exclusions. It makes the PDF a bit bigger, but at least I have a distributable schematic! snip John Haddy Thank you very much for reporting your discovery. I also have been vexed by printing out schematic diagrams, only to find that it is a lottery as to where the overbars end up (not to mention being interrogated by those (such as A.L.), unfamiliar with this aspect of Protel, as to the meaning of the misplaced overbars :( ). Because this is an aspect of Protel which users can expect to encounter in the event that they do make use of the overbar feature, I strongly suggest that David Cary adds this item to his Protel FAQ (and ditto for anyone else given to creating such files). Regards, Geoff Harland. - E-Mail Disclaimer The Information in this e-mail is confidential and may be legally privileged. It is intended solely for the addressee. Access to this e-mail by anyone else is unauthorised. If you are not the intended recipient, any disclosure, copying, distribution or any action taken or omitted to be taken in reliance on it, is prohibited and may be unlawful. Any opinions or advice contained in this e-mail are confidential and not for public display. * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * To post a message: mailto:[EMAIL PROTECTED] * * To join or leave this list visit: * http://www.techservinc.com/protelusers/subscrib.html * - or email - * mailto:[EMAIL PROTECTED]?body=leave%20proteledaforum * * Contact the list manager: * mailto:[EMAIL PROTECTED] * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
Re: [PEDA] Layer Stackup Legend
It seems to me that I remember seeing it. But it is not there now in my installation of 99SE SP6. I'm going to go search the Knowledge Base. Abdulrahman Lomax Nor is it in my tools menu. I do have the layer stack manager in the design menu. I'm running 99se, sp6. Help says design explorer version 6.6.7 The layer legend sounds useful, how do I find it? Richard Sumner The associated (LayerStackupAnalyzer) server was initially released (prior to the release of SP6) in pre-release form, and under NDA conditions. Since then, it has been included as part of SP6 (for Protel 99 SE). Ideally, the prerelease version (of the LayerStackupAnalyzer server) should be uninstalled before SP6 is installed. With the prerelease version, if not the version released with SP6, an Layer Stackup Legend item was added under the Tools column of the menu for the PCB Server, and that (menu item) invoked the LayerStackupAnalyzer:GenerateCrossSection process. If that menu item does not exist, it can be added by customising the menu resource. When using this process, you should previously switch to the layer (i.e. make that layer the current/active layer) you want the layer legend to be added to. When prompted, select the first corner, *then* press the Tab key to invoke the Layer Stackup Analyzer Setup dialog box. That dialog box contains checkboxes which permits you to select which details of the layer stackup will be subsequently reported. (I regard it as confusing that this dialog box is not invoked if the Tab key is pressed prior to selecting the first corner.) After selecting the required items and closing the dialog box, you will be prompted for the second corner, and the location of this will determine how much area is occupied by the resulting text (and how high the associated text strings consequently are). The documentation for this process leaves something to be desired. No LayerStackupAnalyzer.hlp file was provided with the prerelease version, and nor was such a file provided with SP6. However, given that SP6 has now been released on a public basis, it is now permissible for users such as myself to provide assistance on this server. Regards, Geoff Harland. - E-Mail Disclaimer The Information in this e-mail is confidential and may be legally privileged. It is intended solely for the addressee. Access to this e-mail by anyone else is unauthorised. If you are not the intended recipient, any disclosure, copying, distribution or any action taken or omitted to be taken in reliance on it, is prohibited and may be unlawful. Any opinions or advice contained in this e-mail are confidential and not for public display. * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * 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] ClientBasic footprint generator.
I've also noticed that after building relatively complex footprints, such as ball escapes for BGA devices with the escape track routing added and modified over time, when I drag these parts around I notice little bits of copper from tracks that no longer seem to be part of the library part!!! So am I probably falling victim some little momentary lapse from time to time? But it isn't very clear what that would be. Tim Hutcheson Just a thought. Are the primitives of the associated component in a locked state? And here's a gotcha to watch out for. Using the Unroute command can strip non-pad primitives on signal layers from within components, even if these components' primitives are in a locked state. Regards, Geoff Harland. - E-Mail Disclaimer The Information in this e-mail is confidential and may be legally privileged. It is intended solely for the addressee. Access to this e-mail by anyone else is unauthorised. If you are not the intended recipient, any disclosure, copying, distribution or any action taken or omitted to be taken in reliance on it, is prohibited and may be unlawful. Any opinions or advice contained in this e-mail are confidential and not for public display. * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * 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] Test point tenting on side opposite TP
Joel, Clicking Testpoint just marks it as a testpoint for output, but does not even automatically untent the via. So it would allow you to have soldermask on a test point. Hum, they might complain about that in the test department. Seems the only solution/work around is create separate components for the top and bottom testpoints and then modify them as needed. Protels treatment of testpoints leaves something to be desired. Perhaps the next version will give us the control we need. It would be nice to have clearance checking for testpoint to testpoint spacing. And also soldermask control for each side of the board, since you only need access from one side, not both. Carl I was wondering why a (testpoint) component had to be designed for each side of the PCB, as components can be moved from one side of the PCB to the other. But having said that, the Testpoint properties of pads are *not* updated whenever a pad is moved to the other side of a PCB, and regardless of whether a pad is part of a component or otherwise. Is there anyone who thinks that this behaviour is desirable? I.e. that pads' Testpoint properties should *not* be updated whenever a pad is moved to the other side of a PCB. (Maybe the user should be polled as to whether *none* of the pads and vias being flipped have their Testpoint properties updated, or *all* of these, or whether the user will be polled for *each* of these.) Vias are also problematic in this regard. (Although it is less likely for vias to be incorporated within footprints, this is still possible though.) And a related issue is what should happen to each via's LowLayer and HighLayer properties when vias are moved from one side of the PCB to the other. At present, these don't change, but a case could be made that the outside layer of all blind vias should toggle (even though this could result in vias using layer pairs which have not been defined by the user). Comments from other users on this one? I do not disagree with the concept of enhanced padstacks support (supporting, among other things, through-hole pads and vias having a soldermask opening on one side of the PCB but not on the other), and I have advocated this to some extent in the past. But I am also of the view that this is can of worms territory, because of issues as to whether the desired outcome should be achieved by using Design Rules, or dialog box entries, or by *either* of those methods. In some ways, the ideal would be to support either method, but a proper implementation of that approach would require dialog box entries to auto-create corresponding Design Rules, so that settings for pads and vias can be determined/checked either by viewing Design Rules or by viewing dialog box contents. But Design Rules could be problematic when the pads and vias these are applied to are not fully identifiable; if only *some* vias are to be masked on one side only (for instance), how are these to be identifed (via Design Rule entities)? Again, comments from others on this matter would be welcomed. (I have previously suggested that perhaps vias could support a name/designator property, so that Design Rules could be applied to vias on a selective basis, the selection criteria being of course based on the name assigned to each via.) Regards, Geoff Harland. - E-Mail Disclaimer The Information in this e-mail is confidential and may be legally privileged. It is intended solely for the addressee. Access to this e-mail by anyone else is unauthorised. If you are not the intended recipient, any disclosure, copying, distribution or any action taken or omitted to be taken in reliance on it, is prohibited and may be unlawful. Any opinions or advice contained in this e-mail are confidential and not for public display. * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * 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] lost polygons
Is there any way to make lost polygon fills visible? Or delete them? By lost I mean that 'connect to net' and 'remove dead copper' were selected for a polygon fill and through updating, or copying from one design to another, the net name has been removed, and so the polygon disappears. Although it is still 'there' as I am still asked to repour it if I 'select all' objects in the pcb workspace and move the selection slightly. I hope this is not clear as mud. Tom. It helps if you have some idea of where each polygon is. If you know that, you can double-click within an area where a non-visible polygon is occupied, and hopefully a dialog box associated with that polygon will then be invoked. You can then change that polygon's properties, so that after it is subsequently repoured, it will then be visible. So permitting you to then delete this or edit its properties further as required. That still doesn't deal with phantom polygons, e.g those with less than three vertices. If all else fails, save and export in ASCII format, edit that (ASCII) file (which is reasonably self-documenting), then import the thus-modified PCB file again. (Until you are happy with the integrity of the thus modified PCB file, keep a backup copy of the original PCB file, just in case...) Veterans of AdvPcb 2.8 can tell horror stories about polygons in that version; these could disappear from the PCB file in some situations, while leaving their associated primitives (tracks and arcs) behind. That is one of a number of reasons why I would hate to ever have to use that version again... Regards, Geoff Harland. - E-Mail Disclaimer The Information in this e-mail is confidential and may be legally privileged. It is intended solely for the addressee. Access to this e-mail by anyone else is unauthorised. If you are not the intended recipient, any disclosure, copying, distribution or any action taken or omitted to be taken in reliance on it, is prohibited and may be unlawful. Any opinions or advice contained in this e-mail are confidential and not for public display. * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * 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] Customize layer pairs
I try to creat a footprint which contains special string .designator on mechanical layer 15 and .comment on mechanical layer 14, and set default string height and width to them, both of the string are in the center of the footprint. So I can easily to creat the assembly drawing for debuging and assembly, and need not to move the string on the silkscreen. If all components are on the same side, it looks ok. but if the components are on both side, I should manually change the the special string to different layers, before creat assembly drawing. I wonder if I can customize layer pairs to accomplish that, for example, mechnanical 12 VS mechnanical 14, mechnanical 13 VS mechnanical 15, then if I move a component to another layer, the special string can move to the corresponding layer automatically. Luo. It is not out of the question that a Server could be created which could implement (in a fashion) what you are looking for. But Mechanical layers can not otherwise be paired to one another at present. On assorted occasions I have requested that Altium provide a feature (in Protel) in which users could pair Mechanical layers to one another as required. (I have also suggested that a similar feature be provided in the contemporary version of P-CAD, as such a feature was provided in DOS versions of P-CAD.) To facilitate both the user interface (i.e. dialog boxes) and the associated software requirements, I have also suggested that the ability to pair such layers to one another be restricted to the ability to optionally pair Mech 1 and Mech 2, and/or to pair Mech 3 and Mech 4, ... , and/or to pair Mech 15 and Mech 16. Depending upon which such layers were paired to one another, there would be between 8 pairs of paired Mechanical layers and no pairs of paired Mechanical layers in a particualr PCB file. Thus while Mechanical layers could not be paired to one another arbitrarily, it would still be possible to establish up to eight pairs of paired Mechanical layers, should that number of paired layers actually be required. I don't think that it would be possible to implement this in Protel 99 SE (because of database considerations). But it could probably be implemented in future releases of Protel, and it has certainly been long enough, since I first publicised this suggestion on this forum, for Altium to have been aware of this request. Regards, Geoff Harland. - E-Mail Disclaimer The Information in this e-mail is confidential and may be legally privileged. It is intended solely for the addressee. Access to this e-mail by anyone else is unauthorised. If you are not the intended recipient, any disclosure, copying, distribution or any action taken or omitted to be taken in reliance on it, is prohibited and may be unlawful. Any opinions or advice contained in this e-mail are confidential and not for public display. * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * 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] Panelise several designs
I am currently trying to create an A3 panel of 10 PCB designs I have created using Protel99SE. This saves cost by prototyping several PCB boards at once. When I try to copy and paste the PCB designs using Protel99SE the designs lose their connections to the Internal Plane (which I am using as a Ground Plane). Is there any way around this? (I did ask the PCB manufacturers to place these for me as they will have the correct tools but they refused as this design is a prototype only.) If anybody has any suggestions I would be very greatful to hear them. Kevin Blackmore From the PCB Menu, select Edit/Paste Special In the resulting Paste Special dialog box, check the checkboxes with captions of Keep net name and Duplicate designator. (The Add to component class checkbox will automatically be checked as well after doing this, and that is OK.) When you are subsequently asked if you want polygons to be repoured, answer No. Doing this should work, but check your Gerber files afterwards (which you should do in any case, even when you are not producing a panellised PCB). Camtastic can be used for this, but I am long accustomed to using GC-Prevue for this purpose (and this has the advantage of being *totally* independant of Altium/Protel). Let me know if you continue to have problems. Regards, Geoff Harland. - E-Mail Disclaimer The Information in this e-mail is confidential and may be legally privileged. It is intended solely for the addressee. Access to this e-mail by anyone else is unauthorised. If you are not the intended recipient, any disclosure, copying, distribution or any action taken or omitted to be taken in reliance on it, is prohibited and may be unlawful. Any opinions or advice contained in this e-mail are confidential and not for public display. * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * 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] Mechanical Layers are disappearing
snip When you add a new mechanical layer via Design | Mechanical Layers there is a check box option for Display Single Layer Mode and I was wondering if this was the cause of your problem. Apologies if this has been previously solved, not the original problem, or not even the topic of discussion. snip Brendon. That check box option controls whether the corresponding Mechanical layer is also displayed (or not) when Single Layer Display Mode is selected. (When that mode is selected, the current layer is displayed, and whichever Mechanical layers have been selected in this regard (but only if each of these layers are currently visible in Standard Display mode); all other layers are *not* displayed.) I lean to the view that perhaps some code still needs polishing after the provision of the additional Mechanical layers. Regards, Geoff Harland. - E-Mail Disclaimer The Information in this e-mail is confidential and may be legally privileged. It is intended solely for the addressee. Access to this e-mail by anyone else is unauthorised. If you are not the intended recipient, any disclosure, copying, distribution or any action taken or omitted to be taken in reliance on it, is prohibited and may be unlawful. Any opinions or advice contained in this e-mail are confidential and not for public display. * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * 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 with multiple holes surrounding it.
snip The other way I tried was placing multiple pins *on top of one another* in the schematic part to match 4 different designated pads in the pcb part. It worked, but not as well. As a junction was always placed at the pin end (auto-junction was on) even if only one wire was connecting to it. Looked a bit ugly, not the way to go. Hope this helps. Tom. I agree that the junction is not especially pretty. Having said that, it does provide a visual reminder that the wire is connected to more than one pin (which would not otherwise be obvious). Regards, Geoff Harland. - E-Mail Disclaimer The Information in this e-mail is confidential and may be legally privileged. It is intended solely for the addressee. Access to this e-mail by anyone else is unauthorised. If you are not the intended recipient, any disclosure, copying, distribution or any action taken or omitted to be taken in reliance on it, is prohibited and may be unlawful. Any opinions or advice contained in this e-mail are confidential and not for public display. * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * 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 visibility (ex Multilayer pads)
Can anyone explain to me a way around this problem please? on final checking of boards i normally switch to single layer mode check each layer in turn (esp silk screen moving designators etc) why is it that in single layer mode, when i'm on say the top signal layer, the pads still display as a multilayer pad (i have different sizes on different layers ie smaller on top) but they still display as if they are on the bottom and larger. solder mask is also shown (and i don't want it) That's the way that Protel has implemented Single Layer Display mode (and IMO, those are not the biggest shortcomings associated with Single layer Mode; the display of Solder Mask and Paste Mask layers leaves much to be desired). If you don't want to see Solder Mask layers, switch these off (from the Layers Tab of the Document Options dialog box). Also, can anyone tell me how to (if possibly) assign Design/options/Layers to a button so that i can have different setups and layer displays/colours on a toolbar for when checking bottom silk screen etc. I understand tollbars etc but cannot find the process for these options. Rich Thompson The Process to invoke (to change the visibility of layers) is Pcb:DocumentPreferences. As one example, you could set up a Shortcut key or a Toolbar button to toggle the visibility of the Top signal layer; the parameter to use with that Process would then be TopSignal=Toggle. You can specify more than one parameter, e.g. TopSignal=True|BottomSignal=False; the | character separates different parameters, and those two parameters would switch on the Top signal layer and switch off the Bottom signal layer. (Don't include the quote characters when specifying these parameters; I have done so above solely to indicate the start and end of the parameter strings.) Protel has provided an AdvPcb.hlp file (in the Help subfolder), and this documents the Pcb:DocumentPreferences Process (and other Processes provided by the Pcb Server). The default menu for the Pcb Server has a Help/Macros/Layer Sets... entry, and selecting that invokes a macro which invokes a dialog box. Study the text for that macro to get a feel for how to modify (a copy of) this for your own requirements, or to create your own dialog box. (Or for starters, create a toolbar containing a number of buttons, each of which either selects a set of layers you want, or toggles the visibility of a specific layer.) I have provided an addon Server for use with Protel 99 SE, and you can download that from the Yahoo! website. The URL details are as follows: Webpage to visit: http://groups.yahoo.com/group/protel-users/files/Addon_Servers_99SE_SP6/ File to download from there: PcbAddon_6_6_1.zip (You might have to be a member of the Yahoo! protel-users Mailing List to be able to download that file though.) You need SP6 installed to use that Server, and it could be of interest to you because it incorporates a Process to facilitate changing the visibility of layers (via pushbuttons (many of which incorporate an accelerator key) within a customised dialog box). Hope this helps. (HTH) Regards, Geoff Harland. - E-Mail Disclaimer The Information in this e-mail is confidential and may be legally privileged. It is intended solely for the addressee. Access to this e-mail by anyone else is unauthorised. If you are not the intended recipient, any disclosure, copying, distribution or any action taken or omitted to be taken in reliance on it, is prohibited and may be unlawful. Any opinions or advice contained in this e-mail are confidential and not for public display. * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * 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] Possible Gerber generation bug
*** Todays forums are sponsored by Ian Martin Limited Engineering/Technical Placement Specialists www.ianmartin.com *** It's definitely NOT an RS-274X limitation and I can say that with 100% certainty. I have a colleague who uses a cheap CAD tool which allows the thermal reliefs to be controlled minutely on plane layers and it produces (274X) gerbers with no problems at all. Douglas McDonald Geoff, I am not sure I buy into your explanation either. I will disqualify myself by admitting I have little to no programming experience and even less knowledge of Aperature generation, but I bet it can be fixed. And if it can be fixed then it must be broke. Mike Reagan I think that this is a bug in Protel, and that this *can*, and *should*, be fixed; the way to do that is for thermal relief patterns having just two openings to be *drawn* (rather than flashed) within Gerber files (and regardless of whether thermal relief patterns having four openings are drawn or flashed in these files). (If the PCB designer was prepared to provide an aperture list file and RS274D format Gerber files, perhaps those patterns could be flashed instead in those circumstances, but the onus would then be on the PCB manufacturer (and the PCB designer (to the extent of specifically bringing such apertures to the PCB manufacturer's attention)) to ensure that the PCB is still manufactured satisfactorily.) What I was saying previously was that the RS274X standard does not support flashing thermal relief patterns having just two openings. Given that situation, the associated arcs (of these patterns) should (normally) be drawn instead. I have yet to have cause to design any PCB using such thermal relief patterns, but given my understanding of the situation, if I ever did have to design such a PCB, I would figure out some way of avoiding the problem (if necessary, generating RS274D format Gerber files, and then converting these to RS274X format using a Perl script). However, it definitely is a trap for those who are unaware of the situation, so I fully agree that this is a bug, and that it should be fixed. Regards, Geoff Harland. - E-Mail Disclaimer The Information in this e-mail is confidential and may be legally privileged. It is intended solely for the addressee. Access to this e-mail by anyone else is unauthorised. If you are not the intended recipient, any disclosure, copying, distribution or any action taken or omitted to be taken in reliance on it, is prohibited and may be unlawful. Any opinions or advice contained in this e-mail are confidential and not for public display. * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * 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] ATS
Their wording is odd at best. ATS membership CANNOT be purchased on existing Protel 99 SE licenses. I am concerned that it seems that it seems possible that in the future there will be diminishing support for the existing users, but surely they would not want to loose their existing customer base (us). That would be plainly stupid from their point of view (I hope). I think that they are only trying to catch the new purchaser's, and they will probably have this as standard for any future releases. Wayne Bickers I also suspect that anyone upgrading to (or purchasing) Protel 2001 (or Protel 2002, by the time it comes out of beta testing?) will have no option but to go onto an ATS program. I suspect that such an upgrade or purchase would include membership of the ATS program for 12 months, after which users would then have to pay for the next 12 months membership of the ATS program. Protel 99 SE was released in early 2000, and it is probable that the next version of Protel will be released early next year (based on Altium recently requesting users to apply for membership of the Altium Beta Program). With two years between major releases, long-term users would pay an upgrade fee for each new release, and an ATS membership update fee halfway between the issue of each new release. To that extent, it will be a change from the past. I suspect that anyone who didn't front up with their cash midway between releases would have to pay more next time they upgraded to the next new release (compared with users who *had* thus paid), so that Altium would then recover at least part of the funds that they would otherwise have acquired from those users. It is not as if Altium need the additional funds to keep their shareholders from rioting. So the question is what their users will get in exchange for these additional payments. (It has been a long time since SP6 was released for Protel 99 SE. And since the time it was released, two SPs have been released for use with P-CAD 2001.) But to pay almost $US2k a year, when a seat currently costs almost $US8k, certainly seems steep. Regards, Geoff Harland. - E-Mail Disclaimer The Information in this e-mail is confidential and may be legally privileged. It is intended solely for the addressee. Access to this e-mail by anyone else is unauthorised. If you are not the intended recipient, any disclosure, copying, distribution or any action taken or omitted to be taken in reliance on it, is prohibited and may be unlawful. Any opinions or advice contained in this e-mail are confidential and not for public display. * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * 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] ATS
Perhaps they are after money.. perhaps not.. but as users should we be asking a fee to beta test (or alpha test) their software ? If your in the beta test program why not consider this? Afterall whats good for the goose is good for the gander Simon I think that they are after money. :) The question is whether the new fees are reasonable, given that users have been able to download SPs and addon servers for free up until now. A bit OT, but bank fees in Australia have been controversial for some time. The banks claim that in the past, their wealthier clients cross-subsidised the remaining clients, and for an assortment of reasons, including a more competitive financial services market, they need to impose fees on more of a user-pays basis. But what is making the general Australian public angry is high levels of profits reported by the banks, together with long queues being the norm for those who need to interact with a teller, and the CEO of one particular bank who gives a very good impression of being totally politically naive. It could perhaps be argued that Protel users have not done too badly to date, in that they have been provided with SPs, addon servers, and utilities such as Camtastic 2000 Designer's Edition, without having to specifically pay for these. In spite of that, Altium's shareholders have still done pretty well for themselves, so it is not as if Altium has to change its charging policies in order to avoid financial oblivion. For all that, *perhaps* Altium could still justify introducing new fees, on grounds such as better securing their long-term financial viability. But the question still remains as to whether the *magnitude* of these new fees is reasonable. (SPs do contain some new features, such as the new .Printout_Name Special String in SP6. But another aspect of SPs is bug fixes, and it is questionable whether users should reasonably be expected to have to pay for these to be rectified. After all, MS has released SPs for assorted versions of Windows, and users can download these free of charge.) As for beta testing, my impression is that beta testers are regarded as being in a privileged position, as they get an earlier look in at what new features the next version of software has to offer, and the opportunity, to some extent, of influencing what new features are provided (and/or how these are implemented). But Altium's ATS policy could well change the attitude of at least some would-be beta testers. Giving up time to look at new software (and provide feedback on this) without re-imbursement is one thing, but it could well be another if beta testers are still required to also have to pay for any bug fixes and new features which are released between new versions. Time will tell what attitude Altium takes to beta testers, but I am guessing that unless a sufficiently large number of would-be testers revolt, Altium will not provide any re-imbursement to them (either in the form of payment for feedback provided, and/or discounts for upgrades or ATS fees). I am still thinking about whether I would be prepared to be a beta tester for free. But it would not be just my decision, as I am not self-employed... Regards, Geoff Harland. - E-Mail Disclaimer The Information in this e-mail is confidential and may be legally privileged. It is intended solely for the addressee. Access to this e-mail by anyone else is unauthorised. If you are not the intended recipient, any disclosure, copying, distribution or any action taken or omitted to be taken in reliance on it, is prohibited and may be unlawful. Any opinions or advice contained in this e-mail are confidential and not for public display. * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * 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] ATS
Geoff Harland wrote: It is not as if Altium need the additional funds to keep their shareholders from rioting. So the question is what their users will get in exchange for these additional payments. (It has been a long time since SP6 was released for Protel 99 SE. And since the time it was released, two SPs have been released for use with P-CAD 2001.) But to pay almost $US2k a year, when a seat currently costs almost $US8k, certainly seems steep. That seems to be my big question also. It also seems tough to swallow that it is cost effective to maintain two PCB design packages. The required duplicate resources to maintain and upgrade both just doesn't make sense. ATS may be a precursor to a unified Design package. Jim McGrath I can't remember where I saw it, but I seem to recall reading somewhere that Altium had visions of providing a Client application, from which either Protel servers or PCAD servers could be launched (presumably depending upon what package the customer had purchased). Even though that does not in itself equate to a total merger of Protel and PCAD, there are definitely assorted developments which suggest that they are converging. Protel is supposedly targeted for engineers who do a variety of tasks, while PCAD is supposedly targeted for those who doing nothing else but CAD work. However, the difference in price between these products has narrowed, and the announcement of the ATS package increases yet further the similarities between them (as PCAD 2001 users have previously had the option of a PCAD Total Support package, which at ~ 20% of the cost of a new license per annum, translates to ~ US$2k / year). Adding certain new features to Protel, such as being able to define new layers as required, would result in yet greater similarities between Protel and PCAD. There are assorted aspects which are (currently) notably different, but ... Regards, Geoff Harland. - E-Mail Disclaimer The Information in this e-mail is confidential and may be legally privileged. It is intended solely for the addressee. Access to this e-mail by anyone else is unauthorised. If you are not the intended recipient, any disclosure, copying, distribution or any action taken or omitted to be taken in reliance on it, is prohibited and may be unlawful. Any opinions or advice contained in this e-mail are confidential and not for public display. * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * 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] Protel addons (ex Re Altium changes)
snip ... How about providing more detailed documentation for Protel, or providing user-friendly tools to allow customer development of Protel add-ons. ... snip Daniel Webster Altium have provided SDK files for those who want to create their own addon servers, and I have created, and released, some myself. However, there is an associated NDA which prevents me (or anyone else who has downloaded these) from saying too much about the SDK files. But it is public knowledge that you also need to have a copy of Delphi 5 (plus of course the knowledge of how to use this) in order to create any addon servers. Ian Wilson and I have had intentions (for some time) of releasing an addon server which could be used to invert PCB files (i.e. put top side components on the bottom side, and vice versa). Consider reading between the lines as to why we have not released a final version yet... Regards, Geoff Harland. - E-Mail Disclaimer The Information in this e-mail is confidential and may be legally privileged. It is intended solely for the addressee. Access to this e-mail by anyone else is unauthorised. If you are not the intended recipient, any disclosure, copying, distribution or any action taken or omitted to be taken in reliance on it, is prohibited and may be unlawful. Any opinions or advice contained in this e-mail are confidential and not for public display. * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * 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] minor display refresh bug
P99SE SP6, PCB Editor With Top Solder Mask and Outline (I name Mechanical 1 Outline) enabled, as initially displayed, with Outline being the current layer, only actual primitives on the Solder Mask and Outline layers are displayed. The calculated solder mask pads are not displayed. snip Abd ul-Rahman Lomax I suspect that we have all seen this sort of behavior in various conditions, it is irritating. It is certainly worth bringing it up so it can be discussed and Altium may make it an official bug. This has been a long standing aspect of Protel. My interpretation of what is happening is that pads on the external copper layers (and the MultiLayer layer) are imaged on the Solder Mask and Paste Mask layers, and as such, the software released to date does not always properly display what is really present on the Solder Mask and Paste Mask layers. (If the MultiLayer layer is *not* displayed, even images of pads on that layer are not always properly displayed on the Solder Mask layers.) I think that there is some relationship here with the fact that multi-layer is a layer rather than a collection of other layers (subtle difference) but it has significant ramifications during the various combinations and permutations of display configuration. I think I would like to be able to define named collections of layers that can be used during pad stack creation and display manipulation. With this technique, multi-layer as an explicit layer is no longer needed - it merely becomes a layer collection consisting of all copper layers. Any pros or cons for this idea. Ian Wilson There are arguments for and against providing the Multilayer layer. One argument for retaining it, or at least for pad and via objects (if not for arc, fill, track, and string objects), is that the *same* pad or via exists on *different* copper layers, and that aspect matches real world vias and through-hole pads. OTOH, given that a hierarchical structure exists in PCB files (e.g. component, polygon, coordinate and dimension objects), this could be extended so that pad and via objects themselves have a hierarchical structure. As such, users could define default settings for each layer, while also having the ability to customise (i.e. over-ride) the settings for each individual layer as required (including Solder Mask layers, Paste Mask layers, and even Power Plane layers). However, I also consider that efforts to change or enhance pad and via objects would open a very large can of worms. Amongst the issues to consider (but certainly not the only issues concerned) are whether properties associated with the Solder Mask layers, Paste Mask layers, and Power Plane layers should be set by Design Rules, or by dialog boxes, or by either of those options. (I have spoken on that matter previously; at present, listings of Design Rules do not report settings which have been customised by usage of dialog boxes.) Abd ul-Rahman Lomax has also recently mentioned that blind and buried vias are sometimes inappropriately displayed. I concur that this could be regarded as a bug, but apart from that, I personally don't regard the MultiLayer layer as being bad in nature. It is a special layer, like the Drill Draw, Drill Guide and Keep Out layers, but PCB applications differ from general purpose CAD applications (such as Autocad) in that there is a good case for special layers to be provided. I think that pad and via objects could be enhanced. However, we should be very careful about what we ask for... Regards, Geoff Harland. - E-Mail Disclaimer The Information in this e-mail is confidential and may be legally privileged. It is intended solely for the addressee. Access to this e-mail by anyone else is unauthorised. If you are not the intended recipient, any disclosure, copying, distribution or any action taken or omitted to be taken in reliance on it, is prohibited and may be unlawful. Any opinions or advice contained in this e-mail are confidential and not for public display. * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * 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] Padstack
Can anyone tell me if it is possible make a via or pad that is connected to the Vcc net on the top and bottom layers only. TI do not want to connect it to the inner Vcc plane as the decoupling caps are on the secondary side of the pcb and I want the voltage to see them before the leg of the IC. I tried making a pad and using the padstack to not connect to the middle layers but was not sucessful. Wesley Webb As others have suggested, use a (MultiLayer) pad instead of a via, and define a Design Rule so that there are no connections to that pad on any internal Power Plane layers. A possible problem with using pads (instead of vias) is that non-single-layer pads are always through-hole in nature (whereas vias can also be blind or buried in nature). As such, if a blind or buried via is desired, *and* it is desirable to have this *not* connect to one or more internal Power Plane layers (that are amongst those layers occupied by the via), I would then go for adding pads on those internal Power Plane layers as required (in the same location as the via concerned). (And if the via is moved, these pads should also be moved at the same time.) I previously mentioned that I would provide a post on the MultiLayer layer, pads, and vias. I have not forgotten about that intention, and I still intend to do so. At this stage though, with pads and vias having reared their head again, I will mention that I see merit in retaining the distinction between pads and vias. When Pad Master printouts or Gerber files are produced, vias are *not* included in these, and that aspect would be lost if vias ceased to be a distinct type of object. As such, this thread suggests that there is merit in the concept of being able to assign names/designators to vias. If implemented, Design Rules could then be defined to control assorted properties of individual vias, with the application of such Design Rules then being selectable by the name/designator assigned to each via. (The (AdvPcb) 2.8 (i.e. dialog box determined) approach would avoid the requirement to assign names to vias, but that would rule out the possibility of being able to set the properties of vias on a selective basis by the use of Design Rules, as well as making it more difficult to determine which vias have particular properties.) Another difference between pads and vias is that (unlike vias) pads can not be blind or buried in nature, i.e. occupy more than one copper layer, but not *all* of those layers. Off-hand, I do not see any merit in being able to define *pads* (as opposed to vias) that have a blind or buried nature, but if anyone thinks differently, then let us all know, and why. Does anyone see merit in being able to define *vias* with obround/rectangular/octagonal shape (rather than just circular shape), or with different shapes and/or dimensions on different layers? (At present that can be accomplished for through hole connections, by using pad objects instead of via objects, but not for blind or buried connections.) My view is that the purpose of vias is to provide connections between different copper layers, and as such, a circular shape does the job just fine, as the associated *hole* is also circular in shape (and also has the same diameter for each copper layer it encounters). But given that I think that there is a case for being able to control *other* properties of vias, such as internal Power Plane layer connection details, polygon connection details, and Solder Mask layer properties (including the ability to set these properties for *each* of those layers), maybe padstacks properties are yet another aspect of vias that could also be user-controllable. More in another post (next week I hope, and maybe I can find time this weekend to write some of the details). For the time being, I am ambivalent about the MultiLayer layer. I suspect that this could be totally eliminated from future (major) versions of Protel, but I am not at all convinced that this would necessarily be a good idea. That is not to say that this layer is devoid of shortcomings, but I currently lean to the view that totally dumping that layer would be somewhat akin to throwing out the baby with the bathwater... Regards, Geoff Harland. - E-Mail Disclaimer The Information in this e-mail is confidential and may be legally privileged. It is intended solely for the addressee. Access to this e-mail by anyone else is unauthorised. If you are not the intended recipient, any disclosure, copying, distribution or any action taken or omitted to be taken in reliance on it, is prohibited and may be unlawful. Any opinions or advice contained in this e-mail are confidential and not for public display. * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * 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
Re: [PEDA] file format compatibility P98 - P99SE
does anyone know, if object file formats '.sch' (schematic), '.lib' (schematic library, pcb library) and '.pcb' are compatible between P99SE and the older versions P98 and P3? Where and what are the differences? Can I take (e. g.) a pcb file of P99SE, change it using P98 and work with it using P99SE later on? Mike To *some* extent, yes. However, features which are *not* provided in Protel 98 (e.g. the new layers, Keepout arcs, tracks, and fills, comments for Design Rules, layer stackup data, via connections to Power Plane layers, etc) will be lost if a file is edited using Protel 98 (if it was previously created/edited using Protel 99 SE). Such features wouldn't be lost if they weren't used in the first place though, of course. A PCB file needs to be saved/exported using the Protel 98 binary option before it can then be opened using Protel 98. Having said all that, I don't see why you would want to work on a PCB file using Protel 98. If the file was originally created using Protel 99 SE, I don't see any merit in then attempting to edit that while using Protel 98. Regards, Geoff Harland. - E-Mail Disclaimer The Information in this e-mail is confidential and may be legally privileged. It is intended solely for the addressee. Access to this e-mail by anyone else is unauthorised. If you are not the intended recipient, any disclosure, copying, distribution or any action taken or omitted to be taken in reliance on it, is prohibited and may be unlawful. Any opinions or advice contained in this e-mail are confidential and not for public display. * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * 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] SPs for earlier versions (ex Altium Total Support Brochure)
I have just downloaded SP3 for EDA98 from the archive but there was no onscreen form to fill out. Try protel.com.au instead of protel .com. I used the Jan 2000 archive Ian Capps Maybe Altium really don't still have a copy of SP3 for EDA98, or SP1 for EDA3, but I for one would be surprised if that really was the case. (That would also be ironic to boot, in that they would then be dependant upon their customers to provide such files if they ever wanted to create an archive of previous releases of software.) So I believe that in all probability they *do* still have a copy of these files (even though they seem to have assessed that there is no longer a case for having them available for download from Protel's Website(s)). As such, it would not be impossible for them to provide copies of this file to those who requested it. (From their own records, they should be able to determine whether anyone requesting either of these files is a legitimate owner of EDA3 or EDA98, and even if they didn't (still) have such records, the provision of such SPs, *by themselves*, would be of no use to anyone.) A possible reason that comes to mind as to why these SPs are not being provided to those requesting them is that the users would supposedly then have a greater incentive to purchase (or upgrade to) the most recent version of Protel. OTOH, such an attitude could be regarded as customer-hostile, and provide such customers with an incentive to seek out who else is providing CAD applications. I have mentioned previously (though over a year ago) about an experience in my previous job, in which my then-employer had purchased a Cooper and Chyan/Specctra auto-routing package. At the time that this was provided, no indication was given that the associated dongle could be destroyed if it was connected to the wrong type of parallel port, or if the parallel port was not correctly configured. As such, we managed to destroy two dongles before figuring out, largely by ourselves, that we should connect the dongle to a classic parallel port (to which end we purchased an ISA bus plugin PCB providing such a port). The time came when my PC was replaced by a faster model (from a 100MHz 486 to a 200MHz Pentium, if I recall correctly). And while I shifted the plugin parallel port card from my old PC to my new PC, Specctra still did not run on my new PC, and we figured that this (PC) was too fast for the version of Specctra that had been purchased. Advice was solicited from various parties as to how this problem could be overcome, but no feedback was provided to that end, other than to upgrade to the most recent version of Specctra (which would have cost at least as much as the original purchase). In due course, Simon Peacock (who also used to work for the same company, and who is another member of this forum) discovered, from a posting to a newsgroup (sci.electronics.cad?), that the fix was to declare some Environment variables which would then inform the software how fast the PC was running. After I did that, the software then ran OK on my new PC (in reality, as well as it was given to running; I recall at least one occasion when I had visions of the software running overnight, but it refused to start (before I knocked off work for the day) following at least six attempts to achieve that, on the belief that I had turned the PC's clock back (which I had *not* done at the time)). All up, a story with unhappy aspects. (I haven't mentioned all of the details that brassed me off at the time, and it probably wouldn't be prudent for me to do so, but I'll settle for saying that some people underline why most cultures insist upon marriage before children.) It's an old saying that monopolies don't have to apologise to their customers. However, when competition does exist, it is a bad move to alienate your customers, and when competition doesn't exist (or is weak), bad attitudes can result in customers taking their complaints to a regulatory agency. And some times, in some places, these agencies kick a*** ... Regards, Geoff Harland. - E-Mail Disclaimer The Information in this e-mail is confidential and may be legally privileged. It is intended solely for the addressee. Access to this e-mail by anyone else is unauthorised. If you are not the intended recipient, any disclosure, copying, distribution or any action taken or omitted to be taken in reliance on it, is prohibited and may be unlawful. Any opinions or advice contained in this e-mail are confidential and not for public display. * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * 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] Using Multiple Vcc for same part
of these types, e.g. _H for the single part component with hidden power and ground pins, _S for the single part component with no hidden pins, _D for the dual part component, etc. What could help in this regard could be the provision of some type of utility or addon server with which the user can specify all of the associated details *once*, with some type of wizard interface to make the procedure more user-friendly. Once all of the details had been specified, the associated components would then be added, automatically, in an initial form, to *all* of the appropriate library files. At that point, the user could further edit the components within each of those files if so desired, e.g. to fine-tune the relative positions and orientations of each pin, etc. I created and sent this post not with the intention to troll, but to pass on my thoughts on this matter, and hopefully to stimulate further discussion. There is another matter I would also like to comment on concerning schematic components, to wit, being able to re-arrange pins (locations and orientations) within components within schematic files (as opposed to schematic *library* files). In DOS versions of Protel's schematic editor, that was possible, and it would be nice if that feature could be restored. Those versions of Protel also permitted users to change *other* properties of pins, e.g. pin number and pin type, and while I am *not* advocating that that aspect should (also) be restored, the restoration of the ability to re-arrange pins would still be desirable in many situations. As such, a *qualified* restoration of that aspect of those versions of Protel. Perhaps there is something to be said for being able to inhibit the re-arrangement of pins by adding a locked property to each part. When a part is locked, the pins can't be re-arranged, and that would cater for those who don't want that capability. (Is there something to be said for all pins to be restored to their default locations if an unlocked part is placed in a locked state again? And should the ability to unlock parts be inhibitable by means of some type of global/system setting? ...) I have other things to do for now, but let the discussions continue... Regards, Geoff Harland. - E-Mail Disclaimer The Information in this e-mail is confidential and may be legally privileged. It is intended solely for the addressee. Access to this e-mail by anyone else is unauthorised. If you are not the intended recipient, any disclosure, copying, distribution or any action taken or omitted to be taken in reliance on it, is prohibited and may be unlawful. Any opinions or advice contained in this e-mail are confidential and not for public display. * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * 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] SPs for earlier versions (ex Altium Total Support Brochure)
mirror (most) other objects, but not components, which would be a break from past behaviour. What do others think about this matter? Regards, Geoff Harland. - E-Mail Disclaimer The Information in this e-mail is confidential and may be legally privileged. It is intended solely for the addressee. Access to this e-mail by anyone else is unauthorised. If you are not the intended recipient, any disclosure, copying, distribution or any action taken or omitted to be taken in reliance on it, is prohibited and may be unlawful. Any opinions or advice contained in this e-mail are confidential and not for public display. * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * 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] PCB Move-Component selection filter doesn't stick
Yeah that's great and would fit in just fine with what I requested. If the field is maintained between accesses to that dialog, it would do what I want, and in your case the user would have to change the R* to a C* anyway, so there is no difference to them. If they want to randomly pick various part types, just leave it as *. Late for Phoenix? They haven't even started beta testing. I think a little change like this would take a programmer 10 minutes. At least that's how fast my programmers change little features! :) Tony The code itself shouldn't take too long, but there could be database implications; if so, it could be far less straightforward to add this feature. I haven't been asked to be a beta tester for Phoenix (or at least not yet), but that doesn't mean to say that nobody else has been approached in this regard. So for all I know, there could be other users beta testing this already Regards, Geoff Harland. - E-Mail Disclaimer The Information in this e-mail is confidential and may be legally privileged. It is intended solely for the addressee. Access to this e-mail by anyone else is unauthorised. If you are not the intended recipient, any disclosure, copying, distribution or any action taken or omitted to be taken in reliance on it, is prohibited and may be unlawful. Any opinions or advice contained in this e-mail are confidential and not for public display. * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * 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] Beta testing (ex PCB Move-Component selection filter doesn't stick)
I have vague recollection about some of us being asked to participate and I know *I* haven't started yet. I hope they are serious about testing or are planning to slip the release date. Tony The websites for Protel and PCAD invite their visitors to apply to become beta testers for Altium products (which I have done). ISTR that a message was also posted to the Protel and PCAD mailing lists advising users to apply to become a beta tester (if they thought they were suitable for that task). However, other postings to this forum suggest that being accepted as a beta tester doesn't imply that such users will necessarily be asked to test *all* releases of beta software. The last I heard, Phoenix is supposed to be released during Q1/2002. As such, it could be released as late as late March next year without slipping from that schedule. If nobody is beta testing as of yet, that suggests a reasonably tight schedule, but for all I know, there could be some users beta testing already (possibly with NDAs requiring them to refrain from disclosing that they actually are beta testers). It could be argued as to how long is suitable for beta testing. A long test period *should* result in more bugs being found (hopefully all of them), but the counter argument is to ship product ASAP. As I suspect that some bugs will in fact slip through (regardless of how long the beta testing period is), what will be at least as critical is how long it will take to release followup SPs (and how many of these there will be)... Regards, Geoff Harland. - E-Mail Disclaimer The Information in this e-mail is confidential and may be legally privileged. It is intended solely for the addressee. Access to this e-mail by anyone else is unauthorised. If you are not the intended recipient, any disclosure, copying, distribution or any action taken or omitted to be taken in reliance on it, is prohibited and may be unlawful. Any opinions or advice contained in this e-mail are confidential and not for public display. * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * 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 does not really export to Orcad Capture...
At 08:10 AM 12/11/01 +0100, Emanuel Zimmermann wrote: - Export Protel Schematic as PCAD ASCI How? My 99SE SP6 system does not seem to have this option. The Protel add-on site has a PCAD translation pack, but it says that this is included in SP6. Abdulrahman Lomax The list of Servers for my installation of Protel 99 SE (SP6 installed) includes LoadPCADPCB, LoadPCADSCH, SavePCADPCB, and SavePCADSCH servers, which can be used to import or export files in P-CAD (ASCII) format. I did not download these from Protel's Website per se, as they were included as part of SP6. The *default* set of Resources (toolbars, menus, and shortcut keys) is not set up to invoke any of the Processes provided by these Servers, but these Processes can still be invoked, if desired, by either customising your Resources, or by clicking on the downwards facing arrow to the left of the menu, and then clicking on the Run Process... item on the resulting popup menu. (That results in the invocation of a Run Process dialog box, with which you can select whichever Process you want invoked (and with parameters of your choice, if so required).) I don't have much experience with these Servers, but I have exported a PCB file in P-CAD format on a few occasions (while I was trying out the trial version of P-CAD 2001). My recollections were that if two components having the same footprint property had differing numbers for corresponding pads, P-CAD 2001's PCB application spat the dummy when I then attempted to open the thus exported file (and as such the fix was to ensure that corresponding pads (within different components having the same footprint) *didn't* have differing numbers before exporting the associated PCB file in P-CAD format). I didn't acquire any experience with importing any types of files into Protel 99 SE, or of exporting any types of schematic files (or schematic library files) (from Protel 99 SE). But in the event that problems are encountered while attempting to open a file (exported from Protel 99 SE) in P-CAD's Schematic application, I would suggest reading the contents of any error messages / error report generated, and then taking any remedial action as required. Regards, Geoff Harland. - E-Mail Disclaimer The Information in this e-mail is confidential and may be legally privileged. It is intended solely for the addressee. Access to this e-mail by anyone else is unauthorised. If you are not the intended recipient, any disclosure, copying, distribution or any action taken or omitted to be taken in reliance on it, is prohibited and may be unlawful. Any opinions or advice contained in this e-mail are confidential and not for public display. * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * 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 does not really export to Orcad Capture PROTEL TO ORCAD CAPTURE
At 07:54 AM 12/12/01 +0100, Emanuel Zimmermann wrote: - Open the schematic - Under File-Menu choose Export - In the popped up sub-menu choose PCAD 2000 ASCI If that worked for me I would have already done it. The menu option is not there in my SP6 installation. It might have been there at one time from the old prerelease PCAD translator. I'll look into the other suggestions that were given Abdulrahman Lomax You learn something every day... I was not previously aware that that PCAD (2000 ASCII) option was available with the File/Export... menu item. (I sometimes *import* files while using Protel 99 SE, but don't have too much cause to *export* files instead/as well.) ISTR that when the final version of SP6 was released, I uninstalled some (trial?) servers which had been released between the final versions of SP5 and SP6, because those servers were incorporated within the final version of SP6. Perhaps anyone who had not done this may have ended up with a set of Resources with which exporting files in PCAD format was not provided anywhere... On a slightly different note, SP3 has (very) recently been released for P-CAD 2001. (Then again, P-CAD 2001 licences have always been on an Altium Total Support type setup, even though this was not designated as such, until recently.) Regards, Geoff Harland. - E-Mail Disclaimer The Information in this e-mail is confidential and may be legally privileged. It is intended solely for the addressee. Access to this e-mail by anyone else is unauthorised. If you are not the intended recipient, any disclosure, copying, distribution or any action taken or omitted to be taken in reliance on it, is prohibited and may be unlawful. Any opinions or advice contained in this e-mail are confidential and not for public display. * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * 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 article from Australian electronic news Dec mag
What the h*** does organic growth mean in this context? Organic growth in the vege garden infers the use of natural fertilisers such as that produced by cows. Therefore, in this context it must mean growth in sales based on BS. :-) Steve Baldwin Not especially Protel related, but my recollections of material (BS?) put out by the organic farming movement is that cows' excrement is supposedly excellent for restoring/sustaining land being used for agricultural purposes, whereas BS, OTOH, is supposedly absolutely useless in this regard (does it lack soil-nurturing compounds found in CS?). Having said that, you still provided an entertaining interpretation though. :) Regards, Geoff Harland. - E-Mail Disclaimer The Information in this e-mail is confidential and may be legally privileged. It is intended solely for the addressee. Access to this e-mail by anyone else is unauthorised. If you are not the intended recipient, any disclosure, copying, distribution or any action taken or omitted to be taken in reliance on it, is prohibited and may be unlawful. Any opinions or advice contained in this e-mail are confidential and not for public display. * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * 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] License number not accepted
I've tried entering my Protel 99SE license number (purchased before 1 Oct 2001) and this link doesn't work. My local Protel distributor was under the impression this was for ATS members only. Would anyone care to email the Protel 99SE training manual to me? Andrew Ircha What I don't understand is why would you not let all users have a document that helps you use there software??? It is not like they couldn't do with all the documentation help they (Protel) can get. Darren Moore My guess is that Altium has figured that many of the people using Protel do not have a kosher copy of this, and by providing additional documentation *solely* to those who can prove that they *are* kosher users, such users will then be at an advantage over the other users (who will need to continue relying solely upon whatever Help and/or Acrobat files were provided with their non-kosher copy of Protel). (In the past, Protel didn't lose an excessive amount of sleep over such use; their reasoning was that at least some of these users would eventually become legitimate users. But now that Altium is a publicly listed company, I surmise that not only are there now more financially demanding objectives for Altium to comply with, but there is also an increased requirement for Altium's activities and policies to pass muster when these are put under the microscope by market analysts.) I guess this provides a taste of what is to come (and is a dress rehearsal by Altium for future usage). I can see future SPs, addon Servers, etc, being available for download solely to those who can provide a valid ATS code at the time... Regards, Geoff Harland. - E-Mail Disclaimer The Information in this e-mail is confidential and may be legally privileged. It is intended solely for the addressee. Access to this e-mail by anyone else is unauthorised. If you are not the intended recipient, any disclosure, copying, distribution or any action taken or omitted to be taken in reliance on it, is prohibited and may be unlawful. Any opinions or advice contained in this e-mail are confidential and not for public display. * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * 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] Design Rules
Does anyone know if it is possible (or how to) set a design rule to check between the overlay and the soldermask layers? If you place a designator over a pad or via then it does not appear correctly on the finished PCB. I have simplified the solution to check the reference designators versus the [inverted] soldermask of the same side and make sure they don't overlap. I was hoping to automate the process with a design rule. Any ideas? Anthony Whitesell Out of luck I think - there is no possibility using the current set of design rules (from memory). I was asked about this some time ago and spent a little time looking at it but I can't even remember where we got to. I know I am still doing it with a visual check so I guess I did not work out a better way. I would certainly like a better solution. A server could be written to do the check but there is absolutely no incentive in writing such servers unless you have lots of free time or your company will pay you to do it. There may be some combination layer colours and Transparent layer colouring that would show up violations clearly but this does not do much for mis-registration (there is no clearance parameter). I know that some of the CAM packages can do an overlay/silkscreen cut to prevent text on pads but I do not know if Camtastic has such a checking function. A design rule would be nice. Ian Wilson I do not know if any of the higher priced packages accomplish this check. I do know that even Allegro's Autosilk function does not correctly or always prevent text on pads. Valor does check for these violations, though it may not be an economical solution. Cheers! Drew (Andrew W. Riley III) In a past job, I used the AD2.0 version of PCAD (a DOS version of that application), and that provided a configurable DRC capability (albiet not in Protel's on-line form). Although I never tried it at the time, it is not totally out of the question that its DRC feature might have been configurable to have checked for overlaps between items on silkscreen layers and items on soldermask layers (on the same side of the PCB). (Simon Peacock (or anyone else), can you comment on this?) Like Ian Wilson, I have also contemplated the possibility of creating an addon server incorporating a process which could check for such overlaps. Although I have yet to have written any associated code, it is my belief that, for the most part, such a process could be created, but my gut feeling is that text objects (strings) probably would be problematic to some extent. (I have designed various PCBs in which the bounding rectangle of a string encompasses the area occupied by a via, but the actual text itself still misses the area occupied by the via.) I have already released some other processes within addon servers on a freeware basis, but to create this process would impose demands upon my time which would prevent me from releasing it any time soon. Other postings to this forum suggest that Phoenix (the name currently assigned to the next version of Protel) is currently undergoing beta testing. I am not a beta tester for this myself, but it is not totally out the question that Phoenix could incorporate this feature; although it has been a while since the issue was last raised on this forum, various correspondents have still previously commented on this feature and requested it from time to time. So wait and see what is provided in any public prerelease and/or trial versions of this... My way of checking for overlaps is by visual inspection, both from the Protel PCB file itself, and from the Gerber files produced from that (while using a Gerber file viewer, such as Graphicode's GC-Prevue freeware application). In the absense of any automated checking feature, that is about the only way to do it, but I certainly concur on the merits of having automated checking provided for this. Regards, Geoff Harland. - E-Mail Disclaimer The Information in this e-mail is confidential and may be legally privileged. It is intended solely for the addressee. Access to this e-mail by anyone else is unauthorised. If you are not the intended recipient, any disclosure, copying, distribution or any action taken or omitted to be taken in reliance on it, is prohibited and may be unlawful. Any opinions or advice contained in this e-mail are confidential and not for public display. * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * 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] closing pads on paste mask
Some boards are party assembled and some places for components left free. For this purpose the production wants a paste mask with closed pads for this parts. Has anybody an idea how this is done clever. Georg Beckmann Define a (Paste Mask Expansion) Design Rule, and set an expansion value which is sufficiently negative to mask all of the pads concerned. I would suggest defining a Component Class, with a name like NoPasteMask (for instance), and add all appropriate components to that class. The Design Rule's selection criteria should then be that (component) class. Regards, Geoff Harland. - E-Mail Disclaimer The Information in this e-mail is confidential and may be legally privileged. It is intended solely for the addressee. Access to this e-mail by anyone else is unauthorised. If you are not the intended recipient, any disclosure, copying, distribution or any action taken or omitted to be taken in reliance on it, is prohibited and may be unlawful. Any opinions or advice contained in this e-mail are confidential and not for public display. * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * 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] SV: Polygon at non 45degree angles
Wayne Trow wrote: WELL Bugger me with a broomstick !! I believe this was tried in New York a few years ago, and it ended up costing the city over $10 million after the case wound through the courts. Jon I wondered at the time whether Wayne's previous post would result in some type of response. :) I was wrong Nicholas, you can do arcs. I have had a bit of experience in using arcs with polygon boundaries. It is possible to set an arc to be convex or concave in nature, but care is required in positioning the cursor at the time. And arcs are always 90 degrees in arc length, so to turn around 180 degrees needs two arcs (one immediately after the other). As far as I can tell, it is not at all easy to edit the properties of arc segments, such as radius or location (whereas the locations of vertices at the ends of straight edges can be relatively easily repositioned, deleted, or added). It has also been my experience that arcs sometimes turn inside out when the associated polygon is moved and/or mirrored, in that a 90 degree concave arc (for instance) turns into a 270 degree convex arc. ISTR that this can happen with both Protel 98 and Protel 99 SE. In some cases, the only cure is to replace the polygon. I am hoping to see big improvements re polygons in Phoenix. Time will tell whether this actually happens or not... Regards, Geoff Harland. - E-Mail Disclaimer The Information in this e-mail is confidential and may be legally privileged. It is intended solely for the addressee. Access to this e-mail by anyone else is unauthorised. If you are not the intended recipient, any disclosure, copying, distribution or any action taken or omitted to be taken in reliance on it, is prohibited and may be unlawful. Any opinions or advice contained in this e-mail are confidential and not for public display. * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * 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] Unfortunate Blazerouter
snip ... I worked with PHD math major who walked around with a coffee mug most of the time sharing his paradoxes of math algorithms and equating them to real world applications. He once told me the boring mathematical theory how to stack oranges in the most efficient manner. Yes there was a formula to it. There was also the stock boy with a 6th grade education working in the produce section of a grocery store who already knew without a proof that the most efficient method was to stack them side by side and build the orange pyramid in the isle. My understanding is that mathematicians have had very strong suspicions, and for some time, that the pyramid pattern is the most efficient possible for stacking spheres (i.e. in terms of minimising the unoccupied volume between adjacent spheres). The rub, however, is to actually prove that (which I gather *has* now occurred, but only within the last five or so years). There are some other (still) outstanding conjectures, such as that every even number greater than two can be expressed as the sum of two prime numbers. (Mathematicians apparently regard the number one as an unit number, rather than as a prime or composite number, so this conjecture subsequently does not also apply to the number two.) snip I have my checkbook open and am waiting for the new router.If 99SE is any indication of how good these guys in AU can write software then the new router should shake the industry . Mike Reagan I am also interested in seeing how good a job the new autorouter will do. *If* it really is something to behold, that in itself should make it worthwhile to write out a cheque for upgrading to Phoenix. However, until I do get to evaluate it, I am retaining at least some scepticism. It is all very worthwhile to determine which routes exist, topologically speaking, but I would also consider it important to determine the track carrying capacity/maximum track count of each available route, and fairly early on in the piece (rather than at a later stage, which the literature released by Altium to date suggests is happening). And what is straightforward for humans to recognise visually cannot always be translated into algorithms in a straightforward manner. But if the code has been written from scratch, then hopefully it will integrate much better with the PCB editor than has been the case to date (as I gather that much of the code used in previous and existing autorouting servers has been acquired rather than specifically written for use with Protel). We are living in interesting times (though wishing that on someone is said to be a Chinese curse :) ) ... Regards, Geoff Harland. - E-Mail Disclaimer The Information in this e-mail is confidential and may be legally privileged. It is intended solely for the addressee. Access to this e-mail by anyone else is unauthorised. If you are not the intended recipient, any disclosure, copying, distribution or any action taken or omitted to be taken in reliance on it, is prohibited and may be unlawful. Any opinions or advice contained in this e-mail are confidential and not for public display. * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * 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 99 PCB file format?
snip The SDK will be of some use as you can map values seen in the ASCII file to ranges for the various types (whose values are not given in the SDK documentation but can be found either by browsing the SDK files or by a process of experimentation. Rant on Note that the SDK is covered by an NDA that prevents public discussion. The NDA has a one year limit. Those that have downloaded the SDK more than a year ago are free to discuss it (as I see things anyway). Those who have downloaded it more recently are restricted in what the can legally say. Since you are not a user you may not care but people who use Protel for their bread and butter are likely to be more wary. The situation is complicated a little by the fact that as well as the original SDK files there was an update (two actually) and these are presumably covered by the same NDA - so the one year time out may be reset to the latest of the dates one downloaded an update or maybe just the changes in the run-time update are restricted for the longer period. Also, I have asked, on a number of occasions, that Protel release the users from the NDA to allow user-based help (as Protel Support do not officially support the SDK), but was recently informed this would not happen. Protel closed the moderated pre-release discussion forum which closed the only option we (legally) have for discussing the SDK, though on two occasions I have been referred (by Protel) to the PDEV mailing list and told I can discuss issue on the SDK there - in contravention of the SDK, unless the 1 year limit has elapsed and was not reset by the download of the SP6 run time update. Confused? I am? I have lots to discuss on the SDK but nowhere to do it? This is one major aspect of Protel that I am really p***ed off about. Rant off, Ian Wilson It has now been more than a year since I downloaded the second update for the SDK files (and in any event neither that update nor the previous update provided any updates to the *documentation* provided with the original release of SDK files; both updates incorporated just files of a compiled nature). As such, I consider that discussion of the SDK files should now be kosher, or at least for those who, like myself, downloaded the second update more than one year ago. I know that you are aware that I consider that the SDK files incorporate code of a broken/incomplete/misdocumented/undocumented nature; the handling of layer pairs and layer stackup specifications, for starters. I would have liked to have seen our PCB Inverting server develop through to a functioning product, but those aspects have been problematic... Last year, I took a look at the trial version of PCAD 2001, and that provides a similar capability for users to create their own addon software, using (Altium provided) DBX files, which can be used with either MS VB or MS VC++ (or even with Delphi, after porting the source code originally provided for use with MS VC++ (which has actually been done by one of PCAD 2001's power users)). These DBX files are provided by default (even with the trial version), and there is no associated NDA that users have to be a signatory to (for either the purchased or trial versions). As such, I am at a loss as to why Protel 99 SE users wanting to use the SDK files are expected to be a signatory to a NDA (and there was no such NDA for using the CSDK files released for use with Protel 3 or Protel 98). As the boss depicted in the local TV advt for Yellow Pages says, Not happy, Jan! Regards, Geoff Harland. - E-Mail Disclaimer The Information in this e-mail is confidential and may be legally privileged. It is intended solely for the addressee. Access to this e-mail by anyone else is unauthorised. If you are not the intended recipient, any disclosure, copying, distribution or any action taken or omitted to be taken in reliance on it, is prohibited and may be unlawful. Any opinions or advice contained in this e-mail are confidential and not for public display. * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * 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] Cursors
Nice one Geoff, I usually use the large 90 but the small 45 cursor will also come in very handy now that I have your select cursor sever set up on a hot key. Thanks. Thomas I'm glad to hear you appreciate my efforts. I've had a bit of feedback to date on the Servers I've released, but I've hardly been overwhelmed by this. :) Regards, Geoff Harland. - E-Mail Disclaimer The Information in this e-mail is confidential and may be legally privileged. It is intended solely for the addressee. Access to this e-mail by anyone else is unauthorised. If you are not the intended recipient, any disclosure, copying, distribution or any action taken or omitted to be taken in reliance on it, is prohibited and may be unlawful. Any opinions or advice contained in this e-mail are confidential and not for public display. * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * 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 Files.
I'm currently having some problems generating correct gerber files for my manufacturer. They say that some of the information is missing from the files that I have sent them. Apparently I am not the only one to have such problems with the generation of gerber files using protel - but there is (so I am told) a way to create correct files. Has anyone come across this problem before and know how to fix it?? BTW: Apologies if this has been discussed before - I searched the archives and found nothing. Is there a browsable archive list for this group somewhere. David Braendler You will need to be more specific as to what the PCB manufacturer is unhappy about, but my *guess* is that you have created Gerber files *without* embedded aperture definitions, and you have not also provided an aperture list file (with these Gerber files). If you create Gerber files with embedded aperture definions, an aperture list file does not also have to be provided. It is preferable to actually do that, as the PCB manufacturer then doesn't have to manually load the aperture definitions into their photoplotter. From the CAM Manager file, invoke the Gerber Setup dialog box. Select the Apertures Tab, then check the Embedded apertures (RS274X) checkbox. The Gerber files subsequently produced should have embedded apertures, i.e. comply with the RS274X standard. (OTOH, if that box is not checked, the resulting Gerber files will not have embedded aperture definitions, and those files will then be to the RS274D standard instead.) Hope this helps. (Another possibility could be that the manufacturer is having problems with octagonal pads, but for the time being, I am guessing that aperture definitions are more likely to be the issue.) Regards, Geoff Harland. - E-Mail Disclaimer The Information in this e-mail is confidential and may be legally privileged. It is intended solely for the addressee. Access to this e-mail by anyone else is unauthorised. If you are not the intended recipient, any disclosure, copying, distribution or any action taken or omitted to be taken in reliance on it, is prohibited and may be unlawful. Any opinions or advice contained in this e-mail are confidential and not for public display. * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * 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] View PCB 3D
What is up with you lot in north America at the moment? Cabin Fever getting to you? Seems an awful lot of heat in this topic. Ian Wilson It's raining cats and dogs in N. California right now, so YEAH! :) Actually it would just be cool if the damn 3D thing was useable. Tony Karavidas I have vague recollections, in years past, of reading how Mendocino County (N California) was noted for the production of cannabis plants. Is it *really* raining cats and dogs there, or does it just *seem* that that is happening? :) However, I concur that if Altium are going to push the 3D viewer as part of Protel 99 SE, then it should be useable, and more than just a toy/demonstrator type feature. (The Recorder applet provided with Windows 3.x would have been more useful too, if it hadn't had so many shortcomings.) Perhaps there will be improvements in Phoenix; that said, I would also be interested in having some of the more irksome shortcomings of the PCB Server seen to (and a functional and usable Autorouting Server would be nice to have too). And Sydney has been pretty wet during the course of this week; ominous sounds of thunder, as I type this, suggest that we are not through that, as of yet. Regards, Geoff Harland. - E-Mail Disclaimer The Information in this e-mail is confidential and may be legally privileged. It is intended solely for the addressee. Access to this e-mail by anyone else is unauthorised. If you are not the intended recipient, any disclosure, copying, distribution or any action taken or omitted to be taken in reliance on it, is prohibited and may be unlawful. Any opinions or advice contained in this e-mail are confidential and not for public display. * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * 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] Phoenix beta testing (ex View PCB 3D)
snip Has anyone heard about the start of the Phoenix beta program? I've talked with them in the past and know I'm on the list, but it's now Feb and they were claiming a ship date of March I believe. That's not much time to test... Tony I strongly suspect that notifying someone that they have been accepted for membership of the beta testing program does not necessarily mean that they will be invited to beta test every new release of software. As such, it is not out of the question that beta testing of Phoenix actually is occurring at present, and we are not aware of that, due to whoever is participating being prohibited from publicly disclosing that (because of a NDA that testers have to agree to). And regardless of whether that is the case or not, Altium's announcement of publicly releasing Phoenix this quarter (i.e. before the end of March) should be taken with a grain of salt. If the release actually occurs later, it would hardly be the only example of a company not releasing a new version of software by the originally announced date. It is not unreasonable to assume that there is a prospect of Phoenix being released prior to it being thoroughly beta tested and debugged. As such, I wouldn't mind some delay in the public release, if the product ended up the better for it. (I don't know if there will be a public prerelease version before the final public version, but there would be a lot to be said for Altium actually doing that.) I guess it is a case of waiting to see what happens... Regards, Geoff Harland. - E-Mail Disclaimer The Information in this e-mail is confidential and may be legally privileged. It is intended solely for the addressee. Access to this e-mail by anyone else is unauthorised. If you are not the intended recipient, any disclosure, copying, distribution or any action taken or omitted to be taken in reliance on it, is prohibited and may be unlawful. Any opinions or advice contained in this e-mail are confidential and not for public display. * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * 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] YAAMR
G'Day all, Yet Another Altium Media Release http://www.protel.com.au/media/mr02_descapt.htm This time on VHDL stuff (integrated in the next release of Protel). This will no doubt get the PCB designers amongst us off and fuming...(as opposed to those that spend time doing other design stuff as well). Ian Wilson Given the philosophy of Protel come Altium, I am not surprised that Phoenix will contain more VHDL / Programmable Device support. That said, I'm not ecstatic about what this could well mean for the next versions of the PCB and Schematic servers: a less than methodical eradication of outstanding bugs and shortcomings. We are now almost halfway through Q1/2002; I wonder if Phoenix will still be released in that time. Even if Altium don't release the final public version in that time (assuming beta testing is currently occurring, though there is a question mark over that), the release of a beta/prerelease public version by then would still be of value to Altium, in that they would have released *something* by the indicated date, while giving users in general the chance to report outstanding aspects before the release of the final version. (Perhaps Altium could give users an incentive to provide feedback: in exchange for that, the otherwise 30 days available for evaluating the trial version of the final release (when that is made available) could be extended to some extent (depending upon the quality and quantity of feedback provided).) Regards, Geoff Harland. - E-Mail Disclaimer The Information in this e-mail is confidential and may be legally privileged. It is intended solely for the addressee. Access to this e-mail by anyone else is unauthorised. If you are not the intended recipient, any disclosure, copying, distribution or any action taken or omitted to be taken in reliance on it, is prohibited and may be unlawful. Any opinions or advice contained in this e-mail are confidential and not for public display. * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * 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] Beta testing (was Pulsonix vs Protel vs Protel Pheonix)
snip (2) If I *were* testing Phoenix beta, I'd be able to say that, unless I signed another NDA which prohibited it. If Protel informed me specifically that the fact of my testing was confidential, then it could be a violation of the NDA even as it stands, though it might be difficult to enforce because it could easily be argued, in defense, that the bare fact of my occupation in testing was not information, whether written or oral, exchanged between them..., which is what is covered by the NDA. But I would strongly advise PAltium to get Phoenix into Beta as soon as possible. The program could be quite buggy as long as it does not regularly reformat the hard drive ;-) The fact that Phoenix is in beta release will generate excitement in anticipation, and I'm sure that Altium is aware of that. So it should not be secret. So I conclude that it is not in Beta yet. Abdulrahman Lomax Altium might not subscribe to the same view. They could, conceivably, argue that publicising that beta testing is currently occurring (which the general public would infer in the event that a beta tester disclosed that) has the potential to compromise their commercial interests, in that their competitors would then be aware as to when beta testing is occurring (whereas they would not be aware of that if none of the beta testers disclosed that). Whether such an argument would stand up in a court of law is of course another matter (assuming that Altium did initiate legal action against a beta tester who publicly disclosed that). Even if the public at large are not aware of whether beta testing is currently occurring or not, many would still infer that this probably is occurring at present, on the basis that Altium has announced that Phoenix will be released before the end of Q1/2002. While I suggest that that release date should be taken with a grain of salt, that still doesn't alter the proposition that Altium might not want any of its competitors to discern when beta testing started, and/or how long has been assigned for that. I am not currently beta testing, so I am under no obligation to keep that fact to myself. It also follows that I don't know whether beta testing is currently occurring or not, so I don't conclude that this has definitely not started as of yet. Given that Altium will try and release the public version of Phoenix before the end of this quarter (as they have already publicised that release date), or failing that, as soon as possible after that deadline, I would hope that beta testing has in fact already started; the alternative scenario implies that the beta testing phase will be very short in duration, and with the programmers under considerable pressure (from other sections of Altium) to release the final version of this ASAP. In a previous post, I suggested that perhaps Altium could release a public beta version before the end of next month. That would give them some breathing space, while also permitting them to retain a large measure of credibility. And users at large would have the chance to find and report outstanding bugs (even if it was too late in the piece for suggested enhancements to be implemented, unless these were of a trivial nature to implement). Regards, Geoff Harland. - E-Mail Disclaimer The Information in this e-mail is confidential and may be legally privileged. It is intended solely for the addressee. Access to this e-mail by anyone else is unauthorised. If you are not the intended recipient, any disclosure, copying, distribution or any action taken or omitted to be taken in reliance on it, is prohibited and may be unlawful. Any opinions or advice contained in this e-mail are confidential and not for public display. * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * 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] Key assignments (was Pulsonix vs Protel vs Protel Pheonix)
although i am habituated to the PgUp PgDn keys for zoom i think they were VERY BAD default choices whenever the focus is not on the graphical screen but on maybe a list box, the PgUp PgDn keys act as they would in most programs and move up/down the list, this drives me crazy in lib edit when i haven't clicked the screen first and then hit PgDn, but i'm really in the list box and the graphical object jumps to some other one PgUp PgDn should drive the scroll bars on a graphical screen Dennis Saputelli If PgUp and PgDn were not used for Zoom In and Zoom Out, other keys would have to be assigned for these functions. Some applications I have seen use the '+' and '-' keys instead. If such keys were used with Protel though, ... , which keys would then be used to select the Next and Previous layers? I'm not adverse to hearing your thoughts on this matter. And on the topic of key assignments, my experience has been that certain keys, like the 'Home', 'End', 'PgUp', 'PgDn', '+', '-', and '*' keys, seem to be hardwired into Protel to some extent: if the default assignments for these keys are changed (in the list of Shortcut resources), those default assignments are *still* used if those keys are used while another command is currently being executed. (Are there any other keys displaying this behaviour?) That could be regarded as a bug; that said, it is not one that I have lost too much sleep over to date. Regards, Geoff Harland. - E-Mail Disclaimer The Information in this e-mail is confidential and may be legally privileged. It is intended solely for the addressee. Access to this e-mail by anyone else is unauthorised. If you are not the intended recipient, any disclosure, copying, distribution or any action taken or omitted to be taken in reliance on it, is prohibited and may be unlawful. Any opinions or advice contained in this e-mail are confidential and not for public display. * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * 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] Exporting ASCII
I know I can do it by placing the components on a pcb first but that is very cumbersome when you just want to save a whole library into ascii.. Peder K. Hellegaard I have been requesting the ability to save/export/link/import/open PCB Library files in ASCII format for some time now. I'm not assuming that this will necessarily be provided in Phoenix, but it is also not totally out of the question that it could be provided. It has occurred to me that someone using the SDK files could *probably* create an addon server in which a PCB Library file could be translated into an ASCII format file, and such a file translated back into a PCB Library file again. The translation procedures would probably prevent such files from being capable of being saved or opened *directly*, but such a server would still otherwise implement an ASCII format for PCB Library files. Given sufficient spare time, I could probably create such a server myself. But it would still be nice if Altium could implement this, and in a manner which permits such (ASCII format) files to be being saved or (re-)opened directly (with such files being recognised by Phoenix as PCB Library files, rather than merely text files). Regards, Geoff Harland. - E-Mail Disclaimer The Information in this e-mail is confidential and may be legally privileged. It is intended solely for the addressee. Access to this e-mail by anyone else is unauthorised. If you are not the intended recipient, any disclosure, copying, distribution or any action taken or omitted to be taken in reliance on it, is prohibited and may be unlawful. Any opinions or advice contained in this e-mail are confidential and not for public display. * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * 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] Update to Protel's Website
It looks as though Altium have updated, yet again, the Protel Website, sometime today. What is of interest is the advance notification provided of some of the features which will be available with Altium. The following text is an extract from the updated Protel Website (and was thus originally provided by Altium): PCB West Design Conference Altium will be exhibiting at the 11th annual PCB West Design Conference from March 19th to the 21st, 2002 in Santa Clara (for full details go to www.pcbwest.com). We would like to invite you to be our guest at the show and have 2000 show passes to give away. To register for your free pass simply submit your details in the form below and your pass will be mailed to you. Please note that this offer is only available within the USA. What's of interest for Protel users at the show At the Altium stand Every day at booth number 412 - Product preview of the new Protel release - Opportunity to try the new Protel product - Product preview of the new CAMtastic! release The Protel User Group meeting Wednesday, March 20th 2002 (7:30am to 9:30am) Room 203 Santa Clara Convention Center Hosted by our Protel Product Manager, Phil Loughhead and Applications Engineer, Rick Wilson The focus for the meeting will be on features in the new Protel release, including: - Enhanced design integration and management, with powerful design validation, comparison, and bi-directional synchronization features. - On-sheet schematic symbol editing, user definable component and pin parameters, and enhanced schematic printing with optional preview. - Comprehensive PCB dimensioning tools and enhanced padstack definition. - Situs, the new topological autorouter, with complete support for all electrical and routing design rules, BGA fanout support and cleaner routing. - Enhanced circuit simulation, with import and export of waveform data, enhanced plot graphics, overlaying of multiple waveforms and copy to clipboard support. - Integrated PCB signal integrity analysis, operating within the Design Explorer environment. - Plus a host of other features, including integrated component libraries, version control, design variants, true multi-channel design, the ability work with documents directly on the hard drive, user-friendly environment customization, the spreadsheet-like Object Explorer, and much more. We will also be previewing the new Design Explorer based CAMtastic!, with auto-loading of all file types, enhanced DRC checking, and import and export of ODB++ files. +++ The reference to Situs is not unexpected, but we have now been given advance notice of some other features which will be provided in Phoenix. Regards, Geoff Harland. - E-Mail Disclaimer The Information in this e-mail is confidential and may be legally privileged. It is intended solely for the addressee. Access to this e-mail by anyone else is unauthorised. If you are not the intended recipient, any disclosure, copying, distribution or any action taken or omitted to be taken in reliance on it, is prohibited and may be unlawful. Any opinions or advice contained in this e-mail are confidential and not for public display. * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * 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] Cpld question
This is a question I am posing on behalf of a workplace colleague. Does anyone have a working schematic capture example for the Xilinx- CPLD 9536VQ44 producing .jed file? (Either for Protel 99 SE or Protel 98.) Regards, Geoff Harland. - E-Mail Disclaimer The Information in this e-mail is confidential and may be legally privileged. It is intended solely for the addressee. Access to this e-mail by anyone else is unauthorised. If you are not the intended recipient, any disclosure, copying, distribution or any action taken or omitted to be taken in reliance on it, is prohibited and may be unlawful. Any opinions or advice contained in this e-mail are confidential and not for public display. * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * 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 does smt work ??
well, thats a pretty dumb question, isn't it? hahaha. but i'm serious. i'm trying to reproduce a board which has smt top and bottom, and it appears that some of the smt pads overlap from top to bottom. so how do smt pads work? on a thru-hole, they obviously go thru the entire board. how far does a pad go thru as an smt? obviously it has to at least burrow thru to any layer it runs on, but do top and bottom overlapping smt pads necessarily net together? i'm confused. let me state that i realize many complex things are possible (blind and buried vias come to my mind), but somehow i don't think this is the case with this board. but i'm not sure. thanks, miker In Protel, pads on the MultiLayer layer occupy all copper layers on the PCB. Assuming the (pad's) hole diameter is not zero, there are also (anti)pads on the internal power plane layers. (Those (anti)pads are always circular in shape, because the hole is circular in shape.) Pads on all other layers occupy that layer only (with the qualification that pads on the outside copper layers are imaged on the Solder Mask layer and Paste Mask layer on the same side of the PCB as the pad; pads on the MultiLayer layer are similarly imaged on both Solder Mask layers (but neither Paste Mask layer)). Pads have a padstack feature, but this is only relevant for pads on the MultiLayer layer; this feature permits the shape and dimensions of the pad to be customised for each of the (outside) top signal layer, the (outside) bottom signal layer, and the remaining (internal) signal layers. IMO, that feature should be disabled for pads on any other layer, as only one of those three sets of properties is relevant for such pads (with the other two sets of properties being of no practical significance). (Advance information is that the padstacks feature is going to be enhanced in Phoenix; I am hoping this won't be buggy in nature.) All pads can have an associated hole, but while it is not compulsory, it is still extremely advisable to set the hole diameter to zero for all pads which are not on one of the external copper layers or MultiLayer layer, and I personally would be reluctant to have holes in pads even on either of the external signal layers. All pads also have a Plated property; IME, it is advisable to always set this True unless the pad is on the MultiLayer layer and you *don't* want this through plated. (Again, this property should always be disabled if the associated pad has a zero diameter hole.) It's almost certainly too late in the piece for incorporation in Phoenix, but my opinion (which I have distilled over time) is that all Pad objects should exist solely on the MultiLayer layer, and be of either a Top Surface Mount type, or a Bottom Surface Mount type, or a Through Hole type; regardless of which of these types each pad is, it occupies more than one layer, to wit one Solder Mask layer and one Paste Mask layer for SM pads, and two Solder Mask layers for ThroughHole pads (though there would be merit in also being able to image such pads on each of the Paste Mask layers as well). In lieu of Pad objects on other layers, there should be enhanced Fill objects on other layers; these enhanced Fill objects would be like existing Fills in that they would never be imaged on any other layers, and with the enhancement being that a Fill could either have a Rectangular, Obround, or Octagonal shape (rather than just a Rectangular shape as at present). The (new) dialog box for Fill objects would permit one of these shapes to be selected, and the user would also have the option of being able to specify the region occupied by the Fill either by the use of Low and High X and Y co-ordinates (i.e. like existing Fills), or alternatively by co-ordinates for the centre, and Width and Height properties (i.e. like existing Pads). (Both sets of properties would be displayed, but two radio buttons would also be provided to select which set of properties is *just* displayed and which set of properties is not just displayed, but also editable. Alternatively, just one set of properties is displayed at a given time, and these are editable, but selecting the other radio button would then change the set of properties displayed.) It goes without saying that such SM pads should not be displayed unless they exist on a layer which is currently selected for displaying. (At present, there is a bug in that blind or buried vias are displayed even when these do *not* exist on layers which are currently displayed.) (I have previously stated that I believe that Vias should remain a distinct type of object from Pads, because otherwise it would not be possible to create Pad Master type printouts or Gerber files. That said, there is still a case for enhancing the ability to control Vias' properties, so that (as at least one example) designers can select masking of vias on one side of the PCB, but not on the other side.) Regards, Geoff Harland. - E
Re: [PEDA] PCB view from bottom of board??
Is there any way within Protel 99SE's PCB tool to cause the view to be from the bottom of the board rather than from the front? Ray Mitchell Yes (sort of) http://www.considered.com.au/Protel01.htm#CSFlipViewer Geoff Harland and I were working on a more difficult server to completely flip the database around an axis. We struck multiple problems including different flip methods required for different objects due to inconsistencies in the SDK, the undo stack not seeming to log everything correctly and problems with extracting the layer pairs and some other stuff. Some of these are presumably solvable with enough knowledge about the bugs in the SDK and some seem to be completely undocumented or unimplemented aspects of the SDK. This development is pretty much on hold - a beta version was released but that was withdrawn. The above server will allow some a sort of bottom view. Ian Wilson There is another possibility, but due care needs to be exercised if using it. That possibility is to select *everything* in the PCB file, and then mirror this about a vertical axis or horizontal axis. Since the release of SP6 (for Protel 99 SE), you will be presented with a warning box if the items about to be mirrored include components, because producing Gerber files from mirrored components will result in PCBs that can't have real world components installed on them. As such, if you do go for this option, you will then need to re-mirror everything again (and before producing Gerber files). (And when you do re-mirror everything again, the same warning box will be re-invoked; Protel is not conscious of whether components are currently in a mirrored state or not, because (unlike String objects) Component objects do *not* (currently) incorporate a Mirrored field (something which I am hoping will be rectified in Phoenix though).) If you add any new components to the PCB file while this is in a mirrored state, you should then mirror such components as well (to match the currently mirrored state of previously placed components, while keeping in mind that the second mirroring of the PCB file will *toggle* the (non-Protel-registered) mirrored status of *all* components within the PCB file at that time). That consideration is one example of why you need to be careful if you run with this procedure. Other aspects of going with this procedure is that Coordinate and Dimension objects do *not* mirror properly (and that indeed is also a problematic aspect with the alternative concept of inverting PCBs). However, as a PCB file has to be re-mirrored again at a later stage (to restore all components to an un-mirrored state), the associated problems are of a temporary nature (but re-check the locations and properties of any Coordinate objects following the second mirroring). Because it does not have all of the features of Protel 99 SE, I believe that I could *probably* implement an inverting server for use with Protel 98. While I have written *most* of the associated code, I would still need to do a bit more work before I could release this (and I would probably only do so if anyone expressed an interest in having this provided). *Maybe* an inverting server could be provided (in due course) for use with Phoenix, if the SDK files (and associated documentation) provided for that prove to be up to par, but in the absence of appropriate assistance from Altium, I do not envisage that Ian Wilson and I could complete the inverting server that we started on for use with Protel 99 SE. If anyone is interested, it is my belief that an off-line inverting utility could be created for use with Protel 99 SE, as long as the PCB file to be inverted was saved in ASCII format. This would be off-line in the sense that the PCB file would need to be saved/exported (in ASCII format), the contents of the file then manipulated by the utility, and the thus-modified file then re-imported/re-opened again. (Ian and I had been working on a more ambitious plan to implement an on-line inverter, in which the PCB file would be inverted while this was currently open. With hindsight, we weren't originally aware that the SDK files and associated documentation were not up to par for implementing this particular task.) It should be noted that when a PCB file is inverted, all components in the PCB file remain in an *un-mirrored* state, and you could, if you so wanted, produce kosher (/halal/etc) Gerber files from a PCB file that is currently inverted (or at least from a PCB file that has been deeply inverted, rather than just standardly inverted). Inverting a PCB is a *different* procedure to mirroring this (though one aspect they do have in common is selecting the location of a mirroring/inverting axis, and whether this (axis) is vertical or horizontal). Conceptually, you can manually invert a PCB file, but that would normally be time-consuming, as a number of steps would be required, and there would be many ways you could put a foot wrong while
Re: [PEDA] PCB view from bottom of board??
, such as Layer Stackup definitions, (Drill) Layer Pairs, and Design Rules, also need to have their associated properties appropriately updated as well. The server that Ian Wilson and I had been working on was designed to invert an *entire* PCB file. But there would be complications to deal with if any attempt was made to also/alternatively provide a feature of inverting *just* those items currently in a selected state. The Layer Stackup definitions and/or (Drill) Layer Pairs could be asymmetric in nature in some PCB files, and that would have a bearing upon what updated properties should be assigned to vias of a blind or buried nature, and to other (primitive type) objects residing on internal copper layers. (Those issues are less problematic (on a philosophical level, if not on a coding level) when an *entire* PCB is being inverted instead, because *all* of the objects in the PCB are then being inverted, rather than just *some* of these.) And then there are also Design Rules to consider (in such circumstances); some of these could be applicable to components and/or other objects currently in a selected state, ... Bottom line: if Altium have visions of providing an inverting feature in Phoenix, then this should be provided in a form which inverts the *entire* PCB; there should not be an additional option (or alternative implementation) of inverting *just* selected items. It is debatable as to what *should* happen when the L key is pressed, but attempting to implement an inversion of objects which are currently in a selected state (and *just* those objects) does have the potential to produce nasty results. Does anyone else have any thoughts on this matter? Regards, Geoff Harland. - E-Mail Disclaimer The Information in this e-mail is confidential and may be legally privileged. It is intended solely for the addressee. Access to this e-mail by anyone else is unauthorised. If you are not the intended recipient, any disclosure, copying, distribution or any action taken or omitted to be taken in reliance on it, is prohibited and may be unlawful. Any opinions or advice contained in this e-mail are confidential and not for public display. * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * 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 and Accel (ex Polygons that become unselectable, undeletable)
snip And please Altium DO NOT MAKE Protel look and feel like Accel. If I wanted Accel I wouldnt have returned it for a full refund several years ago. Mike Reagan I have heard suggestions to the effect that, in one aspect, the opposite will be happening: PCAD users will have to get used to a Client/Server type interface (as used with Protel) when the next version of that is released. But even if they don't totally merge, I am still picking an an increasing convergence of Protel and PACD though. That said, there are still many aspects of Protel that I would not like to lose either. Regards, Geoff Harland. - E-Mail Disclaimer The Information in this e-mail is confidential and may be legally privileged. It is intended solely for the addressee. Access to this e-mail by anyone else is unauthorised. If you are not the intended recipient, any disclosure, copying, distribution or any action taken or omitted to be taken in reliance on it, is prohibited and may be unlawful. Any opinions or advice contained in this e-mail are confidential and not for public display. * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * 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] Paired Mechanical layers (ex Inversion ...)
Even if it has been talked about I would add that this is very much needed in capability. However or if ever Altium decides to implement something like this. But as the software stands now it is very clunky with respect to package info on a mechanical layer with respect to two sided assemblies. Too much effort from what I see to deal with this appropriately other than making a top and bottom footprints, which really takes us backwards a few years in the way of doing things. Robert M. Wolfe I have also suggested the concept of being able to pair Mechanical layers to one another from time to time in the past, so it is not totally out of the question that such a feature could be provided in Phoenix (given that this is not a suggestion that has first reared its head in the past few days). In a previous job I used a DOS version of P-CAD (specifically version AD2.0), and that provided the feature of being able to define new layers as desired, and to also pair layers to one another as desired. In its contemporary manifestation, to wit P-CAD 2001, the ability to define new layers as desired is still there, ... but the ability to pair layers to one another is not currently provided (with only five pairs of layers being available, to wit, the pre-defined Assembly, Overlay, Paste Mask, Solder Mask, and external copper layers). However, I would not dismiss the possibility that that aspect of previous versions of PCAD could be restored (to future versions of P-CAD) at some stage... Another possibility (in Protel/Phoenix), rather than providing the ability to pair the *existing* Mechanical layers as required, would be to provide still more non-copper layers that are of a hard-wired paired nature. For example, Top Aux 1, Bottom Aux 1, Top Aux 2, ... , Bottom Aux 4 (8 new layers), or Top Aux 1, ... , Bottom Aux 8 (16 new layers); perhaps users could also have the ability to rename these layers as desired, e.g. Top Aux 1 and Bottom Aux 1 could be renamed, by the user, as Top Assembly and Bottom Assembly. And yet another possibility would be for Protel/Phoenix to implement an aspect of Autocad and PCAD, and provide the user with an ability to define new layers as desired, with each layer being of either a Signal, Power Plane, or mechanical/non-copper type; such layers should also be pairable to one another as desired (or at least for layers of a non-copper nature). (Certain layers, to wit the Overlay, Paste Mask, Solder Mask, external copper, MultiLayer, Keep Out, Drill Draw, and Drill Guide layers, would be pre-defined, but all other layers would be defined by the user as required.) To some extent, that would be a break from the Protel Way (as implemented to date), but it still need not be totally incompatible with that... (The predefined layers could be numbered as layers 1 to 12 in the Protel database format, and with user-defined layers starting from layer 13; one of the fields of each Layer object could be a variable that identifies the type of the layer (Signal, Power Plane, or Mechanical), with another field identifying the number of the other layer that the layer is paired to (with that number being set to zero (the null layer) if the layer is not paired), and yet another field containing the name assigned to the layer by the user, etc.) As I mentioned in another relatively recent post, apparently Phoenix will at least be providing an enhanced padstacks feature; one aspect could be providing the ability to define *different* solder mask expansion values for *each* side of the PCB (for Through Hole vias and MultiLayer pads), though I suspect that there will be more to it than just that. So fingers crossed that many of the current bugs and shortcomings of the PCB Server will also be seen to in Phoenix... Regards, Geoff Harland. - E-Mail Disclaimer The Information in this e-mail is confidential and may be legally privileged. It is intended solely for the addressee. Access to this e-mail by anyone else is unauthorised. If you are not the intended recipient, any disclosure, copying, distribution or any action taken or omitted to be taken in reliance on it, is prohibited and may be unlawful. Any opinions or advice contained in this e-mail are confidential and not for public display. * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * 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] Using L key while moving selected items (Long, and advanced material)
snip Bottom line: if Altium have visions of providing an inverting feature in Phoenix, then this should be provided in a form which inverts the *entire* PCB; there should not be an additional option (or alternative implementation) of inverting *just* selected items. It is debatable as to what *should* happen when the L key is pressed, but attempting to implement an inversion of objects which are currently in a selected state (and *just* those objects) does have the potential to produce nasty results. Does anyone else have any thoughts on this matter? Geoff Harland To date, nobody else has commented on what *should* happen if the L key is pressed in the middle of a command to move currently selected objects. Perhaps this is because most users know that this is inadvisable, and/or because some users use the L key just to move components from one side of the PCB to the other (and just one at a time). However, perhaps there is something to be said for an outcome in which some (and just some) aspects of inversion occur. To the extent that a PCB could still be scrambled, to some extent, by the use of this, the onus would be on the user to exercise due care, but it would still be preferable for the outcome to be of a more logical, and less scrambled, nature, than the status quo. Before I go further with what I am suggesting what should happen, a bit of background on Inversion: Ian Wilson and I envisaged that Inversion of a PCB could either be of a Standard nature or of a Deep nature. With the former option, objects on internal copper layers would remain on the *same* layer as previously, but the *sequence* of copper layers would be changed so that the internal layer previously closest to the top side would end up closest to the bottom side, and vice versa, and similarly for the remaining internal layers. We envisaged that Standard Inversion would be of a *temporary* nature, hence the retention of the *same* Layer property for all objects on *all* *internal* layers. OTOH, the use of Deep Inversion was envisaged when the inversion was to be of a *permanent* nature. As such, objects on internal copper layers typically would be re-assigned to a *different* (internal) layer, so that the sequence of layers within the inverted PCB would continue to be logical in nature. For a PCB with a fully symmetrical sequence of layers, the layer sequence would not change at all, but otherwise the layer sequence would change to at least some extent (and as required). Examples of layer sequences for Standard and Deep inversion, to illustrate: Original sequence: Top, Mid 1, Power Plane 1, Mid 2, Power Plane 2, Bottom Updated sequence with Standard Inversion: Top, Power Plane 2, Mid 2, Power Plane 1, Mid 1, Bottom (Former Top side items to Bottom, and vice versa.) Updated sequence with Deep Inversion: Top, Power Plane 1, Mid 1, Power Plane 2, Mid 2, Bottom (Former Top side items to Bottom, and vice versa.) (Former Power Plane 2 items to Power Plane 1, and vice versa; former Mid 1 items to Mid 2, and vice versa.) (That original sequence is not very likely (as it would be far more likely for the Power Plane layers to be adjacent to one another), but it still illustrates differences between the two Inversion options.) Original sequence: Top, Mid 1, Power Plane 1, Power Plane 2, Mid 2, Bottom Updated sequence with Standard Inversion: Top, Mid 2, Power Plane 2, Power Plane 1, Mid 1, Bottom (Former Top side items to Bottom, and vice versa.) Updated sequence with Deep Inversion: Top, Mid 1, Power Plane 1, Power Plane 2, Mid 2, Bottom (Former Top side items to Bottom, and vice versa.) (Former Power Plane 2 items to Power Plane 1, and vice versa; former Mid 1 items to Mid 2, and vice versa.) (A more likely scenario.) Original sequence: Top, Power Plane 1, Mid 1, Mid 2, Mid 3, Bottom Updated sequence with Standard Inversion: Top, Mid 3, Mid 2, Mid 1, Power Plane 1, Bottom (Former Top side items to Bottom, and vice versa.) Updated sequence with Deep Inversion: Top, Mid 1, Mid 2, Mid 3, Power Plane 1, Bottom (Former Top side items to Bottom, and vice versa.) (Former Mid 1 items to Mid 3, and vice versa.) (Another sometimes plausible scenario, which also illustrates differences between each type of Inversion.) Back to using the L key, which could be used to invert, in a fashion, *just* currently selected items. What I envisage with the use of the L key (while moving selected items) is that *all* selected items *appear* to be mirrored (compared with before), though in the case of (selected) *components*, each component is *really* moved to the opposite side of the PCB (from where it was previously), so is *not* really mirrored as such; OTOH, all String objects (for instance) have their Mirrored status toggled, and regardless of whether each of these is on a layer of a paired nature or otherwise. (***PROPOSITION #1***) Because it is *not* an inversion of the *entire* PCB file though, Design Rules, Layer Stackup
Re: [PEDA] Paired Mechanical layers (ex Inversion ...)
Geoff, Does your suggested pairing mechanism only come into play for components which are placed on the back of the board or is it to be used elsewhere as well? Douglas McDonald The pairing feature would primarily be provided for use with objects (arcs, fills, pads, strings, or tracks) that are part of some component (so that the Layer property of such objects automatically changes in an appropriate manner when their parent component changes which side of the PCB it is on), but would *also* be applicable (to some extent) to free objects (those which are *not* part of some component). While the use of the L key (while moving selected items or single components or other objects) is arguably currently broken to some extent, any free object should still *also* change which layer it is on, if it is on a Mechanical layer that has been (user-)paired to another Mechanical layer, and the L key is pressed while it is being moved (either by itself or as one of a number of objects that are currently in a selected state). In that regard, the paired Mechanical layers would behave like the existing layers of a paired nature, to wit the Overlay, Paste Mask, Solder Mask, and external signal (copper) layers. Both free objects and non-free objects on such layers would also change layers in the event that the *entire* PCB file was inverted, and regardless of whether the inversion was of a Standard or Deep nature, and regardless of whether the inversion was provided with Protel or implemented by an user-provided addon server. I also envisage that users could pair Mechanical layers on an as-needed basis, so that up to eight pairs of paired Mechanical layers would be available for those needing that many, while others would alternatively be able to pair a smaller number of Mechanical layers, or even none at all. The implementation could be simplified to some extent (with no loss in the ability to control how many pairs of Mechanical layers are provided) by restricting the pairing feature to adjacent Mech layers. As such, Mech 1 could be paired with Mech 2, but no other layer; similarly, Mech 3 could be paired with Mech 4, but no other layer; ... ; Mech 15 could be paired with Mech 16, but no other layer. And for each such pair of adjacent Mech layers, the user could select whether those two layers actually are paired to one another or not. One way of implementing the associated user interface would be for the Setup Mechanical Layers dialog box to incorporate another eight Checkboxes (perhaps on a second Tab with a title of 'Pairing', but otherwise on the existing 'Properties' Tab). One of those (new) Checkboxes would select (and display) whether Mech 1 and Mech 2 are paired to one another or not, etc. Conceptually, Mechanical layers could *presently* be paired to one another, if an user-provided addon server was implemented which incorporated a Process for controlling (and displaying) which layers are paired to one another (details of which layers are thus paired could be retained, and within the PCB file itself, by the use of Embedded objects, a feature provided by Protel for use by developers), and one or more Processes for updating the layer properties of objects on such layers as required. A relatively recent post to this forum suggests that someone else actually has done this (or at least some of those aspects). *However*, if a component is moved to the opposite side of the PCB while using the L key (or invoking a 'Component' dialog box and then changing the 'Layer' property within that), any objects within the component that are on Mech layers of a user-paired nature will *not* have their Layer property appropriately updated at the time (unless the addon server was clever enough to be able to monitor that situation, and then arrange those properties to also be updated as required, but that would be no small task to implement, assuming it could even be done at all). And *that* is the reason why it would be desirable for this feature to be built into Protel itself. In more recent times, I suggested a couple of alternative options, such as providing eight (or sixteen) entirely new layers which would provide four (or eight) new hard-wired pairs of layers (for use *both* with components *and* otherwise, as desired by each user), or else providing the user with the ability to define new layers as desired (similar to Autocad and PCAD), together with the ability to pair these to one another as desired (similar to past versions of PCAD (and past/present versions of Autocad?)). In any event, I strongly suspect that the existing four pairs of paired layers is a source of frustration for at least some users, who would want to have more such layers available for their use. Regards, Geoff Harland. - E-Mail Disclaimer The Information in this e-mail is confidential and may be legally privileged. It is intended solely for the addressee. Access to this e-mail by anyone else is unauthorised
Re: [PEDA] Paired Mechanical layers (ex Inversion ...)
from Protel, so perhaps it could be argued that it is more appropriate for Protel to continue to be targeted to those wanting to acquire a more focused (on PCB design) product that does not cost as much. However, as I have suggested, even when Protel is used for PCB design, rather than as a general-purpose CAD application, there is still some case for providing the ability to have more than the existing four pairs of paired layers. And while changing to the Autocad/PCAD way (of defining new layers as required) would be one way of doing that, there are alternatively the other suggestions of mine, to wit, either providing yet another four (or eight) pairs of entirely new layers (which are hard-wired in their paired nature), or the longer-standing suggestion of being able to pair (the existing) Mech layers as required. Regards, Geoff Harland. - E-Mail Disclaimer The Information in this e-mail is confidential and may be legally privileged. It is intended solely for the addressee. Access to this e-mail by anyone else is unauthorised. If you are not the intended recipient, any disclosure, copying, distribution or any action taken or omitted to be taken in reliance on it, is prohibited and may be unlawful. Any opinions or advice contained in this e-mail are confidential and not for public display. * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * 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] Paired Mechanical layers (ex Inversion ...)
wouldn't you want pairing to be mech 1 with 16 and mech 2 with 15, etc. ? I would name say 8 layers as Top Mech 1-4 and bottom Mech 1-4 to keep the same naming style as for the current top/bottom layer pairs. This would leave 8 mech layers not paired. That way it would force some standard to which layers are used for what. Just my 0.02, Darren Moore IMO, your suggestion is not devoid of merit. However, many users would probably not want as many as four pairs of paired Mech layers (and at least some could well want *none* of the Mech layers to be paired to one another). As such, unless the pairing of each of these layers could be disabled by the user, that would reduce the utility of those layers to such users. In the form I originally suggested, users would be able to select whether they had 8 sets of paired Mech layers and no unpaired Mech layers, or 7 sets of paired Mech layers and 2 unpaired Mech layers, or 6 sets of paired Mech layers and 4 unpaired Mech layers, ... , or 1 set of paired Mech layers and 14 unpaired Mech layers, or no sets of paired Mech layers and 16 unpaired Mech layers. Perhaps it is unlikely that anyone would want more than four sets of paired Mech layers, so the default names of the Mech layers could perhaps be changed along the lines you suggest. But I still submit that there is something to be said for being able to select which of those pairs of Mech layers actually do have the pairing feature enabled. And to avoid potential complications of whether particular Mech layers are paired to one another or not (i.e. whether the pairing feature is activated or not), was the reason behind my more recent suggestion of providing yet more additional layers, in which the pairing feature is of a permanent/hard-wired nature. These could have default names of Top Mech 1-4 (or 1-8) and Bottom Mech 1-4 (or 1-8), or Top Aux 1-4/8 and Bottom Aux 1-4/8, though presumably the user could rename these as desired (as with existing Mech and internal copper layers). The provision of yet more layers could be regarded as overkill by some, but then again, how many users use *all* of the *existing* layers (other than perhaps to fully test out Protel 99 SE)? OTOH, this suggestion has been made in relatively recent times, so perhaps it is too late to incorporate in Phoenix. OTGH (on the gripping hand (from three-armed motie aliens in two SF novels written by Niven Pournelle)), perhaps this is something that has already occurred to Altium, who could well have anticipated that there could be problems associated with providing a selective enabling of the pairing feature with the existing Mech layers. (We will find out in the not too distant future what Phoenix will be providing in this regard.) Regards, Geoff Harland. - E-Mail Disclaimer The Information in this e-mail is confidential and may be legally privileged. It is intended solely for the addressee. Access to this e-mail by anyone else is unauthorised. If you are not the intended recipient, any disclosure, copying, distribution or any action taken or omitted to be taken in reliance on it, is prohibited and may be unlawful. Any opinions or advice contained in this e-mail are confidential and not for public display. * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * 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] Flipped on panel Paired Mechanical layers (ex Inversion ...)
Ian Wilson wrote: real reasons why correct inversion would be useful, another would be to facilitate panelisation where alternate rows of boards are flipped - to minimise machine setup. Leaving this to a PCB maker can be a source of error. Doing it in Camtastic is my preferred option but some companies I work for like to have the panel in Protel for whatever reason. i've seen those panels with some boards flipped and never understood, in fact i still don't can you pls explain what this offers? Dennis Saputelli That was covered in late 2000 (on this forum). A panel of PCBs in which every second unit PCB is inverted permits a print and turn type of manufacture, in which the *same* filmwork and (Solder Paste) stencil can be used for *both* sides of the panellised PCB, thus saving, to some extent, on PCB setup costs. There are some requirements to comply with. The panel must contain an even number of unit PCBs, and the sequence of copper layers (within the unit PCB) must be symmetrical in nature. When producing a panellised PCB with Protel, extra care would customarily be required when the unit PCBs use Power Plane layers. But in some situations, some savings in costs can still be achieved. Regards, Geoff Harland. - E-Mail Disclaimer The Information in this e-mail is confidential and may be legally privileged. It is intended solely for the addressee. Access to this e-mail by anyone else is unauthorised. If you are not the intended recipient, any disclosure, copying, distribution or any action taken or omitted to be taken in reliance on it, is prohibited and may be unlawful. Any opinions or advice contained in this e-mail are confidential and not for public display. * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * 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] Paired Mechanical layers (ex Inversion ...)
snip In fact, I have a job at the moment where it would be a really useful tool. There are two boards that plug together component side to component side. If such a tool existed, I could place components on both sides of a single outline so that I could check for interferences as I go. I could also put the connectors on top of each other so that I know they will match up. Once I am happy, I could select everything on the bottom layer and flip them with a copy of the outline. Now I have two boards as they will be manufactured on a panel, with the components on the top, no transposition errors and I still have the ability to keep in sync with the schematic. Steve Baldwin You can flip x or y now and it flips correctly so why does anyone what to flip so it contrary to design standards? I dint get your point, but I have seen boards backwards when these standards were ignored. The problem is that mech engineers and designer dont know how to view a board. Mike Reagan It is currently possible to *mirror* a PCB file (using the X or Y key), but due care is required when doing so, because of the potential to produce a PCB which contains mirrored footprints (which can't have real world components fitted to them). OTOH, an inverted PCB file contains components which are *still* in an *unmirrored* state (but on the opposite side of the PCB to previously). Inverting a PCB is thus inherently safer than mirroring it, because it is not necessary (nor sensible) to mirror components that are (newly) added to an inverted PCB, whereas that *is* necessary in the case of a mirrored PCB (because not mirroring them at that time will result in them being in a mirrored state after the entire PCB file is subsequently re-mirrored/un-mirrored). An inverted PCB should be inverted a second time (to restore it to its previous state) in order to comply with IPC standards, *but*, if that is *not* done, the PCB will nevertheless *still* be capable of being assembled, because none of its footprints will be in a mirrored state. However, using the alternative (and currently available) option of mirroring a PCB file does result in an increased risk of the manufactured PCBs incorporating mirrored footprints, due to the potential for the PCB designer to forget to (or overlook the need to) re-mirror/un-mirror the PCB file, or to *not* mirror components which are added to the PCB file while this is in a mirrored state. And apart from that, as others have already said, there can be occasions when it is desirable to invert an entire PCB, or else parts of this, when re-using such work in another new job. I don't know if the concept of inverting a PCB has previously occurred to Altium, but to some extent it is not surprising that such a feature has not been provided to date. As I have said on previous occasions, the provision of this feature could open large cans of worms, as there are issues to consider concerning what aspects of a PCB should be inverted. That is not just an issue when an *entire* PCB file is inverted (as there are differences between Standard Inversion and Deep Inversion), but also when just *some* of a PCB file (such as those objects that are currently selected) is inverted. I, and others, have pointed out why the provision of an inverting feature could be beneficial. But even if the feature of on-line inversion of an *entire* PCB file is not provided in Phoenix (off-line inversion is possible for users to implement (conditional upon ASCII versions of PCB files containing *all* of the data associated with the PCB file), and on-line inversion would also be possible for users to implement *if* the SDK files and associated documentation were up to par (something which is not currently the case with Protel 99 SE)), there is still a good case for at least improving the outcome of using the L key while moving either single objects or currently selected objects. (I have already requested others to comment on what should happen in those circumstances.) At present, the outcome of using that key is typically decidedly unsatisfactory... Regards, Geoff Harland. - E-Mail Disclaimer The Information in this e-mail is confidential and may be legally privileged. It is intended solely for the addressee. Access to this e-mail by anyone else is unauthorised. If you are not the intended recipient, any disclosure, copying, distribution or any action taken or omitted to be taken in reliance on it, is prohibited and may be unlawful. Any opinions or advice contained in this e-mail are confidential and not for public display. * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * 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
Re: [PEDA] Paired Mechanical layers (ex Inversion ...)
, such as those used to document the PCB and/or identify the remaining layers, typically would need followup action.) In the event that inverting procedures were provided (either by Altium or by users), nobody would have to use them. However, in spite of the associated complications that have just been discussed, I am picking that many users would still welcome their provision. And as should have been made clear by now, inverting a PCB is inherently safer than mirroring this, because components then swap sides rather than having their (currently unregistered) mirrored state toggled. (So any PCBs which are manufactured would be more likely to be assemblable, because there would be less likelihood of these incorporating mirrored footprints.) Regards, Geoff Harland. - E-Mail Disclaimer The Information in this e-mail is confidential and may be legally privileged. It is intended solely for the addressee. Access to this e-mail by anyone else is unauthorised. If you are not the intended recipient, any disclosure, copying, distribution or any action taken or omitted to be taken in reliance on it, is prohibited and may be unlawful. Any opinions or advice contained in this e-mail are confidential and not for public display. * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * 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] Paired Mechanical layers (ex Inversion ...)
Sure but doing this removes components unique identifier and the ability to do DRC against the schematic. For particular types of boards basically large numbers of repeating sections ( 'widebus' logic test boards) using connectors mounted from the bottom side and a number of sites, its basically a mix of Protel generated arrays (with ' _1' type of renumbering from PCB) and copy/pasted sections with user defined renumbering (added suffix) Then this gets tied back in with schematic designators and becomes basically a mess. PCB builds and renumbers arrays by adding a suffix ie_1, _2, _3 SCH builds and renumbers arrays by incrementing the final number ie R1 - R2 Copy and pasting renumbered arrays in PCB gives you bizarre results like R1_1_1 which is hard to tie back to the schematic to maintain DRC ability. It really doesnt seem like a hard thing to get right. Clive Broome OK, I previously misunderstood what you were trying to achieve (but it does represent a change in topic from inverting PCBs or providing the ability to have more layers of a paired nature than the existing four pairs). I have an idea that someone has released an addon server which supports pasting components with designators to match user-designated specifications. But apart from that, it would be nice if Altium could improve upon what is currently provided on a built in nature in this regard. (A Paste Array command that not only satisfactorily designated (free) *pads* for two dimensional arrays, but also designated pasted components according to the 'Text Increment' setting (or still better, an additional and newly provided 'Designator Increment' setting) within the 'Setup Paste Array' dialog box, would be a start.) Regards, Geoff Harland. - E-Mail Disclaimer The Information in this e-mail is confidential and may be legally privileged. It is intended solely for the addressee. Access to this e-mail by anyone else is unauthorised. If you are not the intended recipient, any disclosure, copying, distribution or any action taken or omitted to be taken in reliance on it, is prohibited and may be unlawful. Any opinions or advice contained in this e-mail are confidential and not for public display. * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * 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 SPs (ex PCB library part)
snip P99SE Sp6, Sp5, Sp4, Sp3, Sp2, Sp1, P99, P98 Sp4, Sp3, Sp2, Sp1... You get the Idea. Brian Guralnick P98 Sp4? My impression had been that only *three* SPs had ever been released for use with P98. Regards, Geoff Harland. - E-Mail Disclaimer The Information in this e-mail is confidential and may be legally privileged. It is intended solely for the addressee. Access to this e-mail by anyone else is unauthorised. If you are not the intended recipient, any disclosure, copying, distribution or any action taken or omitted to be taken in reliance on it, is prohibited and may be unlawful. Any opinions or advice contained in this e-mail are confidential and not for public display. * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * 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 big gripe
I hope Protel fixes this in future releases. I hate it when I open up a DDB file just to look at something, and it changes the file date. IT SHOULD NOT DO THAT! I use file dates to know when I last worked with that project, and this SCREWS UP that knowledge. Ivan Baggett I take it you are aware that it is possible to set the DDB file's read only attribute, then open this for viewing, then clear that attribute afterwards. (Prior to SP?, it was not possible to open a DDB file whose read only attribute was set, so things *have* changed in that regard.) That said, it is still a big pain to have to go through these procedures just to view a file. Advance publicity suggests that Phoenix will be offering three forms of saving files. Perhaps two of these will be the existing options (Windows and database), with time telling what the other form will be like. But it would be nice if all of the options permitted files to be viewed without their file dates changing (and without having to set and clear the read only attribute). Regards, Geoff Harland. - E-Mail Disclaimer The Information in this e-mail is confidential and may be legally privileged. It is intended solely for the addressee. Access to this e-mail by anyone else is unauthorised. If you are not the intended recipient, any disclosure, copying, distribution or any action taken or omitted to be taken in reliance on it, is prohibited and may be unlawful. Any opinions or advice contained in this e-mail are confidential and not for public display. * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * 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] Toggle Selection State of All
Perhaps it's because I have the PCBAddOn server installed (Yahoo Protel Users file area), but it works fine for me. Thomas I tried that it didn't work. This isn't one of the times where Protel has an undocumented parameter. Mark... I recently checked the Yahoo Protel Users file area myself, and I didn't see any evidence of any of the addon servers provided there providing a Toggle All process. (My PcbAddon Server does not (currently) provide such a process.) For all that, I also can't help thinking that someone has, at some time, implemented an process (within an addon server) which does this. It might have been created for use with Protel 98 though, in which case it probably won't also work with Protel 99 SE (or at least not unless the source code is re-compiled). Could the creater of that process please advise of the situation. (I would be prepared to re-compile source code, if so requested, in the event that this was originally created for use with Protel 98.) Regards, Geoff Harland. - E-Mail Disclaimer The Information in this e-mail is confidential and may be legally privileged. It is intended solely for the addressee. Access to this e-mail by anyone else is unauthorised. If you are not the intended recipient, any disclosure, copying, distribution or any action taken or omitted to be taken in reliance on it, is prohibited and may be unlawful. Any opinions or advice contained in this e-mail are confidential and not for public display. * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * 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] Toggle Selection State of All
I recently checked the Yahoo Protel Users file area myself, and I didn't see any evidence of any of the addon servers provided there providing a Toggle All process. (My PcbAddon Server does not (currently) provide such a process.) For all that, I also can't help thinking that someone has, at some time, implemented an process (within an addon server) which does this. It might have been created for use with Protel 98 though, in which case it probably won't also work with Protel 99 SE (or at least not unless the source code is re-compiled). Could the creater of that process please advise of the situation. (I would be prepared to re-compile source code, if so requested, in the event that this was originally created for use with Protel 98.) Geoff Harland. Duh! If I had looked under Yahoo Protel Users Bookmarks section (when I previously visited that Website), I would have seen that Ian Wilson has provided an URL to the Protel page of his Website, from which both some freeware and some shareware servers (for Protel 99 SE) can be downloaded from. URL for that Website page: http://www.considered.com.au/Protel01.htm And one of the freeware servers provided by Ian does exactly what you are looking for; (direct) URL as follows: http://www.considered.com.au/ProtelFiles/ToggleSelectionAllV2.zip Process description: 'Toggles Selection of tracks, pads, vias, components, fills, text, arcs, dimensions and coordinates' Suggestion for Ian: enhance this so that it also toggles the selected state of polygons and rooms (and nets?). (I have recently verified that not only can polygons be selected and deselected, but also rooms.) Regards, Geoff Harland. - E-Mail Disclaimer The Information in this e-mail is confidential and may be legally privileged. It is intended solely for the addressee. Access to this e-mail by anyone else is unauthorised. If you are not the intended recipient, any disclosure, copying, distribution or any action taken or omitted to be taken in reliance on it, is prohibited and may be unlawful. Any opinions or advice contained in this e-mail are confidential and not for public display. * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * 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] Toggle Selection State of All
Try Edit Select All. Selects the whole board. Then Edit De-Select All. This is from the menu. Rusty Garfield Yes, but Mark was looking for previously selected items to become unselected, and vice versa. That is different from selecting everything, or de-selecting everthing. Regards, Geoff Harland. - E-Mail Disclaimer The Information in this e-mail is confidential and may be legally privileged. It is intended solely for the addressee. Access to this e-mail by anyone else is unauthorised. If you are not the intended recipient, any disclosure, copying, distribution or any action taken or omitted to be taken in reliance on it, is prohibited and may be unlawful. Any opinions or advice contained in this e-mail are confidential and not for public display. * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * 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] NPT mounting holes
It's useful to have a pad of finite size so that it'll be visible as a reminder in case you have (Show) Pad Holes turned off on the Design\Options panel. Best to make an NPT pad up as a single-layer pad on the Drill Drawing Layer; this avoids creating objects on the Mask Layers during Gerber generation, and eliminates error messages during DRC. I use 10mil diameter pad for standard boards, with the hole size adjusted to suit. Brian While I appreciate that using pads on the Drill Drawing Layer avoids creating images on the Solder Mask layers, printouts of the Drill Drawing layer are problematic for such pads; only those pads which are located on the MultiLayer layer, and external copper layers (I think), have their associated hole diameters depicted, and counted, in printouts of the Drill Drawing layer. (However, these holes *are* listed and counted in the NC Drill files.) As such, I confine all pads having an associated hole to the MultiLayer layer (see below for more details). I make the pad and the hole size the same and tick off the Plated box in the Pad-Advanced menu. It works fine with the Print Preview and my PCB manufacturer doesn't complain. Igor Do I need to have a pad size greater than zero for a NPT hole (mounting) or should I make it equal to zero. Jerry Gierach Personal preference to some extent, but I set each such pad's pad diameter equal to its hole diameter when saving the PCB file, and when generating printouts. And when I want to generate Gerber files, I set the pad diameter of all such pads equal to zero. I have created a process within my PcbAddon server which facilitates either zeroing all such pad diameters (for pads having unplated holes) or setting the pad diameter of each such pad equal to its hole diameter. Setting the pad diameter equal to hole diameter when producing printouts means that the associated hole gets to be depicted in the printouts; OTOH, there is no merit in flashing such pads within Gerber files (because any copper within the associated hole's boundary does not end up within the final PCB). While it arguably doesn't hurt to have such pads flashed (as long as the diameter of the flash is less than the diameter of the pad's hole), eliminating a flash all together results in smaller Gerber files. Regards, Geoff Harland. - E-Mail Disclaimer The Information in this e-mail is confidential and may be legally privileged. It is intended solely for the addressee. Access to this e-mail by anyone else is unauthorised. If you are not the intended recipient, any disclosure, copying, distribution or any action taken or omitted to be taken in reliance on it, is prohibited and may be unlawful. Any opinions or advice contained in this e-mail are confidential and not for public display. * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * 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 07:01 PM 3/28/2002 +1000, Don Ingram wrote: Strikes me that it would be so much easier if prottle ( on ALL of the system ) followed the usual windows convention of shift+LMB+drag to add to a selection LMB+drag to set a selection. This way you could reliably clear a selection by dragging on an empty space. However, the Protel selection scheme is useful in other ways which require that it have more permanence than that. The problem here is that Protel gives no warning when objects are moved outside the workspace, and DRC does not detect these objects. Both of these should be fixed. (Being able to temporarily move parts of a selection outside the workspace can be useful as well, otherwise I'd suggest that it be impossible to accomplish this. Having the ability to place a selection even when it creates something outside gives more freedom in where one puts the selection. I've used systems that did not allow this, and I prefer the Protel way.) Abd ul-Rahman Lomax 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). 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. OTOH, it is not always obvious when items are outside this area, so that is the drawback to not prohibiting this. (Maybe the user could be given the capability to select either one option of always prohibiting such movements, or another option of always being able to perform such movements, or yet another option of being warned whenever a movement of one or more objects would move one or more of those outside this area (in the event that the user did not then abort the move command concerned).) Having said that, given that users (currently) can move items outside this workspace (to some extent, but not without limits), I fully concur that netlist aspects of the PCB design should not be compromised as a consequence of moving pads outside that area (either temporarily or otherwise). Concerning warning users of out-of-workspace items, I recall that the AD 2.0 version of PCAD (and in all probability, various other DOS versions of PCAD as well) set the border of the screen to a crimson (?) color whenever the snap grid control was turned off (to alert users of that situation). In a Windows setting, the same approach would not be appropriate, but it is still food for thought as to how users could be alerted of the existence of out-of-workspace items. (Speaking personally, I try to avoid moving items out of the workspace area. That said, there have been times when I have imported Gerber files containing negative co-ordinates, and I have then appreciated being able to select everything, and then move the entire contents in such a manner that all of the items then end up within the workspace area.) Regards, Geoff Harland. - E-Mail Disclaimer The Information in this e-mail is confidential and may be legally privileged. It is intended solely for the addressee. Access to this e-mail by anyone else is unauthorised. If you are not the intended recipient, any disclosure, copying, distribution or any action taken or omitted to be taken in reliance on it, is prohibited and may be unlawful. Any opinions or advice contained in this e-mail are confidential and not for public display. * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * 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] Text
Geoff Harland wrote: I know that you can put lines over pin names on schematic symbols to denote an inverted signal. Can this be done on PCB part types text strings? You can, of course, place a line on the overlay layer over the text string. It is a separate entity, and will have to be moved separately, but it will get the appearance you want. Jon Elson Actually, Sean James wrote the above, not me; I responded to a post of his, and that post included what he had previously posted. Going slightly OT, other mailing lists and NewsGroups I subscribe to, sometimes have threads on Top Posting and Bottom Posting; apparently some people subscribe strongly to the view that Top Posting is a Very Bad Thing, and as such, is something that no well-raised individual would even contemplate, let alone practice. (This post is using the kosher Bottom Posting style, in which the response is placed below the contents of the previous message; with Top Posting, that sequence is reversed.) With the (officially preferred) Bottom Posting style, you get to read what is being responded to before reading the response to it. OTOH, with Top Posting (BOO!! HISS!! :) ), if you have just finished reading a previous posting, you already know what the previous correspondent said, so reading the response to that straight off can save you from having to scroll through the contents of the post in order to read the fresh contributions. However, there are some posts when it is desirable for the responses to be interleaved with the material being responded to, not atypically on a paragraph-by-paragraph basis. In that situation, the Bottom Posting protocol is indisputably appropriate (while usage of the Top Posting protocol would be indisputably *in*-appropriate in such circumstances). Presumably this is a significant reason why Bottom Posting is regarded as the Right Way To (always) Do It. If anyone wants to add anything further on Internet ettiquette re email postings, I would suggest that this be done on the Protel OT mailing list (before we are requested to do so by these mailing lists' Administrator). Regards, Geoff Harland. - E-Mail Disclaimer The Information in this e-mail is confidential and may be legally privileged. It is intended solely for the addressee. Access to this e-mail by anyone else is unauthorised. If you are not the intended recipient, any disclosure, copying, distribution or any action taken or omitted to be taken in reliance on it, is prohibited and may be unlawful. Any opinions or advice contained in this e-mail are confidential and not for public display. * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * 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
I have a small problem with small parts in a small area on a small board (so what else is new?). I have 4 parallel channels of a Quad Transimpedance Amplifier circuit, which is very high gain and requires good isolation. The circuit is all descrete analog components, mostly 0402, except for the S0-8 op-amps, and is packaged quite densely with only .020 between components in the tight spots, and no room for package outlines. The circuit is layed out very nicely, and is electrically excellent, but unfortunately, there is no room for designators. snip Anyone out there got any useful ideas? JaMi Smith To start off with, this could well be my last post (or else very nearly my last post) from this email address. I'm currently looking for another job (preferably in Sydney, Australia, where I am currently living), with my current job finishing this week (the usual circumstances for this era). But I have recently signed up to these forums from my home email address, so other members of these forums will continue to hear from me on an ongoing basis, but from a different email address. Now on to this thread. It is being wise after the event, and not necessarily the best way to do it, but if you want components R1_1, R1_2, R1_3, and R1_4 (say), then add component R1_1 to the PCB file, then append a R1 string (on the Top Overlay layer) to this component (using the Menu item 'Tools/Convert/Add Selected Primitives to Component'; the component's primitives need to be in an unlocked state at the time), then create the R1_2, R1_3, and R1_4 components from copying the R1_1 component to the (Protel) clipboard and then pasting back into the PCB file, then re-annotating the pasted components as required. The additional R1 string is part of each of these components, and will thus move with its component whenever that component is moved. (Moving the string *relative* to the component will require the component's primitives need to be in an unlocked state at the time though, but keep in mind that the global command feature can be used to unlock (or relock) the primitives of more than one component at a time.) All up though, a lot of extra work is called for, even if it is all planned in advance (to minimise the amount of extra work required). But short of creating a customised addon Process of some sort (for example, one which acts upon currently selected free strings so that these are automatically appended to appropriate components which are also currently selected), I am not sure of any other way of doing it, other than the suggestion made by others to use the component's Comment strings. Concerning the use of Comment strings, the Schematic drawings could still be implemented to display component values (e.g. 10k, 100nF, etc) for each component by using one of the 16 Part Fields for this purpose, and setting the corresponding string to be visible. The Part Type (field) (for each component) could then be used to hold the desired abbreviated Designator (e.g. R1 for components R1_1, R1_2, etc), with the corresponding string set invisible (unless it was desired to keep this visible). When information was passed from the Schematic File(s) to the PCB file, the Comment string of each component would then acquire the desired abbreviated Designator for this, and any subsequent re-synchronisation between the Schematic file(s) and the PCB file would *not* result in these desired abbreviated Designators being lost or over-written for *any* of the components (in the PCB file). Some extra work called for with that method as well, but if planned in advance, the amount of extra work required could again be reduced (and probably substantially). If used, I would strongly recommend the addition of an annotation to the Schematic file(s), documenting the usage of this technique. Regards, Geoff Harland. - E-Mail Disclaimer The Information in this e-mail is confidential and may be legally privileged. It is intended solely for the addressee. Access to this e-mail by anyone else is unauthorised. If you are not the intended recipient, any disclosure, copying, distribution or any action taken or omitted to be taken in reliance on it, is prohibited and may be unlawful. Any opinions or advice contained in this e-mail are confidential and not for public display. * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * 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 * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
