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 * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
