At 12:43 AM 4/3/2002 +1000, Geoff Harland wrote:

>I understand what you are saying, but I do wonder how much space you want
>while you are moving items about; after all, 100 inches by 100 inches is a
>pretty big area :) (i.e. much much larger than any PCB which I am ever
>likely to be called upon to design).

The issue is not the size of the workspace, though if one were working at a 
finer scale, for example 10:1, that 100 inch workspace could becomoe a tad 
tight. Why would one want to work at scale? Well, Protel gets a little 
flakey somewhere in the micron region; definitely CAMtastic does. I have 
run into these limits on an MCM design, 2 mil track and space with certain 
structures needing to be a specific size and shape. Protel did generally 
work here, and gerber provides adequate resolution, but CAMtastic was 
useless, it seems to have been designed for the mil region, not much below.

I've worked with Tango DOS, which had a 32 inch workspace; I never had 
occasion to need larger. But I recall my frustration when I could not place 
a block because some element of the block was outside the workspace. Sure, 
I'd like a warning. But I might want to place the block, then bring the 
wayward parts into the workspace. I can do that with Protel.

Frankly, I'd rather see Protel remove the workspace limitations, at least 
for some aspects of the program. It stores the coordinates, why not allow 
display? If it is necessary -- for speed, perhaps -- to keep active 
primitives inside the workspace, still, since it allows them to exist 
outside, why not go further; if there are aspects of the program that would 
be too difficult to reprogram, one already has the problem of having to 
filter the input; what is needed is a warning to the user that the results 
are not reliable. Most notably, DRC. But it is silly that Protel cannot 
recognize a pad outside the workspace as being unconnected!

>IMO, there are pros and cons to having the ability to move items outside the
>100" x 100" "kosher" workspace. If prohibited, user-created macros would
>then have to contend with the possibility that their invocation would move
>one or items outside that area, which could result in complications.


>  OTOH,
>it is not always obvious when items are outside this area, so that is the
>drawback to not prohibiting this.

Much, much easier to simply warn the user when a primitive is created or 
moved outside the workspace, and to report such primitives in DRC. The last 
is the most important, and the easiest to implement.

* * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
* To post a message: mailto:[EMAIL PROTECTED]
* To leave this list visit:
* Contact the list manager:
* Forum Guidelines Rules:
* Browse or Search previous postings:
* * * * * * * * * * * * * * * * * * * * * * * * * * * * * *

Reply via email to