Spurious unrouted connections in BB view


#1

Steps I took that resulted in the problem:

Started Fritzing.
Switch to BB view
Added Arduino Uno
Added two ceramic capacitors
Plugged first capacitor into two unconnected locations on the board - status bar says: no connections to route
Plugged second capacitor into pin 8 and 9 of Arduino headers - 0 of 2 nets routed - two connections still to be routed
Removed second capacitor and dragged wires from arduino 8 and 9 to capacitor - routing completed.

What I expected should have happened instead:

routing completed or nothing to route in all cases.

My version of Fritzing and my operating system:

Windows 10 Pro 1607 14292.693
Version 0.9.3 (b5c895d327c44a3114e5fcc9d8260daf0cbb52806 2016-04-19) 64 [Qt 5.6.0]

Please also attach any files that help explaining this problem


4 out of 5 nets routed
#2

What do you mean. If you want to plug a cap into the UNO directly you have to grab the bendable legs and pull it to the header, because it doesn’t snap to some of the headers.


#3

Both just dragging and dropping the part and dragging the bendable legs seem to fail - you get the ‘green light’ but status still shows unrouted connections.


#4

Oh yeah, the status goes weired. I’ve got 4 green dots and it says 0 of 4 nets routed.


#5

But if you use wires it works fine. I want to create jumper plugs to insert into Arduino (and other) headers, but currently you get these routing funnies. It works fine with a plain breadboard.


#6

I just checked PCB view and it says 2 of 6 nets routed. After I made the 4 ratsnests solid traces, it says Routing completed.

I went to BB and put actual wires in instead of direct connections, and it said Routing completed.


#7

As far as wires in breadboard view go this was my finding also. Doing that makes a mess of breadboard view though. Unfortunately, I do not understand the routing algorithms well enough to say what the different views should do. At a superficial level, it seems to me that if you stick a male connector in female connector, it should count that as fully connected, but there may be reasons that is bad.


#8

I think its because of breadboard (which has female connectors). Connecting to breadboard without another connection doesn’t do anything so routing isn’t complete, its when a male connector is also connected to breadboard that routing will complete I think. The female connector is only being a conduit for the connection, it needs a male connection in the path to compete I think.

Peter


#9

Not sure; the breadboard itself works fine - it comes up with ‘no connections to route’ if you plug in the legs into unconnected holes; I suspect there is some magic code in there to ignore such connections. I will have to look at the code - I just know I’ll get lost when I do. I’ve been programming in C++ for over 25 years, but I still find other people’s code very difficult to read at times.


#10

To avoid trying to decipher the code, I tried old versions - this has been a bug since as far back as at least 0.8.2b :frowning:


#11

Have you (or anyone else willing to admit to it :slight_smile: ) compiled the latest source tree to try and see if any of these are fixed? I’m intending to try that once I finish getting a script together to post process Inkscape svgs. On that front I just gave up on perl and moved to python (first because I see python is the language of choice in Fritzing, but now I’m in love with lxml :slight_smile: ). In a couple of days and half the code I’m as far as I was in perl in weeks. I’m aiming for a script that will take a fpz file (in either unzipped or Fritzing directory formats). check that everything (files and connectors) declared in the fpz exists (for the case of files) or exists (for connectors) in the svgs and replaces style and inheritance in the xml (neither of which Fritzing likes in certain circumstances) and removes the trailing px from font-size commands.

Peter


#12

Sounds like you’ve made a real breakthrough on the scripts - which is fantastic.
No, I’ve not compiled yet. I doubt very much given the number of commits we are seeing currently, that there is a fix just happening to be in there.
I have traced a related issue back to August 2012 - https://github.com/fritzing/fritzing-app/issues/1953 which was fixed for breadboards, but I think female headers got overlooked, possibly because they didn’t connect at all in those days. Unfortunately I cannot check the source. When the dev team imported the source they left out the history. The svn may still be on googlecode but if it is it’s behind an impenetrable redirect.