| Author |
 Topic  |
|
rwconcepts
United Kingdom
23 Posts |
 Posted - 02 Dec 2009 : 16:26:36
|
I previously reported a Gerber file problem which related to a design where Cu Pour areas on different layers were incorrectly connected to a signal via thereby creating a short. On the EPC view all appeared OK and all DRC checks were passed but the Gerber files were generated wrongly.
This was recognised as a bug and apparently fixed. However with a new design which has just been manufactured, the same problem has occurred again. This time there are multiple faults and the boards are a write-off (together with my £1500). The design and Gerber files are with Support who are no doubt urgently looking into why the fix wasn't a fix at all.
Until they've come to a conclusion, I must warn everyone that the Gerber output files could be suspect and, as has happened in my case, very expensive through no fault of my own. Examine the gerber files very carefully i.e. every via, if Cu areas are included in the design before committing to manufacture. Let's hope Support can reply quickly with some useful information.
Roger |
|
|
Iain Wilkie
United Kingdom
1015 Posts |
Posted - 03 Dec 2009 : 12:44:55
|
I put out gerbers on more or less a daily basis and have never had any problems like this. I also use copper pour extensively. However it is always a pre-requiste to view generated gerbers before sending to the pcb manufacturers.
Also the manufacturer we use also checks gerbers (to make sure it fits their process), and normally would report back if they saw anything suspect such as floating vias.
Iain |
 |
