Re: [PEDA] More SPs for older major versions?
A sad consequence of all this is that Altium actually lose sales and the community bcomes more closed as a result of cracked versions in circulation. A university lecturer friend tells me that ALL the students in his classes have got hold of (and sometimes use!) cracked versions of Protel and DXP. Altium will find it hard to maintain the moral high ground when they charge $10,000 for software that is expensive, is buggy, is always going to be buggy and has a limited lifespan. I bought a one-time licence for SE a long time ago but when it no longer wants to play with the latest Windows OS then I shall be looking around for an affordable alternative. My tendency is towards Tsien at the moment; take a look guys. Robert Gillatt In this day and age, there are probably very few (if any) software applications which have not been cracked to at least some extent. So to the extent that there is a difference in that regard, some applications have been cracked to a greater extent than others. I have no idea to what extent Altium's products have been cracked; doubtless the degree of piracy also varies between different countries. But it is still hard to feel sorry for Altium, given the way it has treated its customers. I suspect that I am far from the only customer who has prepared a detailed report describing the nature and scope of a defect, only to not even receive any response whatsoever to my report. (That hasn't happened on every single occasion that I have submitted a bug report, but it has still happened on a number of occasions, and for a significant proportion of bug reports which I have submitted.) But given the ongoing development of open-source CAD applications, where the efforts of developers are augmented by bug-fixes submitted by those applications' users (and where those users do have the potential to fix any defects themselves, given that they have access to the relevant source code), it is becoming increasingly ill-advised for companies such as Altium to treat their customers so shabilly. While they have managed to survive to date, I still definitely wouldn't want to make any serious wager that they will still be around ten years (say) from now; perhaps even five years from now. Although I have some cause to believe that they might have lifted their act to some extent with AD2006 (though I can't vouch for personally, given that I have never used it), it could well still be a case of too little, too late in that regard. And as far as piracy of software in general is concerned, that could be regarded as market forces in action. So-called neo-classic economic theory stipulates that the natural price of any product or service is the marginal cost associated with providing it. And in the case of software, that cost is almost zero. (What is the cost of a CD or DVD containing copies of the relevant files, and the cost of actually creating that CD or DVD?) In making that observation, I am not condoning piracy. However, such market forces are not the only threat that software companies have to contend with; they also have to contend with open-source applications, whose developers can be regarded as providing their product to the world-at-large for free. While there have been some who have attempted to prevent the release of open-source software, I believe that they all deserve to fail in their efforts. It is one thing for software companies to be permitted to take action against those pirating their applications, but they definitely shouldn't also be permitted to prevent anyone else from releasing any software (which they have written themselves) into the public domain. Regards, Geoff. Make the switch to the world's best email. Get the new Yahoo!7 Mail now. www.yahoo7.com.au/worldsbestemail You are subscribed to the PEDA discussion forum To Post messages: mailto:PEDA@techservinc.com Unsubscribe and Other Options: http://techservinc.com/mailman/listinfo/peda_techservinc.com Browse or Search Old Archives (2001-2004): http://www.mail-archive.com/[EMAIL PROTECTED] Browse or Search Current Archives (2004-Current): http://www.mail-archive.com/peda@techservinc.com
[PEDA] More SPs for older major versions? (was Re: Schematic - Dashed Lines.)
Jon Elson wrote: Geoff Harland wrote: But just in case anyone has a tin ear, I do NOT think that defects like that are all right then at all. I'm not unduly bothered about that defect in particular, but it is still all-too-typical of what Altium has been shipping to its customers since the days when God was still in diapers. Although I would have much preferred Altium continued work on P99 instead of always making a New, Revolutionary, Totally recreated from the ground up sofware package, I think I can see that they make a lot more money selling a new package than updating an old one. But, really, P99 is a ten-year old package, so I can understand their dropping support and improvements. I don't dispute that it would be more profitable for Altium to sell new versions of their software than to continue issuing SPs for earlier versions. (And I am not suggesting that it is wrong for Altium to (attempt to) make a profit from selling software to the public at large.) However, I consider that their customers are also entitled to be provided with software which is free from serious defects (ideally, totally defect-free of course, but as that would not be realistic, and/or result in much higher prices, then at least free of all serious defects), and in the event that any serious defects actually are shipped, then to have those rectified on an ASAP basis. Signing on for that attitude would be doing the right thing as far as their customers are concerned, and it would also reduce (if not totally eliminate) any cause for any of their customers to believe that Altium is in the business of selling them snake oil. But over and above that, treating their customers to that level of care and consideration would increase the likelihood that more of them would want to come back again (in the form of updating to each new major version of the application). But instead of focusing on eradicating outstanding serious defects within each SP released for each major version, Altium has been providing a lot of new functionality instead. That would be less objectionable if there were no still-outstanding serious defects at the time, and if the new functionality was not also defective, and if previously provided functionality wasn't also broken at the same time. And (not too surprisingly, given all of that) after the last SP has been released (for each major version), many serious defects are still outstanding. And because no more SPs have been released for any major version after the initial version of the next major version has been released, such defects end up being of a permanent nature, as far as each major version is concerned. I agree that it could be regarded as over the top for Altium to issue any more SPs for Protel 99 SE, as it definitely is long in the tooth at this point in time. However, if they actually did issue another SP for it, then it could be regarded as sending a powerful message to their customers that they actually do care for them. And even though many of their customers (currently owning no later version than Protel 99 SE) would (still) *not* subsequently upgrade to any later version, the attitude projected by Altium could still result in *some* of those customers subsequently opting to upgrade, when they would not *otherwise* have done so. So maybe the number of customers upgrading could even be sufficiently large to cover the costs associated with tracking down and subsequently rectifying the outstanding serious defects within Protel 99 SE, resulting in outcomes of not only doing the right thing for those customers, but also doing no harm to (and perhaps even improving) their bottom line. But even if it could still be regarded as over the top for Altium to issue any more SPs for Protel 99 SE, or for DXP (because of the period of time that has lapsed since the last SP was released for each of those versions), the still very buggy nature of AD2004 would be good grounds for at least one more SP to be released for at least that version. As I have said before, it would be one thing to not issue any further SPs for that version if there were no outstanding defects of a serious nature - but that is definitely not the case. And as such, there are arguably good grounds for owners of AD2004 to take a class action suit against Altium (because of outstanding defects of a serious nature), and as such, they have arguably had an undeserved break, due to those customers not doing so (to date). I honestly can't and don't understand why there aren't far more complaints about how buggy Altium's software is. However, as far as I am concerned, anyone who doesn't see fit to complain about the defects in their applications, but who is prepared to publicly defend them, is an accessory to the provision of crappy software, and is thus part of the problem. I do NOT defend Altium, and have decided I will not buy anything
Re: [PEDA] Schematic - Dashed Lines.
So it is not really a bug, because a menu choice had been provided that didn't work. Oh well, so that's all right then. And even though that menu choice doesn't work, it is actually still possible to create dashed lines by pasting short line segments, as and how required. That's really fantastic too; where would everyone be without the provision of such advice to help them out? But just in case anyone has a tin ear, I do NOT think that defects like that are all right then at all. I'm not unduly bothered about that defect in particular, but it is still all-too-typical of what Altium has been shipping to its customers since the days when God was still in diapers. I honestly can't and don't understand why there aren't far more complaints about how buggy Altium's software is. However, as far as I am concerned, anyone who doesn't see fit to complain about the defects in their applications, but who is prepared to publicly defend them, is an accessory to the provision of crappy software, and is thus part of the problem. It is public knowledge that many people are unhappy about Microsoft. I'm not trying to start any flame war on that matter, and/or which type of OS (Windows, Linux, or others) that people should install on their PCs, but at least MS continues to provide service packs and patches for earlier versions of Windows for quite some time after releasing following versions. (They aren't still supporting NT 4.0, but they still did so for some time after releasing following versions, and AFAIK, they are still, for at least the time being, continuing to support Windows 2000.) OTOH, each time Altium releases another major version, they stop releasing SPs for the previous major version. It would be one thing to not continue releasing SPs for the previous version if the last SP released for that version resulted in it being totally bug-free. However, not only has that never been the case, but the final versions of each major version still contain *serious* defects, such as those involving output (e.g. Gerber files and printouts). I don't believe for one minute that Altium are at all likely to ever release a SP5 for AD2004 (or a SP3 for DXP, or a SP7 for Protel 99SE, or a SP4 for Protel 98 ...). However, given that other companies have issued product recalls on various occasions and for various reasons, I still don't understand why Altium's customers tolerate that. And to make matters even worse, there is nothing atypical about outstanding defects continuing to remain unrectified within following major versions. So not only are customers not getting serious defects rectified for free, but many are paying good money to upgrade to the next major version, ... and *still* not getting many serious defects rectified. I don't want to see the software industry subjected to higher levels of regulation than is currently the case, as it is unlikely that there would be a beneficial impact as far as prices or ongoing innovation are concerned. But software of the quality released by Altium still increases the likelihood of such an outcome occurring. I have already said what I think of anyone who doesn't see fit to complain about the defects, but who is prepared to publicly defend them. In the case of this defect, shortcomings of the GDI could be regarded as a complicating factor, but it is still not an excuse for failing to provide some type of workaround of a satisfactory manner, or otherwise appropriately modifying the user interface to prevent giving users the impression that certain functionality is available when that is actually not the case. Regards, Geoff. Harry Selfridge wrote: Hi Brad, This is an old issue that is well known. It's not really a bug, but a result of how the dotted and dashed lines were produced. In Protel99SE graphical lines were drawn using the Windows Graphics Device Interface (GDI), and the Windows GDI does not support the width property. The bug was allowing a menu choice that didn't work. You can manually create dashed lines of any width by drawing a short solid line with the desired width, then use copy and paste, or paste it multiple times using Paste Array. Regards - Harry At 11:43 AM 1/7/2008, you wrote: The schematic line tool displays dashed (and dotted) lines with the line width of smallest no matter what it is set to. If you change the line back to solid then the line width gets set to the correct value. Is this a known bug? Protel99SE SP6. Tx Brad. Make the switch to the world's best email. Get the new Yahoo!7 Mail now. www.yahoo7.com.au/worldsbestemail You are subscribed to the PEDA discussion forum To Post messages: mailto:PEDA@techservinc.com Unsubscribe and Other Options: http://techservinc.com/mailman/listinfo/peda_techservinc.com Browse or Search Old Archives (2001-2004):
Re: [PEDA] Anyone using P99SE in Win Vista?
I didn't think that it would be too likely that you would be trying to open Library files of a more recent version (than Protel 99 SE), but not overlooking the obvious still eliminates the possibility of doing so (and the feedback which you originally reported did suggest that that possibility couldn't be ruled out). Given the additional information which you have since provided though, I do have recollections of reading that there have been other applications which have also been experiencing problems with running on Vista. As with many defects within Windows applications, this now looks like yet another case of: is Microsoft responsible for what is happening, or is it the provider of the (problematic) application? While I don't know if Microsoft is totally blameless in this case, the fact still remains that they do provide documentation (albeit sometimes of a standard where there is room for improvement) to application developers which specify various details concerning how applications should be written, and when those specifications are complied with, there is a greater probability that such applications will continue to function in (yet more) future versions of Windows. So it's not out of the question that this could be a situation when Altium's programmers failed to RTFM... In any event, I assess that the problem more likely than not to be unfixable, so if it's not out of the question, maybe you should look at setting up a dual boot PC (Win XP and Vista), or otherwise keeping a PC on which (just) Win XP is installed, so that you can continue using Protel 99 SE. (And you can always retire that setup if MS subsequently does provide a fix.) Regards, Geoff Harland. Yes that did occur to me, I actually am able to open the library that I'm having problems with to do my edits and then save it, however if I then try and load the library through the add/remove libraries I get the same file not recognized error message and can't load it. So am I'm kind of at a loss here, it seems to indicate perhaps not a problem with Protel but rather Windows Vista, as I have never had this kind of problem in Win XP. I'll play around with it a bit more and see. -Casey. At the risk of stating the obvious, are the Library files concerned of a more recent version than Protel 99 SE? You should be able to open any Library files which were created using any *earlier* versions (of Protel), but with the possible caveat that the footprints within them might require some tweaking afterwards (as alluded to within other recent contributions to this mailing list). But I still wouldn't be the slightest bit surprised if you encountered problems while trying to open any Library files which had been created using any more recent version instead; the format of such files probably would be of an unexpected nature to the Pcb Library server provided with Protel 99 SE. Regards, Geoff Harland. I just got a new computer which of course came with Vista, P99SE installed fine and seems to be working alright, but then I tried to install some different PCB libraries and it keeps saying unrecognized file format, so I can't load them. I went through several libs to try, including some of the Protel ones, but again same error, has anyone else run into this? Some of the things I tried is running Protel in different compatibility modes, but again same problem. Casey. Sick of deleting your inbox? Yahoo!7 Mail has free unlimited storage. http://au.docs.yahoo.com/mail/unlimitedstorage.html You are subscribed to the PEDA discussion forum To Post messages: mailto:PEDA@techservinc.com Unsubscribe and Other Options: http://techservinc.com/mailman/listinfo/peda_techservinc.com Browse or Search Old Archives (2001-2004): http://www.mail-archive.com/[EMAIL PROTECTED] Browse or Search Current Archives (2004-Current): http://www.mail-archive.com/peda@techservinc.com
Re: [PEDA] Anyone using P99SE in Win Vista?
Casey Vanderweide wrote: I just got a new computer which of course came with Vista, P99SE installed fine and seems to be working alright, but then I tried to install some different PCB libraries and it keeps saying unrecognized file format, so I can't load them. I went through several libs to try, including some of the Protel ones, but again same error, has anyone else run into this? Some of the things I tried is running Protel in different compatibility modes, but again same problem. Casey. At the risk of stating the obvious, are the Library files concerned of a more recent version than Protel 99 SE? You should be able to open any Library files which were created using any *earlier* versions (of Protel), but with the possible caveat that the footprints within them might require some tweaking afterwards (as alluded to within other recent contributions to this mailing list). But I still wouldn't be the slightest bit surprised if you encountered problems while trying to open any Library files which had been created using any more recent version instead; the format of such files probably would be of an unexpected nature to the Pcb Library server provided with Protel 99 SE. Regards, Geoff Harland. Sick of deleting your inbox? Yahoo!7 Mail has free unlimited storage. http://au.docs.yahoo.com/mail/unlimitedstorage.html You are subscribed to the PEDA discussion forum To Post messages: mailto:PEDA@techservinc.com Unsubscribe and Other Options: http://techservinc.com/mailman/listinfo/peda_techservinc.com Browse or Search Old Archives (2001-2004): http://www.mail-archive.com/[EMAIL PROTECTED] Browse or Search Current Archives (2004-Current): http://www.mail-archive.com/peda@techservinc.com
[PEDA] AD6.x vs Protel 99 SE (was: IPC Designers Council Meeting)
procedures are not as good as they could and should be, then the life of designers becomes that much more difficult, as they then need to spend much more time assessing which reported DRC errors are crying wolf, and which ones *aren't* - and if there are a lot of false alarms, then there is also a greater danger of missing errors which really are problematic. Am I a disgruntled ex-employee? Yes I am - but any engineer who turned in work as shoddy as the software that Altium has shipped to its customers could usually expect to be sacked in pretty short order - and perhaps end up in prison if any aspect of a project which had been overlooked subsequently resulted in members of the general public losing their lives (or even being injured). However, I, and others who also attempted to raise the bar, were let go, and (supposedly) because Altium was losing money at the time (an outcome which could hardly be regarded as surprising when the quality of the software being released at that time is taken into account). But those responsible for quality control remain at the helm; what an inspiration to their shareholders, customers, and (remaining) employees. But as long as their (prevailing) customers continue to accept what they are being served up with, and don't complain more vigorously than what they have been doing, I would find it very difficult to believe that the quality of the software would, or actually has, improved to any significant extent. However I have now had a gutsful of trying to improve matters; my efforts in that regard have not been given the level of respect which I would regard as appropriate, and it seems that most of the (prevailing) users are nowhere near as bothered as I am about numerous defects in the software which simply shouldn't be there. And as I suspect that various people on this list think that I am grumbling without good cause, and are not of an inclination to back me when I refer to matters concerning software quality, I've had enough. Good luck when it comes to trying to improve matters, as I won't be making any more efforts myself. Regards, Geoff Harland. Sick of deleting your inbox? Yahoo!7 Mail has free unlimited storage. http://au.docs.yahoo.com/mail/unlimitedstorage.html You are subscribed to the PEDA discussion forum To Post messages: mailto:PEDA@techservinc.com Unsubscribe and Other Options: http://techservinc.com/mailman/listinfo/peda_techservinc.com Browse or Search Old Archives (2001-2004): http://www.mail-archive.com/[EMAIL PROTECTED] Browse or Search Current Archives (2004-Current): http://www.mail-archive.com/peda@techservinc.com
Re: [PEDA] DXP PCB - 99SE
While it has been a few days since the previous most recent contribution to this thread, everyone should note that there can *also* be problems when attempting to reopen files within a *later* version of Protel/Altium Designer than the version which had been used to create those files previously. I can't provide a comprehensive list of all the problematic version-pairs, but I know that there can be problems with opening PCB files in Protel 99 SE that previously been created using AdvPcb 2.8 (not necessarily all of the time, but still problematic in some cases). And I have also had problems with opening files in Altium Designer 2004 (SP4) that had previously been created using Protel 99 SE (SP6). More specifically, the scopes for some of the design rules had not been specified correctly. Nobody has ever explicitly confirmed it to me, but I have still inferred that the intention behind providing various keywords that have been provided for use within queries was to enable scopes of design rules specified within PCB files created using Protel 99 SE to be re-specified when such files are subsequently opened within a later version. Regrettably though ... , it looks like not all of the associated spadework was done when it came to (the source code) processing the scopes and subscopes of each design rule, and what has actually happened instead is yet another instance of the near enough is good enough mentality that is all too frequent within the software. It is one thing for there to be issues when attempting to resave a file for subsequent use within an *earlier* version (as earlier versions don't necessarily have all of the functionality and features of later versions), or when exporting or importing files associated with other applications (as other applications might not support some of AD's features, and vice versa). However, there should *never* be any issues with reopening any files in any *later* version; while details of how some functionality is actually implemented can change between different versions (such as how to specify the scopes of design rules, as one example), there should still never be any *loss* of functionality when using a more recent version. In the case of the PCB file which I had problems with, I was able to rectify the situation by re-specifying the scopes of each (previously problematic) design rule as required. But the point still remains that I *shouldn't* have needed to have done that; the scopes of each design rule *should* have been specified correctly, by the software, at the time that the PCB file was been reopened. Given the motivation, I doubtless could provide details of the particular subscopes which I had problems with. However, I have had a f*cking gutsful of spending considerable amounts of time in comprehensively documenting defects within the software (with the objective of making life as easy as possible for whoever would subsequently be assigned the task of rectifying each such issue), only to have my efforts subsequently ignored (or even rejected) on all too many occasions. And as such, I am instead opting for alerting others that there are issues in this regard, and that this is yet another instance of something else to be on the lookout for whenever using AD (or any of the earlier versions). Does anyone consider that AD 6 is really much better than AD 2004? I know that more features have been provided, and I gather that some of the issues which afflicted AD 2004 have supposedly now been rectified, but is the *quality* of AD 6 (as far as bugginess is concerned) higher than that of previous versions? Based on past form, I would find it very difficult to accept that there have been any significant improvements in that regard. Regards, Geoff Harland. Brad Velander wrote: Danger, Danger Will Robinson! P98 to P99SE: A few patches, additional Mech layers, new rules, new capabilities, different ways of handling some existing functionality, etc., etc.. To export from DXP/AD to P99SE, use the save as function and file extension *.PCB (version 4). Be warned, exporting from DXP/AD to P99SE can/will loose some rules and other capabilities that were added to DXP/AD and just weren't around/available in P99SE. (i.e. polygon cutouts, rules that just weren't available in P99SE and may effect a lot of the design.) It may look the same until you actually repour items, do a DRC, etc. in P99SE. But there is absolutely no truth to the 'rumor' that P98 is closer to DXP than P99SE, just the opposite. Just think about it. Sincerely, Brad Velander Senior PCB Designer Northern Airborne Technology #14 - 1925 Kirschner Road, Kelowna, BC, V1Y 4N7. tel (250) 763-2232 ext. 225 fax (250) 762-3374 Sick of deleting your inbox? Yahoo!7 Mail has free unlimited storage. http://au.docs.yahoo.com/mail
Re: [PEDA] DXP PCB - 99SE
Darren Moore wrote: Hi Guys, There are two levels to this issue. Both are very easy to sort once you know how. First is the pcb and schematic are just not in sync, 'Project, Component Links...' (shortcut CK) will open a dialog, which the match by designator check box should be checked by default, press the add match pairs by button, then perform the update button, should address this. The other issue can be the schematic has some components using the same unique ID, this is addressed with the 'Tools Convert, Reset Component Unique ID's' (shortcut TVR), this will assign unique ID to all the components, you then need to do the first step above. Once you understand how this works it doesn't take long to address, it's a pity the first time can be such a pain. Regards, Darren That information will doubtless be of value to everyone who was not previously aware of it - but it still doesn't change the fact that nobody should have to tweak any files after they are opened using a more recent version of AD (than the version which had been used at the time that those files had previously been saved). It should be clear to everyone that I fully agree with what Jeff Condit said in an earlier message: I think that you should be able to port a design forward within a product line effortlessly, errorlessly, and losslessly. I also think that process should go backward effortlessly, errorlessly, and losslessly provided you don't introduce any of the new features which are not backward compatible. For example, if I take a P99SE design and import it into DXP 2004, I SHOULD be able to take the resulting design (without any changes) and export it back into P99SE and arrive at a functionally exact equivalent file I originally started with. Regrettably though, accomplishing such an outcome would call for a far higher level of quality control than what Altium has managed to display to date (or at least up until the time that AD6 was released, though reading the release notes provided for its service packs suggests that it is still business as usual in that regard). I could say more, but what's the point? Until substantially more users start complaining much more vigorously about the level of defects within AD, Altium are just going to continue delivering more and more and more and more and more of the same... Regards, Geoff Harland. Sick of deleting your inbox? Yahoo!7 Mail has free unlimited storage. http://au.docs.yahoo.com/mail/unlimitedstorage.html You are subscribed to the PEDA discussion forum To Post messages: mailto:PEDA@techservinc.com Unsubscribe and Other Options: http://techservinc.com/mailman/listinfo/peda_techservinc.com Browse or Search Old Archives (2001-2004): http://www.mail-archive.com/[EMAIL PROTECTED] Browse or Search Current Archives (2004-Current): http://www.mail-archive.com/peda@techservinc.com
Re: [PEDA] Query about Export command for Protel 99 SE's PcbPrint server
Geoff Harland wrote: snip Thanks for the tip, but I was really attempting to establish whether the Export command which I referred to before is defective on *just* my PC, or whether it is otherwise a genuine defect within Protel 99 SE (and thus a defect affecting *every* PC on which Protel 99 SE is installed). snip I have just tried it - the command seems to work properly on my computer (Protel99SE + SP6, WinXPPro). It creates the folder and the wmf file(s) - I previewed one of those wmf's in IrfanView and then imported it into MSWord. At the very first glance the orientations of the strings seem to be OK. Regards, Wojciech Oborski Thank you very much for reporting what you discovered. I had an idea that I had got that command to work in the past, but because I had previously had no interest in actually using it, I wasn't absolutely sure. In any event, after reading your report, I tried creating a .DDB file using the 'MS Access Database' option (in place of the 'Windows File System' option which I had used previously), and with that type of file, that command did then work on my PC (but not without defects, as I will describe when I can find some time to specify the associated details). So I am now surmising that at the time that the associated PcbPrint server was first released (during 1999, and as an optional addon server to be used in conjunction with the *original* version of Protel 99), the 'Windows File System' option had yet to be provided for .DDB files, meaning that the only option available for .DDB files at that time was the 'MS Access Database' option. So I now figure that after first acquiring a copy of the PcbPrint server, I took a look at the Export (to metafiles) command at that time, but because the associated functionality was of no interest to me, I never got around to retesting that command with .DDB files using the 'Windows File System' option until just a few days ago. So unless anyone subsequently reports that they can create metafiles from .DDB files using the 'Windows File System' option by using the Export (to metafiles) command (which would imply that there is some issue with my PC), I am concluding that this is yet another one of Protel 99 SE's bugs. And in that regard, it is a typical Altium bug; i.e. they provide some new feature (in the form of providing the 'Windows File System' option for .DDB files in this particular instance), while simultaneously managing to break (or not satisfactorily implement) functionality which had been provided previously (in the form of not satisfactorily implementing the Export (to metafiles) command for .DDB files using the 'Windows File System' option in this particular instance). I don't know if anyone else had discovered that defect before now and subsequently reported it to Altium, but even if that had happened, it wouldn't necessarily imply that any effort would have been made to actually rectify it. After all, there are assorted other defects which were only rectified many years after first being reported, or which have yet to be rectified even though many years have passed since the time that they were first reported. And even though that particular defect is regrettable, it is still small beer when compared with some of the other defects associated with the Protel/DXP/AD applications. But enough for the time being (and I will try and followup with some more details concerning the PcbPrint server as time permits). Regards, Geoff Harland. _ How would you spend $50,000 to create a more sustainable environment in Australia? Go to Yahoo!7 Answers and share your idea. http://advision.webevents.yahoo.com/aunz/lifestyle/answers/y7ans-babp_reg.html You are subscribed to the PEDA discussion forum To Post messages: mailto:PEDA@techservinc.com Unsubscribe and Other Options: http://techservinc.com/mailman/listinfo/peda_techservinc.com Browse or Search Old Archives (2001-2004): http://www.mail-archive.com/[EMAIL PROTECTED] Browse or Search Current Archives (2004-Current): http://www.mail-archive.com/peda@techservinc.com
Re: [PEDA] Query about Export command for Protel 99 SE's PcbPrint server
Geoff Harland wrote: snip So unless anyone subsequently reports that they can create metafiles from .DDB files using the 'Windows File System' option by using the Export (to metafiles) command (which would imply that there is some issue with my PC), I am concluding that this is yet another one of Protel 99 SE's bugs. snip Well, I haven't mentioned in my previous post that I use 'MS Access Database' storage option and I tested the Export command in such 'environment' So, I created new database with 'Windows File System' option and retested the Export command - the command seems to work the same way it worked with the 'MS Access Database' storage option - I mean it produces wmf files which seem to be usable. It was just a quick check. Regards, Wojciech Oborski Thank you for your additional testing and feedback. Your experience indicates that there could well be some aspect of my PC which is causing problems after all (unless I have come across a defect of a movable feast nature, which is not unheard of within the Protel/DXP/AD applications). I had previously been inclined to surmise that .DDB files using the 'Windows File System' option could be problematic, because after opening a .DDB file (of such a nature) with a file name of Printing_Test.Ddb and a path of D:\Misc (and thus a full file name of D:\Misc\Printing_Test.Ddb), the title bar of the info box invoked after attempting to create the metafiles contained the text string of 'Unable to write to D:\Misc\Root\Printing_Test.reg' (so the inclusion of the subfolder with the name of 'Root' within that path made me suspect that *not* using the 'MS Access Database' option could have been responsible for that outcome). Another thing which I have tried, but with the same result, was to log on as an administrator user (rather than as a Power user as I normally do). (When I previously used NT 4.0 on another PC, I always signed on as an administrator user at the time, but since changing to Win 2000 on a newer PC, I have set up a separate Power user account, and which I normally sign onto instead.) But while there is still an outstanding mystery as to why I am currently unable to create metafiles on my PC from .DDB files using the 'Windows File System' option, I am not too upset about that situation. I still have no interest in using that feature in normal circumstances, and the reason why I was wanting to try out that command in recent times was to ascertain under which circumstances any metafiles created by that command would contain misoriented text strings. And after getting that command to work after opening a .DDB file using the 'MS Access Database' option instead, I have now established that an associated metafile is problematic whenever the 'Enable Font Substitution' option and the 'Mirror Layers' option have both been selected for the corresponding Printout definition. (And the strings which are problematic in that regard are any strings which are depicted within the metafile in an unmirrored form, and whose Rotation property within the source PCB file is neither 0 degrees nor 180 degrees nor 360 degrees.) This defect of the Export (to metafiles) command occurs under the same circumstances that defects of a similar nature occur within previews of printouts, and within any printouts that are actually created from any .PPC file. OTOH, when the Copy (to the Windows clipboard) command is invoked instead (one way being by the menu entry of 'Edit - Copy', which results in the clipboard being loaded with an image of the preview of whichever Printout definition is currently focused), there is once again a defect of a similar nature - but rather than also similarly afflicting Printout definitions for which both of the 'Enable Font Substitution' and 'Mirror Layers' options have been selected, it *instead* afflicts Printout definitions for which the 'Enable Font Substitution' option has been selected and the 'Mirror Layers' option has *not* been selected. And for those who are interested, the Copy (to the Windows clipboard) command is still similarly afflicted within the final (SP4) version of AD 2004, but *both* *unmirrored* Printout definitions *and* *mirrored* Printout definitions (for which the 'Enable Font Substitution' option has been selected) are afflicted by this defect. OTOH, that particular defect has been *totally* purged (within the same version of AD 2004) from all previews of printouts, all actual printouts themselves, and all metafiles created by the Export (to metafiles) command. Maybe somebody can report if has since been rectified, but I am picking that the Copy (to the clipboard) command is still defective within the current version of AD 2006. (I can't test this myself, as I don't have any copies of any version of AD 2006.) What is highly disturbing about this particular defect though is that it took so long to rectify it within previews
Re: [PEDA] Query about Export command for Protel 99 SE's PcbPrint server
I wouldn't regard it as the end of the world if there really is a defect in that regard, as I was primarily interested in checking whether the orientations of any strings within the source PCB file would be screwed up within the metafile(s) created by using that command. (There are definite problems in that regard within printout previews, actual printouts, and copies of printouts to the Windows clipboard, so I was curious about checking whether there were also problems with the (exported) metafile(s) as well.) (In the case of Altium Designer 2004, it seems that there are no such problems with either printout previews, actual printouts, or (exported) metafiles (or as long as SP3 or SP4 is installed), but copies of printouts to the Windows clipboard are still problematic - and I suspect that that is *still* the case within the current version of AD 2006.) Geoff Harland I can't check this right now, but maybe another tip helps you. For any print output related issues, FinePrint has been serving me well for many years. It is a virtual printer driver that sits between the apps and the real printer driver, has a preview and provides a number of ways to modify the output (including save it as image). They have a trial version, so you could just see if it helps you. Gerhard Thanks for the tip, but I was really attempting to establish whether the Export command which I referred to before is defective on *just* my PC, or whether it is otherwise a genuine defect within Protel 99 SE (and thus a defect affecting *every* PC on which Protel 99 SE is installed). I actually use a copy of the (totally freeware) PdfCreator application (either http://sourceforge.net/projects/pdfcreator/ or http://www.pdfforge.org/ for further details) to create Acrobat files, and while there is a defect in the current version (0.9.3) involving the file creation date/time, it still creates otherwise satisfactory Acrobat files from any application from which printouts can be created. will FinePrint make a negative image on the printer ? Dennis Saputelli I don't think so. It does preview, repagination (several pages on one sheet), print job collate, add stationary/watermark overlays, color to BW, manual duplex (and maybe a few other things). It's not designed to actually alter the image to be printed. However, you can save an image (TIFF, bitmap, Windows metafile). If you have MS Office 2003, it also has an image printer. But for normal printing, that gets then elaborate... :) Gerhard If you want to create negative images, you should be able to install a printer driver for a postscript printer, then configure that driver so that it prints to a postscript file rather than to an actual printer. Such printer drivers typically provide both a mirrored image option and a negative image option (and if you so wanted, you could select *both* of those options). After thus creating a postscript file, you can then either convert it into an Acrobat file using the PdfCreator creator which I referred to before, or otherwise use an application such as Ghostscript to print it to any real printer. A tip for anyone still using Protel 99 SE is that when any pads on the MultiLayer layer are depicted within printouts created from the PcbPrint server, it is *always* the property values for the Middle layer of those pads which are actually depicted. That is not a problem for any such pads of a Simple nature (in which the property values on each of the Top, Middle, and Bottom layers are all identical), but it still is an issue whenever a PCB file contains any non-Simple pads and you want to create printouts depicting the details on the top and/or bottom (copper/signal) layers (for instance). There are various ways to create good printouts, but at the very least I consider that it is still preferable for people to be at least aware of this particular defect of Protel 99 SE. Regards, Geoff Harland. _ How would you spend $50,000 to create a more sustainable environment in Australia? Go to Yahoo!7 Answers and share your idea. http://advision.webevents.yahoo.com/aunz/lifestyle/answers/y7ans-babp_reg.html You are subscribed to the PEDA discussion forum To Post messages: mailto:PEDA@techservinc.com Unsubscribe and Other Options: http://techservinc.com/mailman/listinfo/peda_techservinc.com Browse or Search Old Archives (2001-2004): http://www.mail-archive.com/[EMAIL PROTECTED] Browse or Search Current Archives (2004-Current): http://www.mail-archive.com/peda@techservinc.com
[PEDA] Query about Export command for Protel 99 SE's PcbPrint server
I am wondering if anyone else on the list who is still using Protel 99 SE (SP6) can confirm whether they experience the same outcome if they attempt to export from a PcbPrint file (having an extension of .PPC). I have found that if I open such a file (containing a set of one or more Printout definitions) within Protel 99 SE, then invoke the associated (PcbPrint) server's 'File Export...' command, a dialog box with a caption of 'Export Options' is subsequently invoked. And if I then check the 'Export Copy To' checkbox and specify a valid path, then click on the 'OK' button, an info box is subsequently invoked alerting me that it is unable to write to a .reg file (having the same name as the .DDB file which is currently open, and a similar path to that of the .DDB file), along with text advising me of an Exception occurring within PCBPrint:PrintDocument (which is the process associated with this particular command), and also suggesting Note: After any system crash it is good practice to save your work and restart Windows.. I cannot recall off-hand whether that outcome has always occurred, but it happens regardless of which options I select within the preceding dialog box, and regardless of whether the .PPC file concerned incorporates just one Printout definition or multiple Printout definitions. (In Altium Designer 2004, invoking that command results in the generation of an .EMF file for each Printout definition that is listed within the currently focused .PPC file, so I would have expected either the same outcome from Protel 99 SE, or else the generation of a single .EMF file depicting the contents of whichever Printout definition is currently selected.) I can't remember if I have encountered this problem before, but I have previously used Protel 99 SE on Windows NT 4, and am currently using it on Windows 2000 instead (so maybe that could be doing something screwy). I am also using the 'Windows File System' option for the associated .DDB file (as I have never cared for using the 'MS Access Database' option), and perhaps this issue occurs only when that option is used. But I would still be curious if anyone else could report on their experiences. (Maybe there is just something oddball about the PC which I am currently using.) I wouldn't regard it as the end of the world if there really is a defect in that regard, as I was primarily interested in checking whether the orientations of any strings within the source PCB file would be screwed up within the metafile(s) created by using that command. (There are definite problems in that regard within printout previews, actual printouts, and copies of printouts to the Windows clipboard, so I was curious about checking whether there were also problems with the (exported) metafile(s) as well.) (In the case of Altium Designer 2004, it seems that there are no such problems with either printout previews, actual printouts, or (exported) metafiles (or as long as SP3 or SP4 is installed), but copies of printouts to the Windows clipboard are still problematic - and I suspect that that is *still* the case within the current version of AD 2006.) Regards, Geoff Harland. _ How would you spend $50,000 to create a more sustainable environment in Australia? Go to Yahoo!7 Answers and share your idea. http://advision.webevents.yahoo.com/aunz/lifestyle/answers/y7ans-babp_reg.html You are subscribed to the PEDA discussion forum To Post messages: mailto:PEDA@techservinc.com Unsubscribe and Other Options: http://techservinc.com/mailman/listinfo/peda_techservinc.com Browse or Search Old Archives (2001-2004): http://www.mail-archive.com/[EMAIL PROTECTED] Browse or Search Current Archives (2004-Current): http://www.mail-archive.com/peda@techservinc.com
Re: [PEDA] Open source equivalent to Protel
Steve and Andrew, Thank you for responding to my query about the nature of the contemporary versions of AutoCAD. It would be nice to think that certain providers of EDA applications would regard AutoCAD as a role model as far as software quality is concerned, and as such, a target to similarly aspire to. And in case anyone is interested, the other PCB designing application which I was thinking of yesterday (other than gEDA) was Kicad; two related URLs are as follows: http://kicad.sourceforge.net/en/index.shtml http://www.lis.inpg.fr/realise_au_lis/kicad There are both Linux and Windows versions of Kicad, and source code is also available for downloading by anyone who is interested in modifying it and/or contributing to its improvement. (And there are also two Yahoo! based two mailing lists, catering for users and developers.) Prior to acquiring and evaluating any related files, my initial assessment is that it is also unlikely to currently be a significant threat to Altium Designer. That said though, perhaps the potential for it to be a future threat to AD could be just what the doctor ordered when it comes to providing Altium with an incentive to lift their act. If I can find some time to look at Kicad and gain some idea of what it is like, I will report back. But if anyone else has already taken a look at it, I (and I suspect others) would still be interested to hear what they have to say about it. Regards, Geoff Harland. We use 2004 here at Avtron. Same conclusions. It is one of the most rock solid applications I've ever used. I've been using it for as long as I've been using Protel. It's not as tailored to EDA, but unlike Protel, it is solid, stable, and infinitely configurable. Sad to hear that it uses the new virtual dongling that has become the norm. Understandable from the software giant's POV (need I mention the wholesale and factory-sized IT thievery that certain far-east nations have and are engaging in?), but sad all the same. aj Geoff, We have AutoCAD 2007. As far as major bugs, there are none to report. It has on rare occasions locked up on me. I have used AutoCAD 11, 12, 2000, 2004 and it has always been a very stable product. There have been only 2 patches released for 2007. Printing has gotten incrementally easier with each release. They added a PDF printout that is decent but could use a little improvement as far as resolution is concerned. Moving, editing, rotating and dimensioning have been marginally improved over time. Editing blocks has gotten much easier. Most of the old commands from the DOS versions still work. Supposedly some of the biggest improvements have come in 3D but we rarely use that here. Customizing the menus and toolbars has been greatly improved along with text editing and can now be linked to spreadsheets. I know that some claim it is not intuitive for the casual user, but I have found it to be a powerful, useful, and very stable piece of software. What I dislike the most about AutoCAD is that I can no longer have a second copy of it on my home system unless we purchase their subscription plan, a $495 adder. Regards, Steve Smith Send instant messages to your online friends http://au.messenger.yahoo.com You are subscribed to the PEDA discussion forum To Post messages: mailto:PEDA@techservinc.com Unsubscribe and Other Options: http://techservinc.com/mailman/listinfo/peda_techservinc.com Browse or Search Old Archives (2001-2004): http://www.mail-archive.com/[EMAIL PROTECTED] Browse or Search Current Archives (2004-Current): http://www.mail-archive.com/peda@techservinc.com
Re: [PEDA] Common component pads
What I do in such circumstances is define pins 1, 1A, 2, 3, and 3A in the schematic component, and similar pads in the PCB component. And pins 1A and 3A (in the schematic component) should each have both their Name and Designator strings hidden, and be placed in the same locations as pins 1 and 3 (respectively). When you connect a wire to pins 1 and 1A (or to pins 3 and 3A) a junction will be depicted (as that wire is joining two different pins), and that acts as an alert that there is actually more than one pin residing at the location concerned. I have found that this method works very well, and to give credit where it is due, I first heard of it from Abd ulRaham Lomax. (a number of years ago, and on this mailing list). Regards, Geoff Harland. Hi, I have created a simple footprint for a component that supports 2 different physical packages ( a pcb-mount pot, 1 on 0.1 pitch the other on 0.2 pitch). The centre leg of both devices are common while the 2 pads on one side are common to each other as are the 2 on the other end. So the footprint has 5 pads, 1 common and 2 pairs. How do I create/define these pads such that Altium Designer DXP 2004 automatically associates the appropriate netlist to each pair of pads? At the moment, if the pads are designated 1, 1, 2, 3, 3, it only picks one 1 and one 3 meaning I have to go to every component using this footprint and assign nets to the empty pads. Which is fine until I do an update. The schematic for the component only has 3 pins (1, 2, 3) because there are only 3 pins on the physical device. A similar situation occurs where it would be nice to have an extra pad on, say, a radial footprint to allow for a 0.1 or a 0.2 capacitor to be fitted. Again, 1 pair of pads needs to be common. Best Regards (Mr) Laurie Biddulph You are subscribed to the PEDA discussion forum To Post messages: mailto:PEDA@techservinc.com Unsubscribe and Other Options: http://techservinc.com/mailman/listinfo/peda_techservinc.com Browse or Search Old Archives (2001-2004): http://www.mail-archive.com/proteledaforum@techservinc.com Browse or Search Current Archives (2004-Current): http://www.mail-archive.com/peda@techservinc.com
Re: [PEDA] No-clean flux leakage, was: (500V power supply)
I have no grudge against you Andrew (and I hope you have no grudge against me), but to be pedantic, mixing ammonia with water results in a mix of NH4+ and OH- ions, and it is the latter which results in the mix having a pH exceeding 7.0. (To be more pedantic, there are both H+ and OH- ions present (and in equal numbers) in (non-deionised) pure water, and the consequence of adding NH3 is to result in an imbalance in the number of H+ and OH- ions, with the latter then dominating.) However I fully agree that if anyone was to follow up with a mildly acid wash, then it would be very prudent to ensure that the boards did not end up in an acidic state afterwards. It would probably be prudent to also have a following wash consisting just of (deionised) water, so that if the consequence of the previous (mildly acidic) wash was to leave the board either very mildly acidic or very mildly alkaline (if the pH of that wash had not been fully spot on), then at least the pH of the board in its very final state would still be closer to 7.0 than would otherwise be the case. Regards, Geoff Harland. - Original Message - From: [EMAIL PROTECTED] To: [EMAIL PROTECTED]; peda@techservinc.com Sent: Monday, December 18, 2006 11:30 PM Subject: Re: [PEDA] No-clean flux leakage, was: (500V power supply) Since ammonia is basic (pH 7.0), one _technically speaking_ might want to consider an acidic wash (a dilute solution of white vinegar comes to mind) prior to final wash with de-ionzed water, in order to neutralize any active NH3 components still present on the PCB or components. You'd have to experiment to find the right wash strength to properly neutralize (and not acidify) the board. FYI Both alkali and acidic deposits will react negatively with exposed metal. r, aj You are subscribed to the PEDA discussion forum To Post messages: mailto:PEDA@techservinc.com Unsubscribe and Other Options: http://techservinc.com/mailman/listinfo/peda_techservinc.com Browse or Search Old Archives (2001-2004): http://www.mail-archive.com/proteledaforum@techservinc.com Browse or Search Current Archives (2004-Current): http://www.mail-archive.com/peda@techservinc.com
Re: [PEDA] Common component pads
I fully agree with Darren in recommending that every pin/pad within every component should always have an unique identity, and I initially opted for that policy after previously encountering problems when using the Specctra autorouter (and also the Neurocad autorouter). An issue involving non-unique pins/pads within Protel files had supposedly been rectified some time ago (within one of the SPs released for Protel 99 SE?), but regardless of whether any changes actually had been made at that time or otherwise, I found that there still were problems afterwards. Hence I have continued to assign unique identities to every pin/pad within every component, and I am still doing so. Regards, Geoff Harland. - Original Message - From: Darren Moore [EMAIL PROTECTED] To: 'Protel EDA Discussion List' peda@techservinc.com Sent: Tuesday, December 19, 2006 11:07 AM Subject: Re: [PEDA] Common component pads Hi Laurie, I am surprised that AD doesn't recognise `more than 1 pin with the same designator' and connect them altogether on the same net. seems a logical thing to do but then this IS Altium Not if it's a switch with the two pin 1's connected in the switch, its best to unique numbers for each pad IMO for what your doing. Regards, Darren Best Regards (Mr) Laurie Biddulph You are subscribed to the PEDA discussion forum To Post messages: mailto:PEDA@techservinc.com Unsubscribe and Other Options: http://techservinc.com/mailman/listinfo/peda_techservinc.com Browse or Search Old Archives (2001-2004): http://www.mail-archive.com/proteledaforum@techservinc.com Browse or Search Current Archives (2004-Current): http://www.mail-archive.com/peda@techservinc.com
Re: [PEDA] Octagonal Pads
still regard it as highly preferable for this issue to be rectified ASAP, but the provision of such a dialog box would at least address its gotcha aspect, and also advise users of the available workaround. i don't care a whit about gaining or losing altium's favor as i am a paying customer and as far as i am concerned they are working for me I sometimes wonder whether Altium's management are working for anyone other than themselves, as some of their actions could be regarded as being hostile to the interests of their customers, their shareholders, and their employees. If I was to take a charitable attitude though, they probably really don't appreciate just how and why they have let all of those stakeholders down on various occasions. and yes they should have fixed this octagonal pad issue or killed it long ago, i don't think it is even offered as a possibility anymore, is it ? If support for pads having an octagonal shape was ever withdrawn, it probably wouldn't be regarded as a loss by anyone who has never used such pads. OTOH, people who have used such pads (and I have, on some occasions (in conjunction with some extra steps and precautions)) could be expected to have a very different view though. I am definitely not hostile to the provision of the relatively new Rounded Rectangular shape for pads, but what I still do find objectionable is Altium's willingness to provide new features or functionality while failing to rectify serious defects associated with existing features and functionality. And in a number of cases, new features have resulted in regression in previously provided features, and typically because the new features have not been properly thought through. And for the same reason, and/or manifestly inadequate testing, newly provided features have themselves often left a lot to be desired as well (and regardless of/over and above their impact upon previously provided features). While making changes to how new functionality and features are developed and implemented could potentially result in them being provided at a slower rate than has been the case to date, I still think that there are far too many cases of defects which should never have been shipped to users in the first instance, and which have all too frequently still not been rectified in a timely manner after users subsequently discover them (and sometimes only after being bitten by such defects). And while there are probably a number of users who wouldn't regard the issue involving pads with an octagonal shape as being a top priority issue, and another complicating factor is that it would be highly desirable (if not essential) to make some other changes at the same time (or else beforehand) as well, I am still of the view that this particular issue should still be rectified ASAP. Failing that, the dialog box which I described previously should be implemented on an ASAP basis instead, in order to at least mitigate the impact of that defect. Regards, Geoff Harland. You are subscribed to the PEDA discussion forum To Post messages: mailto:PEDA@techservinc.com Unsubscribe and Other Options: http://techservinc.com/mailman/listinfo/peda_techservinc.com Browse or Search Old Archives (2001-2004): http://www.mail-archive.com/proteledaforum@techservinc.com Browse or Search Current Archives (2004-Current): http://www.mail-archive.com/peda@techservinc.com
Re: [PEDA] Octagonal Pads
what the software thinks is the dominant Design Rule. Such mismatches can often be attributed to user-error, but it is still not out of the question that such mismatches could sometimes be attributed to software error instead. But regardless of whether any such mismatch can be attributed to user error or to software error, there is still a good case for previewing the contents of output files, and especially the Gerber files specifying the details on the Internal Plane, Paste Mask, and Solder Mask layers. And while I am not currently aware of how things are looking in that regard within AD6, there have definitely been various issues in previous (major) versions which have had an impact upon the contents of those layers. At one stage there were two distinct bugs within the AD 2004 version whose interaction could (and in at least one case actually did) result in (bottom side) solder paste stencils being mis-manufactured. One of those bugs was rectified before the release of SP4, while the other bug was not rectified until after SP4 had been released. As SP4 was the last SP to be released for AD 2004 though, that other bug is still present within AD 2004, and in some circumstances can still bite the unwary. (For users of AD 2004 to avoid being bitten by that bug, they need to ensure that *every* surface mount pad within a PCB file is *truly* Simple in nature. And it is *not* suitable to invoke the properties dialog box for each such pad to check whether they really are Simple; it is instead necessary to display the properties of such pads while using the Inspector Panel or List Panel instead. If they subsequently find any Bottom (copper) Layer pads which are *not* Simple, the values of each such pad's X-Size, Y-Size, and Shape properties on the Bottom layer need to be copied to the corresponding properties on the Top layer *and* (very important) to the corresponding properties on the Mid layer. And if they find any Top (copper) Layer pads which are *not* Simple, those pads should be temporarily moved to the MultiLayer layer, then their Padstack Mode property set to the Simple value, then their Layer property restored to the Top Layer again; doing that is actually more straightforward than copying (the X-Size, Y-Size, and Shape) property values from the Top layer to the Mid and Bottom layers.) Regards, Geoff Harland. - Original Message - From: John Echols [EMAIL PROTECTED] To: Protel EDA Discussion List PEDA@techservinc.com Sent: Wednesday, November 29, 2006 8:48 AM Subject: Re: [PEDA] Octagonal Pads All of the board houses we use send me pdf files of each layer for an OK before they proceed. I can look for any obvious D-code mistakes and any special shapes I made to see if they came through as expected. John Echols -Original Message- From: Terry Creer [mailto:[EMAIL PROTECTED] Sent: Tuesday, November 28, 2006 2:26 PM To: [EMAIL PROTECTED]; 'Protel EDA Discussion List' Subject: Re: [PEDA] Octagonal Pads In addition to this, as I work at a manufacturer, I'm sure we'd be more than happy to do a check-plot of the artwork onto film for the customer to check the outputs prior to manufacture. Far cheaper than 'suck it and see' board runs. -Original Message- From: [EMAIL PROTECTED] On Behalf Of Dan Enslen Sent: Wednesday, 29 November 2006 6:58 AM To: 'Protel EDA Discussion List' Subject: Re: [PEDA] Octagonal Pads Good Afternoon All, I am not in the same position here as most, and I have absolutely no experience with Gerber readers, but it seems to me that it would be quite easy these days to make a prototype run to check out any radically new or questionable PCB structures. Granted, the monetary resources may prohibit this in a lot of cases. Just my 2 cents worth. Dan Enslen The only reason time exists is so everything doesn't happen all at once. You are subscribed to the PEDA discussion forum To Post messages: mailto:PEDA@techservinc.com Unsubscribe and Other Options: http://techservinc.com/mailman/listinfo/peda_techservinc.com Browse or Search Old Archives (2001-2004): http://www.mail-archive.com/proteledaforum@techservinc.com Browse or Search Current Archives (2004-Current): http://www.mail-archive.com/peda@techservinc.com
Re: [PEDA] Octagonal Pads
Good Afternoon All, I am not in the same position here as most, and I have absolutely no experience with Gerber readers, but it seems to me that it would be quite easy these days to make a prototype run to check out any radically new or questionable PCB structures. Granted, the monetary resources may prohibit this in a lot of cases. Just my 2 cents worth. Dan Enslen The only reason time exists is so everything doesn't happen all at once. As I mentioned in another message to this thread, I would strongly suggest that *everyone* designing PCBs should acquaint themselves with at least one application which can preview Gerber files (and NC Drill files), and furthermore, that they subsequently preview those files for *every* PCB which they design before despatching any files to any board house. Even learning (just) how to use the CAMtastic server would be beneficial in that regard, though I still think that it would be preferable to learn how to use at least one third-party application (for additional peace of mind). I wouldn't regard it as necessary to also have an understanding of the contents of Gerber files and NC Drill files, though having that knowledge would definitely not be harmful (and could even be beneficial in some circumstances, such as if, shock/horror, there are still any outstanding bugs affecting the contents of Gerber files). And users who do learn how to preview Gerber (and NC Drill) files are not only less likely to have PCBs mis-manufactured from then on (for whatever reasons), but would then also be able to gamma test any new functionality while avoiding the costs of having any prototype PCBs manufactured. (For those who weren't previously in the know, alpha testing involves in house testing of an application, while beta testing is testing conducted by selected end users. Thus gamma testing is testing conducted by end users, and frequently has pejorative connotations. It is regarded as best practice that comprehensive alpha testing be conducted to detect as many bugs as possible, and in the absence of compelling reasons to the contrary, that all bugs detected at that time be rectified prior to releasing any files to beta testers. And when beta testers detect any bugs, they should similarly be customarily rectified before any files are subsequently (publicly) released to end users. However most applications are so complex that even the combined efforts of alpha testers and beta testers are unable to detect every bug afflicting them, and hence there is nothing atypical about end users discovering yet more bugs. That said, there are still substantial differences between applications which have been developed according to best practice as just described, and applications which have not...) Regards, Geoff Harland. You are subscribed to the PEDA discussion forum To Post messages: mailto:PEDA@techservinc.com Unsubscribe and Other Options: http://techservinc.com/mailman/listinfo/peda_techservinc.com Browse or Search Old Archives (2001-2004): http://www.mail-archive.com/proteledaforum@techservinc.com Browse or Search Current Archives (2004-Current): http://www.mail-archive.com/peda@techservinc.com
Re: [PEDA] Octagonal Pads
approach in some circumstances. That said, I think that that approach still has something going for it in at least some situations, though it would of course be even better to have the P-CAD feature provided in which customised shapes can be specified on each layer as required. Regards, Geoff Harland. You are subscribed to the PEDA discussion forum To Post messages: mailto:PEDA@techservinc.com Unsubscribe and Other Options: http://techservinc.com/mailman/listinfo/peda_techservinc.com Browse or Search Old Archives (2001-2004): http://www.mail-archive.com/proteledaforum@techservinc.com Browse or Search Current Archives (2004-Current): http://www.mail-archive.com/peda@techservinc.com
Re: [PEDA] Tips on using Protel 99 SE
to keep all pads which are *not* on the MultiLayer layer to be of a Simple nature (i.e. to have the Uses Padstacks checkbox *not* checked), as/but extra care and work is required to rectify any such pads which are *not* on a Top Side layer. And unless you specifically want different properties on different layers, pads on the MultiLayer layer should also similarly be made Simple. I have determined relatively recently that there is a bug in how MultiLayer pads are depicted within printouts within which you want the properties of such pads on the Top layer or Bottom layer to be depicted, as the properties of such pads on the *Middle* layer are *always* depicted instead... There are still many other aspects where there are differences between the 2.8 and 99 SE versions, but I would now be struggling to recall them and/or to find the time to describe them. However I have an idea that one of the other members of this mailing list has prepared a FAQ which can be downloaded from somewhere, and while it wasn't specifically written with the objective of advising users moving from version 2.8 to 99 SE, the information within it could still be of interest and value to you. Hopefully whoever did prepare that FAQ is *still* a member of this mailing list, and can either advise you of where to download it from or else provide you with a copy, but otherwise maybe some other member of this list might be able to assist in that regard. I have also created two addon servers which provide additional functionality for the Schematic and PCB servers, which can be downloaded from the protel-users mailing list hosted by Yahoo Groups. Only members of that mailing list can download those files though, but if you are not a member of that list and are still interested, I could send you copies of those servers. (I would also like to update those servers to provide yet more functionality, but it is a case of finding the time to do so, and especially to update and provide the associated documentation.) Regards, Geoff Harland. You are subscribed to the PEDA discussion forum To Post messages: mailto:PEDA@techservinc.com Unsubscribe and Other Options: http://techservinc.com/mailman/listinfo/peda_techservinc.com Browse or Search Old Archives (2001-2004): http://www.mail-archive.com/proteledaforum@techservinc.com Browse or Search Current Archives (2004-Current): http://www.mail-archive.com/peda@techservinc.com
[PEDA] Tips on using Protel 99 SE (was: Advanced PCB V2.8 Libraries)
their Resources, to wit, menu entries, toolbar buttons, and shortcut keys. A tip from my personal experience is that if you want to define shortcut keys which can start commands in the middle of other commands, then *don't* define any such shortcuts which (also) use the 'Alt' key, and *don't* define any such shortcuts which use either the 'F9' or 'F10' key (and regardless of whether or not any other keys, such as the 'Shift', 'Ctrl', or 'Alt' keys, are also used at the same time). - Users can also define and subsequently run scripts which can perform various tasks on an automated basis. And at one time it was also possible for users to be provided with SDK files (if they were prepared to agree to a NDA) which permitted them to create their own addon servers (if they also had a copy of Delphi 5) to provide yet more customised functionality. (I don't know if you would ever be interested in doing that, and I also don't know whether Altium would still be prepared to provide those files to anyone. As far as I'm concerned though, they *should* still be prepared to provide those files to bona fide owners of Protel 99 SE, even if they do so without also providing any support to anyone actually using those files.) It is not out of the question that you were already aware of at least some of the items on the above list, but as Altium no longer provide support for Protel 99 SE, *this* mailing list is effectively the predominant means of ongoing support for that particular version. There are assorted bugs in Protel 99 SE, some of which are of a gotcha nature. To avoid one such gotcha which I am specifically aware of, *all* pads which incorporate holes should reside on the MultiLayer layer, as any such pads which are *not* on that layer do *not* auto-generate blowouts (aka antipads) on any of the Internal Plane layers. And to avoid another not-unrelated gotcha, it is also advisable to define a Power Plane Connect Style Design Rule with a No Connect Rule Attribute which specifically applies to *all* pads with a False Plated property, because without such a Design Rule being defined, you risk an outcome in which the software will attempt to connect some of those pads to Internal Plane layers (by Thermal Relief and/or Direct connections). (You should probably define a Pad Class whose members consist of all such pads, and then specify that particular Pad Class as the set of objects which that particular Design Rule then applies to.) Also bear in mind that DRC (Design Rule Checking) procedures should not be treated as gospel, as aspects involving Internal Plane layers are not as well analysed as they could be, and pads with a False Plated property are regarded as unroutable (which can be a real pain if you ever really do want to route connections to such pads). There are many other things which I could say about Protel 99 SE, but hopefully what I have said will still give you a good start, and don't hesitate to ask if there are any aspects for which you would like to have answers provided. Regards, Geoff Harland. Hi Geoff, I got this to work. I had to Import the file. Took me awhile to figure out how to get a blank DDB set to accept it. I think I have it now, in 99SE library format. Thanks, -Bob Hi Bob, You *should* be able to open an AdvPcb 2.8 Pcb Library file in Protel 99 SE, as I tried this just a minute ago, and had no problems. You might need to specify, however, that the file concerned is a *PCB* Library file, and *not* a *Schematic* Library file, as both types of files use the same extension (.LIB) in all versions of Protel up until Protel 99 SE. In the Explorer window, right click on the icon provided for the file, then select Properties from the popup menu. Then select the PCB Library Document item within the resulting Properties dialog. If you still have problems opening that file, I could have a go at attempting to open/update it for you if you like, so you could attach a copy of the file concerned within a private message sent to me. (Naturally I wouldn't disclose any details of the contents of that file to anyone else.) Regards, Geoff Harland. [EMAIL PROTECTED] Hi, Is there any way to read AdvPCB V2.8 libraries into 99SE? The manual says you can add them but when I try I it says the format is unrecognized. I would really like to acess these footprints. Thanks, -Bob You are subscribed to the PEDA discussion forum To Post messages: mailto:PEDA@techservinc.com Unsubscribe and Other Options: http://techservinc.com/mailman/listinfo/peda_techservinc.com Browse or Search Old Archives (2001-2004): http://www.mail-archive.com/proteledaforum@techservinc.com Browse or Search Current Archives (2004-Current): http://www.mail-archive.com/peda@techservinc.com
Re: [PEDA] Advanced PCB V2.8 Libraries
Hi Bob, You *should* be able to open an AdvPcb 2.8 Pcb Library file in Protel 99 SE, as I tried this just a minute ago, and had no problems. You might need to specify, however, that the file concerned is a *PCB* Library file, and *not* a *Schematic* Library file, as both types of files use the same extension (.LIB) in all versions of Protel up until Protel 99 SE. In the Explorer window, right click on the icon provided for the file, then select Properties from the popup menu. Then select the PCB Library Document item within the resulting Properties dialog. If you still have problems opening that file, I could have a go at attempting to open/update it for you if you like, so you could attach a copy of the file concerned within a private message sent to me. (Naturally I wouldn't disclose any details of the contents of that file to anyone else.) Regards, Geoff Harland. [EMAIL PROTECTED] Hi, Is there any way to read AdvPCB V2.8 libraries into 99SE? The manual says you can add them but when I try I it says the format is unrecognized. I would really like to acess these footprints. Thanks, -Bob You are subscribed to the PEDA discussion forum To Post messages: mailto:PEDA@techservinc.com Unsubscribe and Other Options: http://techservinc.com/mailman/listinfo/peda_techservinc.com Browse or Search Old Archives (2001-2004): http://www.mail-archive.com/proteledaforum@techservinc.com Browse or Search Current Archives (2004-Current): http://www.mail-archive.com/peda@techservinc.com
Re: [PEDA] Netlist import choke
Has any one else had problems with importing netlist into all DXP products. Specifically, importing large netlist with 2000 -3000 components. The first time the netlist imports, DXP chokes so bad that it locks up. The method I use to get around it is to extract the components as a separate netlist. I import the components in first then reload the original netlist with nets back in. I have seen this pretty consistant across DXP SP2 to AD6. and have used several different computers. Is any one else using other programmed netlist? The reason I have to use these netlist is because I have Cadance and Orcad customers. Thanks Mike Reagan I have never encountered any problems of that nature myself, but then I don't think that I've ever worked on any PCB file containing so many components. However your experience does indicate that there is almost certainly some type of issue when it comes to loading really large netlist files, so if you haven't formally reported your experience already, you should do so (and if possible, also provide an example of a problematic netlist file). (Some members of Altium's staff do monitor the messages sent to this mailing list, but they won't necessarily act upon any defects which are reported just here.) As the customary way (since Protel 99 SE) to effectively load the data within netlist files is by synchronising the PCB file to its associated schematic file(s), it is likely that the code for loading netlist files is long in the tooth, and as such, it is not implausible that only one 65,536 byte block of memory has been provided for that particular task (harking back to the days of earlier versions of Windows, when such memory limits really did exist in some circumstances). It is certainly fortunate that you are able to load just the components during a first pass and then load the netlist information during a subsequent pass, and I will keep that workaround in mind just in case I ever experience similar problems myself. So while I can't really help you with this particular matter, I still appreciate you informing everyone of that workaround. Regards, Geoff Harland. You are subscribed to the PEDA discussion forum To Post messages: mailto:PEDA@techservinc.com Unsubscribe and Other Options: http://techservinc.com/mailman/listinfo/peda_techservinc.com Browse or Search Old Archives (2001-2004): http://www.mail-archive.com/proteledaforum@techservinc.com Browse or Search Current Archives (2004-Current): http://www.mail-archive.com/peda@techservinc.com
Re: [PEDA] Many similar Sheet Symbols
following SP6 for Protel 99 SE did not permit users to re-sequence the sequence of printouts within a set of printouts, which was painful if you wanted to create a PDF file within which the sequence of all layers (including non-copper layers) matched the sequence of layers within the PCB file (as resequencing the sequence of printouts within a set of printouts *was* possible in Protel 99 SE). And yet another example: the Find Similar Objects feature was (and still is?) less user-friendly in implementing global editing (than with the previously provided expanded dialog boxes), as it didn't (and still doesn't?) provide users with the ability to specify that only free primitives should be selected by that feature, while excluding primitives which are child objects of components or polygons.) Almost enough for a day. One last thing though: Is Altium Designer still polluting the RS-274X standard? In one of the SPs released for AD6 (which I don't have a copy of, so I can't answer this myself), the release note claimed that octagonal pads are now correctly depicted within Gerber files for all angles. My experience has been that octagonal pads have *never* been correctly depicted within Gerber files for *any* angle, so my initial inclination was to say oh oh. To test whether the pollution is still occurring, place just one pad in a PCB file, with an Angle (Rotation) property of zero degrees, equal X-Size and Y-Size values (e.g. 60mil), and an Octagonal Shape property. Generate a Gerber file from that PCB file, and check whether the pad which is depicted within the Gerber file appears the same as the pad within the PCB file. If the RS-274X standard is still being polluted, the pad depicted within the Gerber file will have two vertices on the X axis and another two vertices on the Y axis, so *none* of its (eight) edges will be either horizontal or vertical. (OTOH, the pad in the PCB file will have two horizontal edges and two vertical edges.) While enquiring whether Altium Designer still polluting the RS-274X standard could sound like I am asking whether somebody is still beating their wife, the fact remains that Altium Designer *has* been polluting the RS-274X standard in at least the past, even if it is not still doing so. Maybe things really have improved in that regard, but I first reported that there was an issue in this regard back in 1997, so *if* that issue has since been rectified, it has *only* been rectified some time this year. (Class performance, eh?) Regards, Geoff Harland. Hi Jakub, It's too bad that AD6 isn't a possibility for you, as a multi-channel design is *much* easier with AD6. Otherwise a lot of manual intervention is required. You might check out the multi-channel design demo's just to see what AD6 could do for you in this area: http://www.altium.com/webdemos/?p=10 http://www.altium.com/Evaluate/DEMOcenter/AltiumDesigneroverview/Multichanneldesign/ I don't recall 99SE auto-generating the sheets for you here, I think you had to copy/paste a sheet to make the new sheets. Then manually edit all of the ref des so there were no duplicates. Somewhat painful in 99SE. A piece of cake in AD. ---Phil Stevens GET AD6 :) it really handles this pretty well in 99SE there are methods but at the end of the day i found that you really needed the 20 separate sheets and getting them to all annotate nicely was a major pain the 'repeat' feature was what finally drove me to AD6 Dennis Saputelli You are subscribed to the PEDA discussion forum To Post messages: mailto:PEDA@techservinc.com Unsubscribe and Other Options: http://techservinc.com/mailman/listinfo/peda_techservinc.com Browse or Search Old Archives (2001-2004): http://www.mail-archive.com/proteledaforum@techservinc.com Browse or Search Current Archives (2004-Current): http://www.mail-archive.com/peda@techservinc.com
Re: [PEDA] Question about power planes
I think that somewhere there is a Fanout command provided with versions following Protel 99 SE, which can be used to route connections between surface mount pads and Internal Plane layers, but I'm not sure offhand if such a command is also provided with Protel 99 SE. (Check out the functionality provided by the autorouter?) In the event that such a command is not provided though, you would need to route such connections yourself. To connect each SM pad to an Internal Plane layer, you would need to add a track (on the same layer as each pad concerned) and a via (with the via located at one end of that track and the pad at its other end). Sorry if that sounds obvious, but that track and via *are* required, and regardless of whether you provide them yourself or whether they are otherwise provided by some command. (And unlike in versions before Protel 99 SE, vias *can* connect to Internal Plane layers; it is no longer necessary to use through-hole pads instead to connect to those layers.) Regards, Geoff Harland. - Original Message - From: Jakub M. [EMAIL PROTECTED] To: Protel EDA Discussion List PEDA@techservinc.com Sent: Monday, October 30, 2006 11:01 PM Subject: Re: [PEDA] Question about power planes I have put Split Plane polygons and assigned created regions to desired nets but looking at pins that should be connected to them (DGND for example) I don't see that they are; there are still gray lines indicating that those pins should be connected together... Geoff Harland napisał(a): Jakub M. wrote: [PROTEL 99] I want to create a power plane and a ground plane (split into analog and digital ground). How to connect SMD pins with appropriate plane? It doesn't connect automatically. When the appropriate layer has a closed boundary with lines, you can assign a net to this closed region and then it connects automatically to a pin placed to the net. Rene That is normally true in the case of post-Protel 99 SE versions. For versions up until Protel 99 SE though, it is necessary to place Split Plane polygons on Internal Plane layers in order to define regions on such layers within which the Net property differs from the default Net property for the layer concerned. Regards, Geoff Harland. You are subscribed to the PEDA discussion forum To Post messages: mailto:PEDA@techservinc.com Unsubscribe and Other Options: http://techservinc.com/mailman/listinfo/peda_techservinc.com Browse or Search Old Archives (2001-2004): http://www.mail-archive.com/proteledaforum@techservinc.com Browse or Search Current Archives (2004-Current): http://www.mail-archive.com/peda@techservinc.com
Re: [PEDA] PEDA
- Original Message - From: Leonard Gabrielson [EMAIL PROTECTED] To: peda@techservinc.com Sent: Sunday, October 29, 2006 11:00 AM Subject: [PEDA] PEDA test And a big pity that Altium doesn't do more of it, and in a more comprehensive manner. Regards, Geoff Harland. You are subscribed to the PEDA discussion forum To Post messages: mailto:PEDA@techservinc.com Unsubscribe and Other Options: http://techservinc.com/mailman/listinfo/peda_techservinc.com Browse or Search Old Archives (2001-2004): http://www.mail-archive.com/proteledaforum@techservinc.com Browse or Search Current Archives (2004-Current): http://www.mail-archive.com/peda@techservinc.com
Re: [PEDA] Library internal to Database
Scenario: snip Another issue involved with this, and assuming I can do this, how do I get all of the footprints/symbols used in a PCB or Schematic to point back to the local library made using Make Library under the design tab, rather to other libraries located elsewhere which may have been used originally. snip JaMi JaMi, FYI (For Your Information), I would be very very wary about using the Make Library command. As is regrettably typical for Altium's software, that command is buggy in that some of the properties for various types of primitive objects (such as a user-specified value for a pad's or via's Solder Mask Expansion, as just one example) are not properly copied (from the source component within the PCB document file to the target footprint within the PCB Library file). And I have personally had a gutsful of encountering components whose associated footprints had been created by the use of that command - which can be deduced from the offset of such components' insertion points from where they could reasonably have been expected to have been located. I have been working on an addon server for Protel 99 SE which will create a decent PCB library file from a PCB document file, with the intention of making this available for all interested users. As of yet I haven't figured out how to change the name of the PCB library file which is created by that server (or how to change the name of that file and then add primitives to it afterwards), but if the worst comes to the worst and I can't figure out how to do that, users would arguably still be a lot better off, as it is not unduly difficult to manually rename that file - and certainly a lot less bother than having to check and rectify the insertion point of each footprint within the PCB library file, and the properties of each primitive within each footprint within that file. Time permitting, I ultimately hope to provide another two processes within the same server to export a PCB library file to an ASCII format file and to import such a file back into a PCB library file again. (Users can save schematic document files, schematic library files, and PCB document files in either a binary format or an ASCII format - but PCB library files can only be saved in a binary format, so this addon server would similarly provide, to the maximum possible extent, an ASCII format for PCB library files as well.) I don't think for one minute that Altium's software is totally bad - but what is indisputable is that the software which has been provided to users has not been tested anywhere near as well as it should have been, and that it is all too common for truly serious bugs to not be rectified forthwith (quite apart from, and over and above, the fact that such bugs shouldn't have been present within any publicly released software in the first instance). Regards, Geoff Harland. You are subscribed to the PEDA discussion forum To Post messages: mailto:PEDA@techservinc.com Unsubscribe and Other Options: http://techservinc.com/mailman/listinfo/peda_techservinc.com Browse or Search Old Archives (2001-2004): http://www.mail-archive.com/proteledaforum@techservinc.com Browse or Search Current Archives (2004-Current): http://www.mail-archive.com/peda@techservinc.com
Re: [PEDA] Library internal to Database
JaMi, My responses interleaved with yours. Geoff, see below JaMi - Original Message - From: Geoff Harland [EMAIL PROTECTED] To: Protel EDA Discussion List PEDA@techservinc.com Sent: Thursday, October 05, 2006 8:00 PM Subject: Re: [PEDA] Library internal to Database Scenario: snip Another issue involved with this, and assuming I can do this, how do I get all of the footprints/symbols used in a PCB or Schematic to point back to the local library made using Make Library under the design tab, rather to other libraries located elsewhere which may have been used originally. snip JaMi JaMi, FYI (For Your Information), I would be very very wary about using the Make Library command. As is regrettably typical for Altium's software, that command is buggy in that some of the properties for various types of primitive objects (such as a user-specified value for a pad's or via's Solder Mask Expansion, as just one example) are not properly copied (from the source component within the PCB document file to the target footprint within the PCB Library file). Never had a problem here, providing the component was done correctly to begin with. Not all of the properties are afflicted in the manner which I described - but newer properties (i.e. post Protel 3/Protel 98 properties) are all (or else mostly) afflicted as I described; the properties concerned include (True) Tenting, Testpoint_Top, Testpoint_Bottom, (customised) Solder Mask Expansion (pads and vias), (customised) Paste Mask Expansion (pads), and (True) Keepout (arcs, fills, and tracks). If you have not used such property values though, then you probably wouldn't have encoutered those shortcomings. And I have personally had a gutsful of encountering components whose associated footprints had been created by the use of that command - which can be deduced from the offset of such components' insertion points from where they could reasonably have been expected to have been located. I have encountered a problem here, but not as you describe. What I have encountered is that when I copy a component from one library to another, the resultant component ALWAYS has its reference point at the center of PIN 1, irrespective of where the reference point of the original component was. In other words, if the original component reference point was in the center of the footprint, the copied footprint will have the reference point at Pin 1 of the component, and this can cause problems wit the design, in the event something is UPDATED. Yes I have found that myself as well in recent times - yet another instance of regrettably sloppy code. As such, the smart thing to do of course is to correctly set the origin of the copied footprint (and immediately after it has been copied). snip My real problem is that I have a completely seperate library of footprints which I have modified from the original P99SE footprints, mostly by making the component outline thinner and smaller (occupying less real estate), as well as defining most components on a real useable grid, such as 5 mil. All of these components usually have the same name as their original counterparts, so the trick is to have my replacement library first in the list of libraries. What I really want to do is reference my library only, and reference it as being internal to the .ddb database file. Problem is that if I am doing this for a customer, the library with a path on my machine will not work on his machine, unless I can find some way to make it simply default to the local .ddb file. You touch apon an issue that I have thought of, but seems to be too much work to even try, and that is to save the database as an ASCII file and edit the file path in the ASCII Database, such that it is just a default link, beginning only with \. May try that if all else fails. JaMi Speaking personally, I always use the ASCII format for .DDB files, as I don't care for the idea of schematic and PCB files, etc being embedded within database files. (I also think that it is a major pain of Protel 99 SE that a PCB or schematic (etc) file can't be opened directly in it and can only be opened after opening a .DDB file that owns the file concerned.) But if a PCB library file (for instance) and an ASCII format .DDB file which owns that file are both placed in the same folder, then the PCB library file concerned can effectively be opened from any folder after its parent .DDB file has been opened in Protel 99 SE (assuming of course that both of those files actually do reside in the same folder). Regards, Geoff Harland. You are subscribed to the PEDA discussion forum To Post messages: mailto:PEDA@techservinc.com Unsubscribe and Other Options: http://techservinc.com/mailman/listinfo/peda_techservinc.com Browse or Search Old Archives (2001-2004): http://www.mail-archive.com
Re: [PEDA] Location of Hole Size Editor
Where is the Hole Size Editor located in the menus? I can't remember where it is. I am using Protel 99SE SP6 Hopefully Hole Size Editor is what it is called. I will describe what I am trying to do and you can correct me on what I am trying to find. I have some 30mil and 35mil holes on my board that I would like to change to 29mils and 36mils. I know there is an editor that you can bring up that lists all of the different hole sizes on the board and you can select the different hole sizes and edit them. If I can't find the editor then I will probably use the Hole Selector which is located under the menu 'Edit/Select/Hole Size...' Trentino I believe that was an add-on published by a contributor to this list. You might try searching the archives (probably the pre-2004 archives, IIRC). I've got a file that looks to be a copy of it, dated 2000-04-07, though that was probably the date I downloaded it. Email me off-list at HxEngr at Alltel dot Net if you want to try a copy of that. Steve Hendrix Try the menu entry of 'Edit Hole Size Editor...' If, for whatever reason, there is no such entry in your menu, the HSEdit:Run Process should be invoked (without any parameters) in order to run the Hole Size Editor. As is regrettably not uncommon (for Protel 99 SE, and both preceding and succeeding versions), my recollections from using that particular editor are that it is not totally bug-free, so remain alert when/if you actually do use it. I suspect that Steve could have been referring to a macro/script which I wrote for Protel 99 SE (and which I uploaded (some time back in 1999 or 2000) to the Files section under the [protel-users] mailing list hosted by Yahoo Groups). It could be used to *select* particular pads and/or vias (depending upon the sizes of their holes), but by itself, it wouldn't *change* the values of any properties of the subsequently selected objects (other than their Selected property) - so if you did use it, you would still need to (subsequently/also) use global editing commands to actually change the sizes of their holes. As such, you probably really would be better off using the Hole Size Editor instead, which is able to change the sizes of the holes within pads and/or vias as required. Regards, Geoff Harland. You are subscribed to the PEDA discussion forum To Post messages: mailto:PEDA@techservinc.com Unsubscribe and Other Options: http://techservinc.com/mailman/listinfo/peda_techservinc.com Browse or Search Old Archives (2001-2004): http://www.mail-archive.com/proteledaforum@techservinc.com Browse or Search Current Archives (2004-Current): http://www.mail-archive.com/peda@techservinc.com
[PEDA] Mechanical layers (was Re: 99SE PCB Component gone afar.)
is of such a fundamental nature though that it is very unlikely that it would be implemented with the release of any SP; it would be far more appropriate to do that with the very first version of a new major version. Hence it is very regrettable that this was not implemented in AD6, and as such, users should collectively insist that this be implemented with the next new major release (as not having that implemented at that time either would almost certainly result in having to wait until at least the next major release following that one). Regards, Geoff Harland. [EMAIL PROTECTED] Hmm... Everyone has a standard for THEIR use of mech layers. Mech layers are, by default, not specified, for the specific reason that they are open to use by a given tecnician or engineer at the technician or engineer's discretions, aside, of course, from employer mandates... The idea is that they are amorphous, ie, unfixed in their assignment. Otherwise, we would call them board outline, PCB documentation 1, contour route layer, etc. In fact, they were provided for that very reason. Engineers (and technicians) were tired of being told what layers were to be used for what purpose all the time by an EDA vendor, when all they were really doing in the first place was providing a subset of a 2D CAD program, and so we repeatedly requested a group of layers which WE could control to OUR liking. Much like the annoyance that comes about from having proggies like PCAD demand that we choke on their auto-specified ref-designators, having some brain-dead person require our use of layer X to satisfy their concept is intellectually offensive to those of us who have to use our creativity (ie the reason you're not still using tape and mylar). I guess what I'm saying is this...Please don't give the moron management team at Altium another stupid excuse to take control back again. aj Augh. I use mech 2 for the board outline, and mech 3 for the enclosure details. Anyone have a standard for mech layers ? Dean Carpenter Yep, Mechanical Layer 3 has always been the default for board outline, Keepout layer (of course) for the keepout and Mechanical Layer 14 for any documentation such as special pcb material etc. Best Regards (Mr) Laurie Biddulph You are subscribed to the PEDA discussion forum To Post messages: mailto:PEDA@techservinc.com Unsubscribe and Other Options: http://techservinc.com/mailman/listinfo/peda_techservinc.com Browse or Search Old Archives (2001-2004): http://www.mail-archive.com/proteledaforum@techservinc.com Browse or Search Current Archives (2004-Current): http://www.mail-archive.com/peda@techservinc.com
Re: [PEDA] Converting Very Old Protel V3 PCB Files
snip SE takes in my old 2.8 files. If you wish send me one of your files off line and I'll try to open it in 2.8. Regards, Jim McGrath Note that while Protel 99 SE satisfactorily opens files that were created using AdvPcb 2.8 (AFAIK), there *can* be problems if you attempt to open AdvPcb 2.8 files in Altium Designer 2004 (and I suspect the previous and succeeding versions (of DXP and AD6 respectively) as well). So if you want to go from AdvPcb 2.8 to Altium Designer, it would definitely be preferable to resave the file(s) using Protel 99 SE as an intermediate step. Regards, Geoff Harland. [EMAIL PROTECTED] You are subscribed to the PEDA discussion forum To Post messages: mailto:PEDA@techservinc.com Unsubscribe and Other Options: http://techservinc.com/mailman/listinfo/peda_techservinc.com Browse or Search Old Archives (2001-2004): http://www.mail-archive.com/proteledaforum@techservinc.com Browse or Search Current Archives (2004-Current): http://www.mail-archive.com/peda@techservinc.com
Re: [PEDA] Protel compatible manufacturer files
While the provision of the ability to import assorted types of file formats is not devoid of merit, I would personally suggest that Altium should at least ensure that it *properly* supports all of its native file formats. *Maybe* things have been fixed since then, but with AD4 SP4, there definitely were issues with saving a PCB (document) file in ASCII format, and reopening such files again (after they had been closed). *None* of the properties of any Embedded Board Array objects (such as their XRowCount and YRowCount properties) contained within PCB files were specified within ASCII format (PCB) files - meaning of course that all such objects were *not* restored (at all) whenever such files were subsequently reopened. There were also issues with non-classic Dimension objects; Embedded objects were used to specify some of the details associated with each such object - but the strings specifying the values of those Embedded objects typically contained non-Notepad friendly characters. This meant that if you opened an ASCII format PCB file in Notepad, made one or more legitimate changes to the contents of that file (such as changing the value of a free object's Layer property, as one illustrative example), saved that file (in Notepad), then reopened that file in Altium Designer, then there was a good chance that the non-classic Dimension objects in the file would either be corrupted or else missing in action altogether. But wait, there's more. :-) and :-( Whenever an ASCII format PCB file was reopened, a dialog box was invoked at the time prompting the user to specify the locations of the PCB's border. The associated details *are* in fact saved to the file in a satisfactory manner - but they were (and still are?) *not* being reloaded properly afterwards (and hence the dialog box at that time). That aspect *had* been fixed at one stage, but was subsequently reincarnated. (Hint to Altium: The set of regressive tests run after each new build should include at least one instance of opening an ASCII format PCB file. If the border of the PCB can't be restored without drama at that time, then the subsequent invocation of the dialog box will result in each such particular test failing - and hence signal if there currently is a problem with ASCII format PCB files in this regard.) It would perhaps be excusable if there were issues associated with importing (or exporting) files of a third party nature, because there could be translation issues in such circumstances. But there is no excuse for not being able to save Altium-created files in ASCII format and then reopen them afterwards (and without issues). This situation encapsulates many of the issues concerning Altium Designer in general. There are many instances of functionality being provided which are nice or sometimes even useful to some extent, but which are still not of a core or critical nature - but at the same time, functionality which really is of a core or critical nature is sometimes significantly compromised. A case could be made that new features and functionality need to be provided with at least new major versions (though they are also often provided in service packs as well) for marketing reasons (and regardless of how useful such enhancements really are in practice). That said, I genuinely believe that failing to rectify issues and shortcomings which *really* matter, or reincarnating formerly rectified issues, or other instances of regression, definitely undermine marketing (and sales) efforts. It is possible to spend so much time debugging and polishing an application that it is either never released at all or else is only released in an untimely manner. The evidence suggests that Altium could be very close to the *other* extreme of quantity, not quality, and when there are significant delays between service packs or major versions, it could be because the source code is so buggy that any changes made to it need to be followed up by rectifying bugs that were created (or else uncovered) as a consequence of the previous changes. It would perhaps be understandable if Altium was operating in an extremely competitive commercial environment, in which any delays in going to market could result in a loss of market share - but as it is arguably *not* operating in such an environment (and is subsequently far less subject to such pressures), it would be prudent for it to at least tend to the core and critical functionality in a satisfactory manner, to avoid the outcome of fouling its own marketing efforts (and cash flows). Will they take this feedback on board? Who knows? Some people (and companies) excel at hearing what they want to hear (rather than what was really said)... Regards, Geoff Harland. [EMAIL PROTECTED] Stephan If you can not find Protel compatible files and OrCad files are avaliable, you can always read the Orcad files. I recently downloaded a series of Samtek footprints that were in Orcad. They imported with no problems
Re: [PEDA] Protel compatible manufacturer files
Hi aj, snip... and I'm surprised that Protel (and now Altium) hasn't gone a little further towards this end. One would think that the profits they've generated by doubling and then tripling the pricepoint for their EDA entry would easily absorb such a lost-leader to a literal handful of companies in payment for the long-term press they might receive as a result... (And I would not be at all surprised to learn that Orcad and the other HAVE implemented such investment strategies, to their long-term benefit) Altium have been running at a loss for a few years, I don't think most users realise this. Darren Altium seems to have real problems with understanding how their customers view their products, and how their customers view their attitude towards them. I recall a case of a user reporting shortcomings with the DRC procedures (for PCB files) - and he was *not* *just* complaining about shortcomings related to checking connections on the Internal Plane layers (which would be less than straightforward to fully implement, because of the negative nature of those layers), but about *other* shortcomings as well, which *shouldn't* be anywhere near as difficult to rectify. He suggested that a patch should be released on an ASAP basis, because of the critical nature of DRC procedures - but even after the following SP had been released, the issues which he had complained about still hadn't been rectified (and I strongly suspect *still* haven't been rectified). And I think that it is poor form to release files (and sometimes (sub)folders) which contain spelling mistakes, non-unique accelerator keys, menu entries *without* accelerator keys when they really *could* be provided, strings (in menu entries or within buttons in dialog boxes) which *don't* have a suffix of ... when they *should* (which suffix is used to indicate that a dialog box will subsequently be invoked), strings which *do* have a suffix of ... when they *shouldn't*, etc. I believe that users who see things like that have a good chance of wondering whether Altium is capable of writing satisfactory code for procedures of a complex nature, when the evidence suggests that they are not capable of properly handling tasks of a less demanding (and even relatively trivial) nature. Such users could wonder whether Altium is even capable of running a lemonade stand (or with less decorum, of organising a p*ss-up in a brewery, or of getting laid in a cathouse). I tried to rectify as many of those shortcomings as possible, but there was usually an element of pulling teeth when it came to actually making any changes to any of the associated files. When I first started at Altium, I had to go over the top of a then-fellow employee who didn't see anything wrong with assigning the 'Ctrl+P' shortcut key (in PCB files) to *both* invoking a printout from the (currently focused) PCB file *and* invoking a dialog box for configuring printouts (We arguably need an acronym of BMUS - for Beam Me Up Scotty.) (That shortcut key had been specified in a menu entry resource, and also in a toolbar button resource, and one of those types of resources always takes precedence over the other, so invoking that shortcut key would always have resulted in the same outcome. That said, it was still very bad form, as the text provided for any menu entry, and the bubble text displayed from any toolbar button (invoked after positioning the cursor over a button for an extended period of time), both include a reference to any shortcut key assigned to the associated resource.) I could continue, and maybe I will in following messages, but I'll finish for the time being by saying that another thing that they really don't seem to understand is that issues which (I think) should be rectified on an ASAP basis include those involving output (printouts, Gerber files, ODB files, BOM files, exported files, etc), DRC procedures, and gotchas. (One example of a gotcha is that when a pad incorporates a hole, and that pad is *not* on the MultiLayer layer, then blowouts are *not* provided for that pad on *any* of the Internal Plane layers. And there are others...) Regards, Geoff Harland. [EMAIL PROTECTED] You are subscribed to the PEDA discussion forum To Post messages: mailto:PEDA@techservinc.com Unsubscribe and Other Options: http://techservinc.com/mailman/listinfo/peda_techservinc.com Browse or Search Old Archives (2001-2004): http://www.mail-archive.com/proteledaforum@techservinc.com Browse or Search Current Archives (2004-Current): http://www.mail-archive.com/peda@techservinc.com
Re: [PEDA] Protel compatible manufacturer files
I was wondering if anyone knows of any semiconductor companies that provide Protel ready models, footprints, and/or schemtic parts. If not, does anyone know why? I've put inrequest after request to no avail to folks like Texas instruments, Analog Devices, etc. Is Altium really such a tertiary player in the field that they are considered someone to be ignored, or is the format just such a pain that no-one wants to bother? Thanks, aj Do *any* of the semiconductor companies put out symbol and/or footprint files for *any* of the CAD applications (for PCB design)? I gather that some companies provide SPICE files and/or 3D model files for at least some of their devices, but then standards have been defined for such files. OTOH, there are currently no standards (AFAIK) for specifying symbol and footprint files (for direct use by all CAD applications for PCB design). And how well known is Altium in the USA? It is not the only provider of CAD applications for PCB design, and any prominence which it has in that market has probably been building over an extended era, as opposed to having been prominent for some time. And Altium has never supported an ASCII format for PCB library files (and in spite of me requesting that for some time now), and it no longer supports an ASCII format for schematic library files either (though it did in previous versions up until Protel 99 SE). Hence the absence of support for ASCII format library files, and the absence of any generic standard for such files, means that any semiconductor company would *have* to have a licence for Altium Designer to be able to produce any library files. Altium has sometimes provided copies of their products to various educational institutions on either a free or discounted basis, but I am unaware of whether they have also done so with any semiconductor companies. And while acquiring a copy of Altium Designer at its standard price (to the extent that there actually is a standard price) wouldn't break the bank of any semiconductor company, it is not implausible that such companies think that if Altium wants them to create library files for their devices, then they should be provided with a copy of AD on the house. My two cents worth anyhow, but I would be interested in hearing what anyone else has to say on this matter. Regards, Geoff Harland. [EMAIL PROTECTED] You are subscribed to the PEDA discussion forum To Post messages: mailto:PEDA@techservinc.com Unsubscribe and Other Options: http://techservinc.com/mailman/listinfo/peda_techservinc.com Browse or Search Old Archives (2001-2004): http://www.mail-archive.com/proteledaforum@techservinc.com Browse or Search Current Archives (2004-Current): http://www.mail-archive.com/peda@techservinc.com
Re: [PEDA] Snake Oil vs Pricing
to Having said that, I currently surmise that not paying the maintenance fee would (merely) result in users losing the ability to download the latest SPs. That type of change would, of course, *not* be as drastic as changing to leased licences - but for all that, I still consider that most (if not all) users would believe that if they purchase an application which is of a buggy nature, then they are entitled to be provided with *free* SPs to rectify its bugs, or at least the most offensive of those bugs. For some time though, SPs have contained a mix of bug fixes and new features (and the new features haven't always been bug free - and typically are buggy). It would be one thing to effectively pay for new SPs if the application was bug-free, so that the SPs subsequently contained *just* new features - but most of us know that Altium's products (like most applications for that matter) are *not* like that (i.e. bug-free). While new SPs customarily contain *some* bug fixes, there is nothing atypical about bugs of a truly serious and/or obnoxious nature (such as those impacting upon output generation and DRC checking) enduring for SP after SP after SP - and even after succeeding new (major) versions. And to make matters even worse, SPs have sometimes been regressive to some extent, in that bugs which *had* been fixed in a previous SP have sometimes been reincarnated in a following SP, or else functionality which had previously been provided has sometimes been down-graded, or broken, or otherwise gone missing in action, in a following SP. IMO, to expect users to pay for such service would be adding insult to injury. (Or should that be vice versa?) So perhaps somebody in Altium has (since) figured out that seeking to impose a maintenance fee upon users would not be a good idea, and it has since been dropped. If, however, that fee is for real, then I think that users would have a very good reason to resist it - and even that they *should* make every effort to oppose it. So does anyone else have anything to say about this matter? (For the record, I currently have a licence for AD4 (SP4), but don't have a licence for AD6, and I'm not currently intending to upgrade.) Regards, Geoff Harland. [EMAIL PROTECTED] You are subscribed to the PEDA discussion forum To Post messages: mailto:PEDA@techservinc.com Unsubscribe and Other Options: http://techservinc.com/mailman/listinfo/peda_techservinc.com Browse or Search Old Archives (2001-2004): http://www.mail-archive.com/proteledaforum@techservinc.com Browse or Search Current Archives (2004-Current): http://www.mail-archive.com/peda@techservinc.com
Re: [PEDA] Are there really no PEDA archives past OCT 13 2004?
Just went to the PEDA (Tech Serve) archives and tried to find an old post that I knew the reference(s) for, only to discover the archives seem to stop on Oct 13 2004. Is this true or am I missing something on the archive page? Brad Velander Hi Brad, If you haven't figured it out already, try looking at the details appended to each message (as repeated below). snip Browse or Search Old Archives (2001-2004): http://www.mail-archive.com/proteledaforum@techservinc.com Browse or Search Current Archives (2004-Current): http://www.mail-archive.com/peda@techservinc.com Regards, Geoff Harland. You are subscribed to the PEDA discussion forum To Post messages: mailto:PEDA@techservinc.com Unsubscribe and Other Options: http://techservinc.com/mailman/listinfo/peda_techservinc.com Browse or Search Old Archives (2001-2004): http://www.mail-archive.com/proteledaforum@techservinc.com Browse or Search Current Archives (2004-Current): http://www.mail-archive.com/peda@techservinc.com
Re: [PEDA] ARRRGGGHHHH 99SE SP6 can not manual route NET
If all else fails, try cutting or copying a short track (on the Top layer) into the clipboard, and then paste (a copy of) that track (from the clipboard) onto a pad located on the same layer. Hopefully you will be able to subsequently route from the other end of that track (or at least while Single Layer Mode is selected) without the problems that you are encountering while attempting to route from the pads instead. I can't guarantee that this will work, ... but it might. Regards, Geoff Harland. Hi all, This is my stupid fault but... I have a over crowded PCB, I have a section (filters) where I have components top and bottom of the PCB, they are identically aligned ie if you look through the board, the other side is shadow of the side viewed from. The problem is that I am getting a net from the other side when I want to route one side, in this case I am trying to route the top, but I am grabbing a bottom net :( I have tried selecting the net, selecting all the components pads on the net, using single layer mode, turning the bottom layer off, all to no avail, I think this is due to the pad centers being 100% in allingment? Any ideas how to do this, or do I need to move all the components off the same centers ??? -- Regards, Kat. You are subscribed to the PEDA discussion forum To Post messages: mailto:PEDA@techservinc.com Unsubscribe and Other Options: http://techservinc.com/mailman/listinfo/peda_techservinc.com Browse or Search Old Archives (2001-2004): http://www.mail-archive.com/proteledaforum@techservinc.com Browse or Search Current Archives (2004-Current): http://www.mail-archive.com/peda@techservinc.com
