X-Authentication-Warning: delorie.com: mail set sender to geda-user-bounces using -f X-Recipient: geda-user AT delorie DOT com X-Virus-Scanned: amavisd-new at neurotica.com Message-ID: <4F5DCE76.1060304@neurotica.com> Date: Mon, 12 Mar 2012 06:22:46 -0400 From: Dave McGuire User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.27) Gecko/20120216 Thunderbird/3.1.19 MIME-Version: 1.0 To: geda-user AT delorie DOT com Subject: [geda-user] Very confused...possible PCB bug? Need help. Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Reply-To: geda-user AT delorie DOT com Ok, I hate to ask this, for the obvious reason...but I wonder if I've found a bizarre bug in PCB. I could really use a hand with this one. This is with the 20110918 snapshot. I'm using the standard flow of gschem -> gsch2pcb -> pcb. Here's what's going on. I'm working on a small two-sided board, mostly surface mount. It's very close to done, but the message log keeps telling me that the +3.3V net is shorted to the GND net, and vice-versa. But I've been going over this for a solid day (a 14 hour day in fact!) and I cannot find this short! I don't know when this supposed short crept in, as I generally don't keep the message log open as I'm routing. When I hit "o", a via and a pin of a connector are highlighted in orange. They both have thermals to the to board-sized rectangle (I have board-spanning rectangles for 3.3V and GND on the top and bottom) but I've gone over them very carefully and they don't seem to be in play. Now here's where things get weird...which vias and pins are highlighted in orange are not consistent! If I delete the connector whose pin gets highlighted, then hit "o" again, of course I'll get all sorts of "not found" messages in the log due to the missing connector, but a DIFFERENT pin on a different connector then gets highlighted in orange. If I delete the GND and 3.3V planes, the supposed short remains. If I delete all connections to the orange-highlighted pins, that doesn't get rid of it either. I've looked at it a zillion different ways and tried a zillion different things (looked for hidden pieces of former traces lying around, etc) and nothing has gotten me past this. It's worth mentioning that I've designed about five boards with this flow on this exact set of software, on this system, with no changes save for a few added symbols and footprints. All the way to copper deployed in the field, no problems whatsoever. This stuff works great, as always. Until this weird situation. Are there any known conditions in which PCB might think that two nets are shorted when they actually aren't? Does anyone have any suggestions as to how I might chase this? -Dave -- Dave McGuire, AK4HZ New Kensington, PA