|
|
rwconcepts
United Kingdom
23 Posts |
Posted - 03 Dec 2009 : 13:24:38
|
I've used EPC for nearly 6 years and had never come across the problem before. However it's real.
I view the Gerbers before sending them for manufacture but didn't look at every via on all layers. My boards are typically 10 - 16 layers, 1500 - 3000 holes.
The manufacturers I use also check the Gerbers but this error is simply a legitimate via that's been wrongly connected to a Cu area on a particular layer(s). The BBT netlist is generated from the Gerbers so the BBT is passed post manufacture. The problem lies with EPC where the Gerbers and the design within the software are not the same.
Roger |
|
|
|
Iain Wilkie
United Kingdom
1015 Posts |
Posted - 03 Dec 2009 : 19:54:18
|
Ok, this does sound worrying. I know its not a fix, but if there was some way of generating a netlist from the generated gerbers to directly cross-check with the EPC netlist, then at least this would give an extra level of check, and give a bit more confidence.
Iain |
|
|
|
rwconcepts
United Kingdom
23 Posts |
Posted - 03 Dec 2009 : 20:56:58
|
It certainly would and Support have mentioned that a capability of some sort like this is on the wish-list for the future. Shame it's needed though as we should be able to trust the Gerber output. I used to.
Roger |
|
|
|
Iain Wilkie
United Kingdom
1015 Posts |
Posted - 04 Dec 2009 : 11:38:55
|
Roger,
It is obviously an impossible task to manually check each via on a complex multi-layer pcb. So it is really important Numberone address this problem immediately, otherwise all confidence in the gerber generator will be lost. I have an 8 layer pcb going to manufacture on monday ... so now I am worried about this. Could you keep us all informed of the progress on this and any feedback you may get from Numberone.
Regards
Iain |
|
|
|
rwconcepts
United Kingdom
23 Posts |
Posted - 04 Dec 2009 : 15:17:36
|
Iain,
Sorry you've got a board lined up for manufacture with this hanging over your head. I sympathise.
As for feedback from WestDev, it's an accepted fault i.e. they've re-created it. Apparently it's been given a high priority to be sorted out ASAP. I suspect that, partly becuse I'm trying to get some reimbursement from them to offset the £1500 loss I've suffered because of this, they're actually saying this time it's a new fault. The fault back in July was fixed. The fault this time is different - it's in the Cu Pour code (like last time) and gives exactly the same effect ... but it's somehow different! How to lose credibility in 1 easy step eh?! I don't want to say too much on newsgroups at the moment as the negotiations on me getting some money back aren't complete but I find it absolutely hilarious that they feel it's good to say there were actually 2 faults in their software! Clearly far better than 1 fault!
Back to your situation Iain, a slightly low-tech but better than any other method to check the Gerbers is to double the number of layers and import the Gerber files (just the shapes, no pads) into these new layers. Then the EPC layer (shapes only) and corresponding Gerber version of that layer can be viewed together. By fiddling with the colours, the Gerber can be bright, the EPC layer dull and any errors will then appear. The bright Gerber (where there should have been a via) will be visible through the via hole in the EPC layer. Lots more work which you shouldn't have to do but it's a way forward. I hope this helps.
Have a good weekend.
Roger |
|
|
|
Iain Wilkie
United Kingdom
1015 Posts |
Posted - 05 Dec 2009 : 10:59:03
|
Roger,
Thanks for info ..... I did speak to Peter Johnson late on friday evening who confirmed this method. Hopefully there will be a resolution to this very quickly given the serious nature of the problem. I therefore think I will withhold our new layout until the problem is fixed.
Havinf experiance in programming myself I can appreciate problems like this arising, it is very very difficult to check all aspects of a program, especially when the "input" is practically infinately variable. Also sometimes a tweek to fix one part of a program can impact on a completely different part inadvertantly causing another problem.
All said and done the main this is that it has been spotted and can be replicated and so should take little time to find the cause and put it right. If anything this is what Numberone have been very good at in the past.
Just a thought ..... do you use the simple "plot viewer" in the output plotting dialogue to have a quick look at the gerbers ?.... I don't ..... I noticed once way back that somtimes this could cause scaling problems when the gerbers were output ....
Oh, and I do remember that in the past changing the line thickness for copper pour would sometimes cause/repair problems with copper pour areas within the EPC app .... wether this would have an affect on the gerber output I am not sure. I have now always set the line width for copper pour to 5 thou which seems to have worked well (so far !)
Iain
|
Edited by - Iain Wilkie on 06 Dec 2009 11:27:10 |
|
|
|
rwconcepts
United Kingdom
23 Posts |
Posted - 07 Dec 2009 : 13:27:10
|
Iain,
I hope you've made some progress getting your design out for manufacture by now. Getting confidence back when something like this happens is a slow process, if you bother at all.
As someone who's also written a fair bit of code over the years, I understand software bugs can occur and debugging can be difficult. This is why when this fault first appeared in July on a different design job, I didn't make a fuss and didn't feel so aggrieved. What annoys me is the fact that the fault was supposedly fixed when in reality it wasn't. That shows me they've really slipped up in this case.
I've not used Plot Viewer. To view Gerber output I use GC Prevue available from the Internet for free.
The line thickness is indeed a funny one. Like you I use a thin line in order to obtain the required level of detail. It's a very hit and miss thing with Easy-PC. My default is 0.05mm which has worked OK for some years - until now. Presumably they use a line based flood-fill algorithm for Cu Pour to boast fast fill speeds but at the expense of code complexity (and bugs).
Still no offer of any form of recompense from them for the £1500 they've cost me. How would you react if you caused a customer to lose this amount of money in the course of your business? Would you just say "hard luck mate"? Customer care eh?
Good luck.
Roger |
|
|
|
Iain Wilkie
United Kingdom
1015 Posts |
Posted - 07 Dec 2009 : 13:55:38
|
Hi Roger,
I am going to hold off our PCB going to gerber till this is fixed. I am not a lawyer, but it could be that Numberone are not responsible for "consequencial loss".... however the gerber output being wrong could be looked at as "un-merchantable product" in which case you would be due for a refunt of the cost of the product. However we are all in business and as such risk is a factor we all have to content with. I think Numberone should do the honourable thing since they have admitted there is a problem... and lets face it it is a very very serious problem.
My main concern is that they get this put right immediately so that we can all get back to work with confidence.
I would also like to see some input from Numberone in this thread.
Iain |
|
|
|
rwconcepts
United Kingdom
23 Posts |
Posted - 07 Dec 2009 : 15:10:41
|
Iain,
Thanks for your input. I agree with you.
Roger |
|
|
|
DavidM
United Kingdom
458 Posts |
Posted - 08 Dec 2009 : 14:02:07
|
Update 13.0.5 which includes the fix for this specific problem is currently in test and should be released to the web site later this afternoon.
As a bit of background information, Gerber data doesn't handle cutouts, so we have to post-process any shape that includes cutouts to build a 'jigsaw' of shapes that lie alongside each other, where each shape is a convex non-self-intersecting polygon. As you can imagine, the code for this is quite complex, and has to deal with many 'border' cases such as where a split between adjacent shapes runs tangential to an arc of a cutout, or grazes a very shallow line, and so on.
What we have here is two bugs within that whole module of complex geometry code that happen to end up with the same symptoms, unfortunately both affecting the same customer, but only in these specific cases out of the many hundreds or perhaps thousands of Gerber files that must be produced from Easy-PC every month.
As has been mentioned already in this thread, visual validation of the Gerber data can be done by reading the files back onto unoccupied layers lower down in the layer stack. This method was used to locate the position of the fault in this particular design to allow us to fix it, and then to verify the fix. In addition, as I mentioned earlier, we are also considering possible methods for an automatic validation.
David.
|
|
|
|
Iain Wilkie
United Kingdom
1015 Posts |
Posted - 09 Dec 2009 : 10:20:07
|
David,
So what was so specific in the design that showed the problem that would not have "normally" be in other designs using copper fill that would not have shown the problem ?. For example was it if the copper pour had curved edges, or a cluster of vias at a specific edge of the copper pour ?. I only ask so that we can understand if this was a unique instance. As you say it has not affected hundreds of other gerber outputs so there must have been a pretty specific situation for it to occur. Understanding the specific situation could create bit of comfort to users.
Iain |
|
|
|
DavidM
United Kingdom
458 Posts |
Posted - 09 Dec 2009 : 11:20:49
|
Perhaps my statement did have something of the 'self fulfilling prophecy' feel about it, but my general drift was that this area of the program is in constant daily use and if the issue was more general we would have seen many more instances of broken output.
The problem in this case happened where the breaking of the shape into separate pieces ended up at one particular point with line so short it had an indeterminate angle. Although this isn't really a lot of help in your search for a more 'secure' outcome for your Gerber files, it does point to areas to avoid such as tiny segments (straight line or arc) and extremely shallow angled lines. You can help avoid these to an extent in a design with adjacent poured areas by not pouring area A then B then A then B and so on. Each successive pour will 'notice' the true shape of the adjacent copper and you can sometimes see more and more tiny geometric artefacts appearing. Better to clear all the copper on a layer and pour it in one go.
As for post-process validation, we will be looking at what could be done in this area as I have already said. In the meantime it might be worth considering using ODB++ output instead of 'raw' Gerber, as the ODB++ data contains component and padstack definitions, and a net-list and other electrical information that allows for independent verification of the results in third-party CAM tools.
|
|
|
|
Iain Wilkie
United Kingdom
1015 Posts |
Posted - 09 Dec 2009 : 11:52:13
|
David,
Thanks for the info ..... personally within any design I clear ALL copper pours and then pour all areas at the one time automatically (doing a pour all) before generating gerbers. I assume this is perhaps been a method that has been helpful in this particular instance ?.
Starnge as it seems, no PCB manufacturer has ever asked for the info in ODB+++ even though we have offered it !.
Iain
|
|
|
|
rwconcepts
United Kingdom
23 Posts |
Posted - 09 Dec 2009 : 14:51:05
|
Iain,
Good points.
I always clear all then pour all when it comes to the Cu areas before doing the Gerber output. Didn't help with this bug.
Does the posting from David fill you with boundless confidence that you can't now go wrong with the Cu area Gerber generation?
Mmmm, me too.
Roger |
|
|
|
rwconcepts
United Kingdom
23 Posts |
Posted - 09 Dec 2009 : 15:01:42
|
David,
This forum seems to be the preferred method of communication so I'll put my message here.
Firstly, don't you think it would have been more professional and supportive of a customer to e-mail me directly that the fault (which I reported) had been fixed and a patch was available for download. True I periodically monitor this thread but it was only by chance that I saw your posting saying a patch was available.
Secondly, you must have used my design as a test vehicle for the software patch. Could you let me have the Gerber files please?
Thirdly, I e-mailed a reply on 4/12 to David Grinter's message to me regarding a good will gesture for screwing up my PCBs. No reply so far. Do you know if he got the message (sent to sales@...) and is he going to reply?
Regards,
Roger |
|
|
|
Iain Wilkie
United Kingdom
1015 Posts |
Posted - 09 Dec 2009 : 18:23:17
|
Roger,
I can see both sides of the argument here.
What I was trying to get at was .... it seems to have only been yourself that has come up against this particular problem, so I was trying to understand if there was something specific in your design that obviously does not exist in others (as there are no other reports). Had this problem not arisen, we would probably all be generating gerbers as we have done in the past, and most lilkely encountered no problems.
On the other hand, Numberone have obviously homed in on the particular set of circumstancies and put a fix in place relatively quickly (unlike a few other software products I have used and found bugs .. eg my accounting software.)
I think because of the complexity of the product and the fact it is revised on an annual basis, means there will always be bugs generated, unfortunately in your case it cost and hopefully you can resolve this with Numberone.
At the end of the day, the product can only become better and better as bugs are discovered and put right.
Iain |
|
|
|
rwconcepts
United Kingdom
23 Posts |
Posted - 11 Dec 2009 : 11:34:37
|
Iain,
The Cu areas in my design are not complex. The problem seems to occur if, by chance, there's a via in a particular place within the area. If there's a bug in software, the only sure thing is that it will cause a problem at some time. Who it will affect is pure chance.
As I said earlier, my real annoyance with WestDev is they allegedly fixed the bug when in fact they didn't. I appreciate software development can be problematic at times but a commercial product should be of a better quality than this. Still no reply from my last posting by the way - maybe they're trying the 'ignore it and it'll go away' approach now.
I hope you've tested your Gerber output and have your board manufacture underway at long last.
Roger |
|
|
|
rwconcepts
United Kingdom
23 Posts |
Posted - 11 Dec 2009 : 11:51:04
|
Iain,
Did you know the Gerber Import facility is a Cost Option? I've just got back to doing my design and need to generate and check the Gerber output for more errors using the technique that's been described. However it's apparently a cost option! I was still hoping for the Gerbers that Support will have produced whilst testing the software fix but nothing from them.
Another e-mail required.
Roger |
|
|
|
Iain Wilkie
United Kingdom
1015 Posts |
Posted - 11 Dec 2009 : 14:27:59
|
Roger,
Yes I did know gerber import was a cost option.... I automatically take these options so kinda forget that is the case .... but yoes that is a good point when considering the fix suggested which needs this option.
Our board has been held off till next wek now, but I will double check the output as described. As to your own position, it may be better to talk to support directly over the phone rather than on the forum.
Iain |
|
|
|
Peter Johnson
United Kingdom
499 Posts |
Posted - 11 Dec 2009 : 16:06:38
|
For those users who don't have the Gerber import cost option, an alternative would be to download a demo. It's enabled in there as you can't save the work, but it would be perfectly adequate for checking.
Regarding pour in general, all the 'easy' fixes for global problems were done long ago. Now the problems that appear tend to be very specific to one piece of geometry. There's no realistic way to test for an instance like this - the chances of hitting the right geometry are just too small. (That's why we need an example to be able to fix pour problems).
Problems where the pour looks good on screen, but goes wrong during Gerber creation are even less likely. If they do occur, the tendency is for them to be quite obvious to a casual inspection.
Roger has been extraordinarily unlucky in hitting two different subtle Gerber problems (and they ARE different, but presenting in a similar way), and especially within a short time frame.
It's because of the totally unpredictable nature of these faults that we're looking into providing some means of verifying the Gerber files against the original design as a final check. However, there's no obvious strategy for detecting subtle problems if they appear in the original design and aren't revealed by a design rule check. |
|
|
|
rwconcepts
United Kingdom
23 Posts |
Posted - 11 Dec 2009 : 21:11:28
|
Iain,
I hope the board goes OK. I post on this forum regarding the recent events to provide visibility to other users of how WestDev are handling my grievance. This thread has attracted over 150 reads in 9 days which shows the level of interest.
Roger |
|
|
|
rwconcepts
United Kingdom
23 Posts |
Posted - 11 Dec 2009 : 21:23:15
|
Peter,
Thanks for sorting out the Gerber Import question. I'm up and running now and will be using it to check the gerber output as previously described.
Regarding the original fault, I have to re-iterate that there has only ever been 1 fault. As I said to David Grinter, from a customer's perspective, what I saw in July was:
Vias being incorrectly connected to Cu pour areas.
The fault in November was:
Vias being incorrectly connected to Cu pour areas.
The fault is the same. It's irrelevant that it's in a different line of code in your software. I'd be interested to hear the views of other users regarding this.
The crux is that I was told in July the fault was fixed when in fact it wasn't.
Regards,
Roger |
|
|
|
olga
United Kingdom
107 Posts |
Posted - 14 Dec 2009 : 13:21:27
|
quote:
Originally posted by rwconcepts
The fault is the same. It's irrelevant that it's in a different line of code in your software. I'd be interested to hear the views of other users regarding this.
The crux is that I was told in July the fault was fixed when in fact it wasn't.
I have to say that, although the symptom was the same, if there are two lines of code which are wrong, they are different faults. One fault was fixed in July; therefore /that/ fault was fixed. It may be that the other fault couldn't come to light until the first one was sorted out, maybe not; without knowing the code it's impossible to say.
However, the base matter is there were two problems which just happened to cause you the same (wrong) output.
It would be like someone going to the doctor with a cough & the doctor saying 'you've got bronchitis' & giving you antibiotics. You go back later with a cough & this time he says 'it's because you smoke'. Both have the same symptom, but are caused by different problems!
Best wishes,
Olga. |
|
|
|
rwconcepts
United Kingdom
23 Posts |
Posted - 14 Dec 2009 : 14:45:06
|
Olga,
Thanks for your input. Iain and I were feeling lonely!
I think your analogy is a bit awry.
How about this instead? You go to the doctor with a cough and he says you have a chest infection. You get antibiotics and he tells you you're cured and OK to go back to work. In reality this is incorrect because you actually have 2 infections, one of which is untouched by the antibiotics and are still unfit to work. The doctor was wrong.
The analogy is poor in that you would realise you are still ill of course! In the case of software the faults are hidden.
In the EPC case, the fault was exactly (100%) the same in both cases both prior and after the July fix.
Any other inputs?
Thanks.
Roger |
|
|
|
Peter Johnson
United Kingdom
499 Posts |
Posted - 14 Dec 2009 : 15:42:43
|
Point taken. There's absolutely no way we can guarantee that an algorithm as complex as this isn't going to give wrong results from time to time. I believe no-one could. It's rather the opposite, in that we know it's almost certain that it will, but it's impossible to predict when. The best we can do is try to minimise the window for such events.
I still maintain that there were two faults. That the faults were in the same area of code and produced the same result doesn't remove the fact that there were two of them. The fault on your earlier design DID change with the patch so that the expected output was produced. The code which cured the earlier problem has failed to cure this one. Therefore they cannot be the same fault! QED.
Perhaps we've been lucky so far in that almost all previous instances have been readily detectable, but clearly that's not a guarantee. It's in recognition of this that we're now looking at other strategies to provide absolute confidence in the outcome. |
Edited by - Peter Johnson on 14 Dec 2009 15:49:16 |
|
|
|
rwconcepts
United Kingdom
23 Posts |
Posted - 14 Dec 2009 : 17:01:00
|
Peter,
The fact that the output changed in July looks more like a data-dependent fault which was got around for that particular design data only. It was never properly cured until (hopefully) this time around when it re-appeared with a new set of data. You can (and no-doubt will) maintain the 2 fault line as it suits your purposes. I maintain that from the customer POV trying to use the software for the purpose it is advertised as being fit for, the same fault reappeared i.e. vias were incorrectly connected to Cu areas.
Roger |
|
|
|
Iain Wilkie
United Kingdom
1015 Posts |
Posted - 17 Dec 2009 : 10:14:52
|
Eveen though the problem is meant to be fixed, I decided to double check using the gerber import outlined above. I find this almost completely unusable. I imported 6 inner layers to the design to check the pours on these, but the gerber always imports down in the bottom left hand corner of the working area and my deisign is in the centre trying to move either to lay on top of the other is impossible as the re-draw time is enormous and even then the app crashes nearly all the time. I tried using co-ordinates on the gerber import to change the position when importing, but this does not work either. I have stuggled for two hours with this and got nowhere ....... dispair is setting in !!
Iain |
|
|
|
MikeMillen
United Kingdom
10 Posts |
Posted - 17 Dec 2009 : 15:59:31
|
Just so you know you're not alone, I had a similar problem with copper pour shorting to an arc'd track on a board in September (Using 13.0.3).
It was reported to Peter.
I assumed it would be fixed in v13.0.4, but was not. I tried generating new Gerbers from the same design (with the arc'd track) but still got the pour running into the track.
I sent NOSL the relevant files as requested again at the start of December (from v13.0.4) but have heard nothing back since.
|
|
|
|
MikeMillen
United Kingdom
10 Posts |
Posted - 22 Dec 2009 : 08:28:42
|
| Update v13.0.5 has fixed the pour problem with the arc'd track. |
|
|
|
Topic |
|
Gerber file corruption