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 
that structure.

>  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 
last long.

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 
problems fixed?

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 
since then.)

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.

[EMAIL PROTECTED]
Abdulrahman Lomax
P.O. Box 690
El Verano, CA 95433

* * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
* To post a message: mailto:[EMAIL PROTECTED]
*
* To join or leave this list visit:
* http://www.techservinc.com/protelusers/subscrib.html
*                      - or email -
* mailto:[EMAIL PROTECTED]?body=leave%20proteledaforum
*
* Contact the list manager:
* mailto:[EMAIL PROTECTED]
* * * * * * * * * * * * * * * * * * * * * * * * * * * * * *

Reply via email to