On 3/7/2012 10:34 AM, Steve Adam wrote: > Hi, > > I meant to reply to this the other day, to make a couple of quick points. > > On 05/03/2012, at 1:11 PM, rickman wrote: >> I had seen that, but it doesn't fix my problem of the drill files not >> having proper tool size spec. > What is the status of your problem? Do you need any help with anything?
Sorry, I thought I had made it clear that I no longer have an issue that needs to be resolved. I was just referring to the problem that got me started on this conversation. At this point it is all just rhetorical. Although it might not be a bad idea to provide a means of editing the drill table after loading the drill file. The same way the file interpretation info can be entered when AUTO doesn't work. >> Yes, but it is still work to do the conversion or whatever they need to >> do. When someone sends me a PDF file I don't have to determine what >> size paper is was intended for or whether it is portrait or landscape, >> etc. I just open it in Acrobat or Sumatra or whatever I use for viewing >> PDF files. As an engineer it pains me whenever I see inefficiency >> especially when it impacts schedules or results. > A better example would be a comparison to the printing (publishing) industry. > If you want to publish a novel (or engineering manual) then what format do > you use? I bet there are lots of problems sending files if you don't use > exactly the same software as the printers/publishers. Not so long ago most > publishers would only accept manuscripts double spaced on A4 (or similar). Yes, the publishing industry has the same problem I suppose. But that is the point, it doesn't need to be that way if a standard can be agreed on. As you mention in your other email when companies who influence the market make a standard, it tends to stick (hence the Adobe PDF example). That is why we have Gerber files and Excellon files, even though they aren't the ideal, tool independent standard. >> I now know that a drill file should properly contain the tool sizes. >> But on the other hand as Steve pointed out neither the conventional >> Excellon drill files nor any of the routing file formats are truly >> appropriate for conveying drill or routing data unless it is intended >> for a particular machine. In reality there should either be a single >> standard for all machines (which ain't gonna happen) or some >> appropriate, independent standard should be devised. The Excellon >> format seems to be a defacto standard for drills, but none seems to >> exist for routing. The routing I have seen on PCBs appear simple enough >> to be conveyed by a Gerber file. > The point here is that sending hardware specific codes is a poor strategy. > The designer should only have to send a specification. It is up to the > manufacturer to convert that specification into whatever they need to operate > their factory to produce the specified boards. > > A rout file is a good example of this. You can't supply a useful rout file > unless you know what tool sizes are available at the factory. Yes, that is what I was trying to say, but you said it explicitly. The file between CAD machine and vendor should be a tool independent, machine readable description of the product result, not instructions on how to get there. Gerber files work pretty well since all the info you need (other than stackup and electrical connectivity perhaps) is in them or can easily be extracted. Excellon files are pretty good as well except that many produce variations on the theme and there is no real spec on how to produce a "correct" Excellon file unless you are using it on an Excellon machine. That is why so many drill files have to be manually tweeked. >> In their defense I read a web site that explained why, after more than >> one attempt had been made to define a new standard for PCB etching >> patterns which could include all of the other information important for >> making PCBs, the industry sticks with Gerber files. Basically it comes >> down to the fact that many of the errors in Gerber files are errors in >> usage (which is not an adequate reason in my opinion) and that the >> learning curve would not be without its own errors resulting in >> significant short term costs. In many ways the current system is the >> "devil we know". > Importing Gerber format is a bit like trying to create a document by > importing a PDF. It can probably be made to work most of the time but a PDF > file could just be one big bitmap which would be difficult to import. I'm not sure why you say this. Isn't the Gerber format a pretty good way to specify the copper on a PCB? Isn't a bitmap what you are trying to get in order to make the board? I guess you are saying it can be hard to import to Gerbv? Rick ------------------------------------------------------------------------------ Virtualization & Cloud Management Using Capacity Planning Cloud computing makes use of virtualization - but cloud computing also focuses on allowing computing to be delivered as a service. http://www.accelacomm.com/jaw/sfnl/114/51521223/ _______________________________________________ Gerbv-devel mailing list Gerbv-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/gerbv-devel
