At 03:42 PM 3/15/01 +1100, Ian Wilson wrote:
>We seem to be locking horns today ;-)

If one does not lock horns every so often, they become ingrown. :-)

>On 05:58 PM 14/03/2001 -0800, Abd ul-Rahman Lomax said:
>>It's important to realize that CAD programs may be thoroughly checked for 
>>bugs, but when they hit the real world, they may be fed data that was not 
>>anticipated and therefore the behavior of the program has not been tested.
>Abd ul-Rahman, I have a problem with the manner in which you are 
>expressing things in your post?
>Are you saying it is OK to introduce a bug in a new version of software 
>that did not exist in a previous version?

I don't think I said that. But I do say that when one introduces new 
features to a program, it goes with the territory that bugs may be created 
that did not exist before; or program behavior may change in a way that is 
not technically a bug but which might as well be if one was relying on an 
undocumented feature.

>There is a bug.  Drill file does not match Drill Drawing = BUG.

Definitely. I don't know why Mr. Wilson would think I would not agree with him.

My point is that if one is using a program in a non-standard way, the 
probability of running into a bug is greatly increased. It's reality, and I 
don't think that it will change in the next hundred years.

>Protel allows holes in surface pads *but* doesn't mark those holes in the 
>Drill Drawing.  The program does however recognise that a hole should be 
>drilled there (it is in the drill file).  So there is a bug.  Drill file 
>does not match drill drawing = BUG.  No excuses or discussions on this, surely.

I prefer to look for causes and remedies than to try to assign blame. 
"Excuses" imply an assignment of blame. Essentially, some programmer failed 
to anticipate every consequence of what was being done, and someone testing 
the software failed to test a particular aspect of its operation.

I can't do *anything* about either of these factors. But I *can* do 
something about how I use a program and what I expect of it. If I am doing 
something which pushes the envelope, it behooves me to very carefully check 
my output. What I have said is that a surface pad with a hole is pushing 
the envelope. It's a rare beast and thus has seen little testing.

>   This bug did not exist in previous versions of PCB so the argument 
> about real-world data is a bit facetious - I think that after all this 
> time Protel could reasonably have realised that non-zero sm holes were 
> used in the field.  If they wish to change this then making the drill 
> files erroneous is hardly a sensible method.

How then, was the bug created? Mr. Wilson, does any one of us think that a 
Protel software engineer *wanted* to make the program behave as he has 
described? If he did, and if it were discovered that he did, I assume that 
he would be out of a job. No, I think that no one even dreamed that this 
bug would be introduced. And we did not discover it in beta test, I 
suspect, though I'm not certain about that.

>I think:
>1) Protel should make sure the drill drawing and the drill file match, 
>exactly.  I would consider doing this by generating the drill file 
>internally and using the results to make the drill drawing.  The same 
>process would be used for both then - no code synchronisation issues at all.

Good idea. Good ideas are common in hindsight.

>2) Protel should consult on what, if anything, should be done about 
>continuing to allow/not allow non-zero hole sizes to be entered.

Certainly we agree on that. I give my opinion, and I hope that others give 
their experience, insights and opinions; Protel should value discussion 
that bring out the various ways that users will use the programs and what 
ideas they have for improving it. We will differ, often. It is Protel's job 
to decide which way will be best, though we might assist them in certain 
ways where we can come to some kind of consensus.

>In order not to break existing designs Protel *must* maintain support for 
>non-zero hole sizes in surface pads but there could be appropriate DRC 
>warnings.  New versions of the software could prevent accidental entry of 
>non-zero hole sizes in surface pads by, as you say, greying out the hole 
>size edit box, in the Change Pad dialog, if the layer is not multilayer.

I do think that we agree on the solution. If a surface pad has a zero hole, 
grey out the hole size edit box so that one may not make it non-zero. If 
one edits a multilayer pad to surface, set the hole size to zero 
immediately. It might be courteous to give a message that this has been 
done. However, if a surface pad exists that has a non-zero hole, allow it 
to remain and also allow copying and editing of the hole size until and 
unless it has been set at zero.
And fix the drill drawing/drill file routines.

If all this is done, there would be the occasional user who would run 
headlong into a brick wall and then complain that we put the wall there. We 
would then inform this user that it was done for good reason, and if he 
*must* work around it, here is how. Basically, "Here is a file with a 
surface pad with a hole in it. You can copy this pad and edit all its 
features to whatever you want. But you would be better advised to use a 
through-hole or a pad/via combination (the latter in the case of 
via-in-pad, which I think will become standard practice eventually when 
hole-plugging becomes common).

Alternatively, however, one might simply put a warning in the DRC that 
lists such pads. Or something in between this and the more controlling 
solution first suggested.

Abdulrahman Lomax
P.O. Box 690
El Verano, CA 95433

* * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
* To post a message: mailto:[EMAIL PROTECTED]
* To join or leave this list visit:
*                      - or email -
* mailto:[EMAIL PROTECTED]?body=leave%20proteledaforum
* Contact the list manager:
* * * * * * * * * * * * * * * * * * * * * * * * * * * * * *

Reply via email to