here is one about 99SE
maybe this is to be expected, i'm not sure, but it *almost* caught us 

the story:
we had a finished, released and working bd
for the next rev we unrouted all traces and moved some parts around to
new mechanical locations

the netlist did not change

we had a few 2 pin parts
the pads were numbered 1 & 2
for some good reasons which i will not go into
we renumbered 2 to 1 and 1 to 2

remember that the traces were all deleted

we then rerouted the board and it passed DRC

on final inspection the 1 & 2's were backwards compared to the schem
(Orcad sch, so no sync'r)

apparently since the pin 1 had previously acquired the net VCC after 
it became pin 2 it was still perfectly happy being on VCC and 
pin 2 was happy wherever it went even though the intent was otherwise

examining the netlist proved that the pin numbers did not match the
board
yet the DRC was fine which just shows that it does not walk the netlist 
pin numbers
maybe this is as it should be, i'm not sure
or maybe the DRC should take that extra step and resolve the pin numbers

a few cycles of clear the nets and load the nets resolved this but 
it would have been easy to release and it would have been AFU

in retrospect this should have all been obvious, 
i write it here as a word of caution so that others may not fall down
this hole
reload the netlist! reload the netlist!

a related side note about this:
when we went to re-load the netlist the correct file was in the drop box
we hit Execute and it did something or other and there were no changes
made

we did it a second time BUT used the Browse button to drill to the same 
file which was already listed and then it loaded a bunch of macros
and reversed the 2 pins

it does not seem to always need that extra step, just sometimes which is
a bit mysterious

Dennis Saputelli

vincent mail wrote:
> 
> Tony Karavidas wrote:
> 
> >It doesn't happen for me. I tried it with and without a component in focus
> >(w/o causes the inspector panel to be empty)
> >
> >I'll be very interested to hear how that one gets resolved for you. It's
> >funny, there seems to be two camps: the ones that don't get crashes and the
> >ones that do. I wonder what the dependencies are?
> >
> hold it . can't have anything on the schematic . has to be a new clean
> sheet file new schematic.
> 
> select the Navigator panel. and right click in the mid pane where it
> says components - information.
> 
> >
> >
> >
> >>-----Original Message-----
> >>From: vincent mail [mailto:vincent.himpe@;alcatel.com]
> >>Sent: Friday, August 02, 2002 7:07 AM
> >>To: Protel EDA Forum
> >>Subject: Re: [PEDA] Speaking of Protel Bugs.
> >>
> >>
> >>try this one for stability
> >>
> >>open new schematic
> >>open ispecotr  , right clik on the mid pane
> >>
> >>- access violation reading 0x00000004 every time. under win98 - protel
> >>99se your system would die. DXP on 2000 : close the box and continue . I
> >>have a memory sniffer and resource monitor open . it doesn't even 'leak'
> >>memory !
> >>
> >>
> >>
> >>Ian Wilson wrote:
> >>
> >>>On 04:09 PM 1/08/2002 -0500, Matt Pobursky said:
> >>>
> >>>>On Thu, 1 Aug 2002 14:20:07 -0400, Watnoski, Michael wrote:
> >>>>
> >>>>>Greetings all,
> >>>>>
> >>>>>   Another two cents:
> >>>>>
> >>>>>   Protel has been my biggest headache as far as crashes due to
> >>>>>upgrades of other programs.  I would expect that if Protel needed
> >>>>>
> >>>>specific
> >>>>
> >>>>>versions of .dlls to run, it should have written them and not used the
> >>>>>Microsoft versions that are likely to be updated on a regular
> >>>>>
> >>>>basis.  I am
> >>>>
> >>>>Actually, they should just put ALL their ancillary config files,
> >>>>required DLL's and such in the Protel owned and created directory.
> >>>>End of problem.
> >>>>
> >>>
> >>>Actually it isn't - at least until Win XP came along.  Pretty much
> >>>only one DLL of a certain name can exist in memory pre-XP.  Win XP now
> >>>allows different versions of a DLL to exist in memory (I think).  This
> >>>is the MS solution to DLL hell.
> >>>
> >>>>Again, not very defensive programming practices.
> >>>>
> >>>
> >>>Somewhat forced by the OS in this case but I agree that, at least
> >>>historically Protel products have not been very defensive.  But do
> >>>remember that the user community was split in 1999 as to whether the
> >>>application should trade speed for stability.
> >>>
> >>>Ian
> >>>
> >>>
> >>>************************************************************************
> >>>* Tracking #: 359C05030908664CBC51CCEC9FEA08FC302B19E6
> >>>*
> >>>************************************************************************
> >>>
> >>
> >>--
> >>-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
> >>     _____________
> >>    /____________/  Vincent Himpe
> >>   // _____  ___/   Lab Manager
> >>  / \ \   / /  /    ST Microelectronics
> >> /___\ \ / /  /     5510 Six Forks Road . Suite 200
> >>/______//_/__/      Raleigh NC 27612
> >>
> >>                    Tel : (919) 850 6070
> >>                    Fax : (919) 850 6689
> >>                    e-mail : [EMAIL PROTECTED]
> >>
> >>-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >
> 
> --
> -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
>      _____________
>     /____________/  Vincent Himpe
>    // _____  ___/   Lab Manager
>   / \ \   / /  /    ST Microelectronics
>  /___\ \ / /  /     5510 Six Forks Road . Suite 200
> /______//_/__/      Raleigh NC 27612
> 
>                     Tel : (919) 850 6070
>                     Fax : (919) 850 6689
>                     e-mail : [EMAIL PROTECTED]
> 
> -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-

-- 
___________________________________________________________________________
www.integratedcontrolsinc.com            Integrated Controls, Inc.    
   tel: 415-647-0480                        2851 21st Street          
      fax: 415-647-3003                        San Francisco, CA 94110

* * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
* To post a message: mailto:proteledaforum@;techservinc.com
*
* To leave this list visit:
* http://www.techservinc.com/protelusers/leave.html
*
* Contact the list manager:
* mailto:ForumAdministrator@;TechServInc.com
*
* 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