On 03:43 PM 29/04/2002 -0700, Mira said:
>Brad,
>Thank you for your polite reply.

Nicely put. Brad - are you being harsh?  There are legitimate userbility 
issue in Protel that are well worth discussing even though many of us 
experienced users are so familiar with them that we may loose sight of 
other ways of doing things.

I for one would quite like the net to be an attribute of a sch wire (to 
facilitate some global operations across sheets on wires).  But it does 
rather break some aspects of Protels current manner-of-use and so would 
need really careful thought.

><..snip..>
>PCAD2001 places the refdes automatically. If you have
>R1 and R3, next time when you place R it will name it
>R2... then R4 and so on.

Protel will step net lablels, pin numbers and ref des numbers when there is 
a numeral last in the relevant text.  It will not fill in unused windows.

So if you have placed a resistor R3, then the next one will be R4.  When 
placing items you can hit the TAB key to bring up the properties for that 
object.  You can then set the ref des as you wish, continuing to place more 
of the same component type will step on the ref des numerals.  This 
auto-assisted ref des incrementing suits me as I sometimes like to group 
ref des by circuit block, leaving gaps to allow for additional components 
as the design matures.

Does PCAD force re-use of ref des "windows"? This is something I would not 
like.  When we remove a component we try hard not to re-use that ref des to 
reduce the chance of production errors. We also like to group ref des by 
function often.

>I didn't want especially to duplicate part names. I
>just placed one and then I saw there was another one
>with the same name but this makes me wonder what will
>happen If I have multiple pages and the same component
>names. To be checked!

ERC can trap duplicate ref designators.  And many other errors - it is well 
worthwhile making *full* use of ERC including taking the time to set up the 
electrical type of the pins in schematic libraries to facilitate the best 
possible ERC.

><..snip..>
>Now about the net label placed on top of two wires...
>I saw that the net label has kind of a ref. point.
>Obviously when this point touches the wire it assigns
>this name to the wire. It seemed to me but now I'm
>sure this ref. point acts as a junction if placed on
>top of two wires, which are crossed but not really
>connected.
>
>    |netlabel3
>---o---
>    |

You are correct and this is a limitation of Protels net labelling 
scheme.  You can ameliorate this situation by naming explicitly (with a net 
label) as many nets as practical and then ERC is more likely to pick up the 
duplicate net labels.  Placing net labels in consistent locations to reduce 
the chance of a long wire running across a sch causing a stray net label 
"connection" is helpful.  A visual check for unclear net label placement is 
important - but a clear, good looking, sch will have this anyway.

A related issue that Protel should have fixed a long time ago is the 
joining of co-linear wires.  Wires in Protel remain as placed.  If you 
place a small section of wire and then at some time later come back and 
extend that by placing another wire (rather than stretching the existing 
wire), the join between these two in-line sections remains - the wires are 
not merged.  This join is now an auto-junction hot spot.  So if someone 
runs a track across this hotspot a junction dot will be added (assuming 
auto-junction is enabled - see more on this below), so creating a possibly 
incorrect circuit.  This is a bigger failing in Protel than the placement 
of the net label in my opinion.

A note on auto-junction: The auto-junction is a system, not document, level 
attribute (Tools-Preferences).  This means the attribute does *not* travel 
with the schematic.  So leaving stray auto-junction hotspots around a sch 
may be OK for some (if Auto-junction is off), but if that sch is given to 
someone else then a number of operations can cause the junction to be 
auto-magically placed, possibly in an area a long way from where one is 
working, and so easily missed.

It is very disappointing to me that this issue remains in Protel years 
after it being made clear to Protel/Altium that is was a problem.  Merging 
co-linear wire segments is not hard and many low end sch packages have it.

Mira,  it has been years since I used another ECAD package in anger so I am 
not a good judge.  However, there are many that successfully use Protel for 
high-end high quality work, so it can be done.  Which package is best - 
sort of like asking which religion is best, or which OS is best.

Good luck,
Ian Wilson

* * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
* To post a message: mailto:[EMAIL PROTECTED]
*
* To leave this list visit:
* http://www.techservinc.com/protelusers/leave.html
*
* Contact the list manager:
* mailto:[EMAIL PROTECTED]
*
* Forum Guidelines Rules:
* http://www.techservinc.com/protelusers/forumrules.html
*
* Browse or Search previous postings:
* http://www.mail-archive.com/proteledaforum@techservinc.com
* * * * * * * * * * * * * * * * * * * * * * * * * * * * * *

Reply via email to