At 09:18 AM 3/15/01 -0800, Brad Velander wrote:
> Abd-ul Rahman how can you define a single layer pad with a hole as
>pushing the envelope? I have used this type of design in at least three CAD
>packages over the years and extensively in P98, all successfully. So where
>is it defined that this is pushing any envelope?
What I am saying is that defining a "surface pad," an entity which in its
conception was without a hole, as having a hole, is pushing into a
territory that may not have been as thoroughly tested and debugged as might
a more normal entity.
Using a multilayer pad to accomplish the same thing would be much safer.
The issue is not the PCB structure, but how one uses the program to produce
> With each and every CAD
>package there are operations which are not clearly and defined as do-able or
>not do-able. We all know there are 101+ things to do with a dead cat. So we
>try them, if they work they are do-able, if they don't work they are not
>do-able. P98 it was do-able, P99SE it is not do-able, but it also generates
>flaky output data so it is a P99SE bug.
First of all, I'd remind Mr. Velander that the use of undocumented features
of a program is subject to exactly this hazard: the next version might not
support it. That risk exists with *documented* features, but the risk is
much higher when the feature is one that is not anticipated by the
programmers. That really ought to be obvious.
There is a bug here, definitely. No way should the drill drawing fail to
match the drill file. It should be impossible to create a PCB that would do
that. That such an error exists shows a certain weakness in the program
conception; apparently what should be the same process, at least in the
first steps, has been implemented in two different ways. That is sloppy
programming, for sure. But in a software project the size of Protel 99SE,
there is bound to be some sloppy programming. One could spend ten times
what Protel spends on programming and still have some problems like this.
> I don't think that this bug was introduced intentionally, not at
>all. However the response that I got, supposedly forwarded from a
>development team member, was ludicrous. It simply stated that this was not a
>bug because single-layer pads should not have a drill or else they are not
>single layer pads. If the use of a through hole in a surface mount pad is to
>not be allowed from P99 forward then there is still a bug because the output
>data does not synch.
Right. But Mr. Velander is focusing on a misstatement by a Protel
development team member. It was not ludicrous, however, it was merely
short-sighted or incomplete as a response. That the program might not
support SMT pads with holes is not a bug. That it allows such primitives
and then does not process them correctly is a bug. He was addressing the
first issue, not the second.
> There are so many bugs (or if you like, programming oversights) in
>Protel that you can drive a semi-trailer through. And the type of response
>that I got demonstrates why these bugs exist. The development team members
>do not take responsibility for their code and Protel does not take full
>earnest responsibility for their product.
As one might imagine, I have a different view of this. It is not that what
Mr. Velander is saying is false; but rather it is, in my view, misdirected.
We all make mistakes, and there is no existing software company that "takes
full earnest responsibility for their product." Or if there is, it will not
I would also note that Protel does not openly reveal its internal
processes, and one cannot judge those processes by a comment from member of
a development team. For all we know, that person is no longer at Protel. Or
perhaps he is still there because he is a better programmer than he is a
customer relations person. There are reasons for Protel's secrecy;
historically, things were worse. In any case, what the programmer (assuming
that a "member of a development team" is a programmer) wrote was, within
its limits, not incorrect. It was merely incomplete, as I noted.
> For example: Why does Protel allow component footprint names which
>exceed their stated name length or contain illegal characters. Then when you
>use a name with illegal or excessive characters the program fails during
>some mundane operation. Not only that but they do not inform you of these
>illegal characters and only state the name limitation on one page of the
>documentation in a very obscure area, no where near the library editing or
>part creation areas.
These too are bugs and documentation shortcomings. They should be fixed. It
should be *impossible* to enter illegal data into a field. I think we all
agree on that. Let's focus on fixing the problems, rather than on trying to
blame the programmers who did a good, if incomplete, job **overall**. Do we
think that metaphorically yelling at the programmers is going to get the
Some of these problems have existed for a long time. I think that we can
support Protel in fixing these things if we speak with a coherent voice
about them. Protel has made certain choices about its priorities. We might
not like all those choices, but we certainly like *some* of the
consequences of them, or we'd be using a different CAD system. (I know that
some readers are forced to use Protel by their employers, so this does not
apply to them. But I and many writers on this list actively chose Protel at
a point where we did have choices, and I, for one, chose Protel when I knew
that it had a reputation for bugs. The positive values of the program
outweighed the bugs; and Protel has definitely improved in reliability
In order to present a coherent voice, we need some level of organization.
That's why the other lists have been started, in particular
[EMAIL PROTECTED] Not everyone wants to participate
in such things, or we would do it all here. But I expect that whatever the
association decides, it would be announced here for comment, etc.
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:
* mailto:[EMAIL PROTECTED]
* * * * * * * * * * * * * * * * * * * * * * * * * * * * * *