Incorrect wires added during breadboard layout

[daxliniere]

Current Behaviour

In the Breadboard view, on a stripboard, if you place a component that creates an unwanted connection, re-positioning that component doesn't remove the unwanted connection. That unwanted connection becomes a permanent feature and the only solution is to undo many, many steps or to delete 4-5 parts and re-do the schematic and breadboard layout.

I have even tried to convert the unwanted connection into a wire in the schematic view and then delete that wire, but the unwanted connection is left behind.

Build:
Version 0.9.4
(CD-498-0-a1ffcea 2019-12-01) 64 [Qt 5.12.3]

Operating System:
Windows 10

Steps to reproduce:
See above.

Expected Behaviour

See above.

[KjellMorgenstern]

Can you add a screenshot? On a stripboard, it should be possible to simply cut connections.

[daxliniere]

Hi Kjell,
I have captured a series of undo/redo 'states' which you can see below. Simply copy each one and go into Breadboard view and paste them.
Fritzing - everything good.txt
Fritzing - fault 1.txt
Fritzing - fault 2 - (skipped ahead several redo steps).txt
Fritzing - fault 3.txt
Fritzing - fault 4.txt

[KjellMorgenstern]

I loaded Fritzing - fault 1.fz
Could you mark where the problem is?

[KjellMorgenstern]

PS: Later on there are issues, which seem to be from resizing the board, looks like #3162 .

There is another issue about unwanted connections, maybe this is related? #3130

[daxliniere]

Hey Kjell, to answer your first question, the schematic view will show a problem. A dotted connection has been made where it shouldn't be.
(No idea why, but I can't seem to copy/paste the contents of those TXT files all of a sudden. ????)

Yes, it could be related to #3130 and yes, resizing the board also messed with the schematic.

Side question: Is there a way to delete these incorrect connections?

[daxliniere]

I'm not sure where to post this or even what to call it, but I had another issue. Once you've started editing in the Breadboard page, things start to get wacky in the schematic view, like there's no designated 'master'. I feel like the schematic view needs to have 'master status' over all other pages, since that is the core of every circuit.

For example, I just came across this problem: I wanted to disconnect the limit switches at the top of the schematic so I could connect them via a screw terminal block. As you'll see in the screencap, when I disconnected one of the wires, it was automatically 'replaced'. This is 'clever', but absolutely not wanted behaviour.
The only way to do it is to delete the part, but then I'd have to find it, recreate it, relabel it, rename it, move name label to correct position when all I want to do is disconnect it from the circuit.

[daxliniere]

CAUGHT ON CAMERA!
Also attached are before and after states.

Bug - before and after.zip

[daxliniere]

Sorry guys, but this is completely unusable. Look how the transistor pins are joined incorrectly and for absolutely no reason:

(The first attempt, the bug didn't occur. Around 0:19 I undo the move and place the transistor again. The second time, I got the error. This error could have something to do with where the dotted lines are routed/sorted before a component is placed, maybe??)

[daxliniere]

Also, shouldn't the colour of the dotted line on the Breadboard view match the Schematic view? It would make it a whole lot easier to tell where a short had occurred.

Thanks again, Kjell!

[mMerlin]

Deleting a wire should convert to a ratsnest line only if there is a wire/trace on another view for that connection. You can also delete that ratsnest line as a separate step, but beware of what connections might be in place on other views. It's not hard to get into crazy states across different views. I suggest finding the wire in the other view(s), and deleting them before deleting the ratsnest lines.

[vanepp]

It is best practice to make all your connections in one view (breadboard, schematic or pcb.) Once that is completed switch to the other views where rats nest lines will indicate the connections set in the completed view, and click on the rats nest line to create a wire and drag it to route it correctly. If you make a conflicting connection in another view, it is possible to corrupt the routing database (which may be a bug, or just how it works) in such a way that you can not recover. In that case the only thing you can do is start the sketch again. As to your text files above, you need to add a .zip to the end of the .fzz file as in Fritzing - everything good.fzz.zip so github will upload it. It looks to have only loaded the .fz file and not the associated svg files as a .txt

[KjellMorgenstern]

Deleting a wire or ratsnest line in breadboard or schematics view should not be possible if it is already routed on the PCB view. And the other way round, too. This avoids deleting a already routed connection by accident. It might make sense to add a hint if users try to delete such a connection. Please open a feature request for this if you agree.

Regarding the unwanted connection: I stil could not reproduce it from the first examples, but from the video it seems that a connection is created while hovering the part over the stripboard, before even setting it down. That indeed is a bug that should be fixed, as it makes striboards unusable/very difficult to use should it occur.
I think it is the bug we should focus on in this issue.

[vanepp]

"but from the video it seems that a connection is created while hovering the part over the stripboard, before even setting it down."

I am unsure that is what is happening here. It looks to me from the pictures that the routing database is corrupted by incorrect connections (getting complete copies of the fzz files would probably confirm that.) If so then the unwanted connections are caused by the routing corruption and will likely go away when it is fixed. I am unsure whether the corruption is a bug or an unavoidable consequence of an incorrect connection in another view causing a change that can't be reversed. I'm leaning towards a bug because I have an example where removing all connections in all views does not correct the routing database (from an example posted lately in the fritzing forums) which I think is incorrect.

[mMerlin]

@KjellMorgenstern Deleting a ratsnest line in one view when there is a matching routed connection in another view should not be possible for reasons mentioned. However, deleting a wire, which then reverts to a ratsnest line should be possible. If editing/routing the wire/trace gets messed up bad enough, it is a lot easier to just delete it, and start that particular wire/trace over again. Especially when overlapping wire/parts make selection of the pesky extra bend point all but impossible. Even with simplification by reducing the number of displayed layers. Sometimes, move to front/back can help, but often delete and recreate more carefully is easier.

[KjellMorgenstern]

In order to resolve this issue I must find a way to reproduce it.

I agree with @vanepp that uploading the fzp of a faulty project (and annotating again what is the fault) is worth a try.

Otherwise I will have to close this issue unresolved, as there are just to many use cases and uncertainties, maybe even multiple different issues, mixed into this. Chances of isolating the issue and thus fixing it seem dim.

[KjellMorgenstern]

Update: I overlooked the file "Bug - before and after.zip" . With that file I could now reproduce creating a short over the resistors. This is however not a bug: R2 is connected to Q2 and pin3 of J1.
Anode of D1 is connected to pin3, too.
When you put D1 on the stripboard, you create a connection of the D1 anode to Q2. Now anode D1 is connected to both Q2 and pin3, and you have a short over R2.

So, I still can not reproduce the issue of "incorrect wires added during breadboard layout" :-/

[KjellMorgenstern]

In regards of deleting the ratsnest line over R2: Right click and choose "delete ratsnest line" worked for me, both in Breadboard and schematics view.
Limiting the displayed layers via Menu -> View might make sense, too, depending on your style of working.

[vanepp]

I agree this isn't a bug but operator error (having also overlooked "Bug - before and after.zip".) You have correctly completed schematic before starting on breadboard, now however your best bet is to click and drag on a rats nest line in breadboard which will create a wire to where it should connect. In the case of D1 that is one row down from where it is connected in breadboard to connect to the strip that is shorted to the terminal block connection As well I would change the short between the two rows at the screw connector to a wire like this to make the connection more obvious. as it will be wired in real life (note the resistor had to move one position left to allow for the connection of the diode as well):

Your problem here is that breadboard connections reflect back in to schematic, so an incorrect connection in breadboard will create rats nest lines in schematic and if you then click on the new rats nest line in schematic, in some cases corrupt the routing database in such a way that the only solution is to restart by clearing all connections. I don't think there is a bug here. I would also make a cut in the strip board just after the anode of D1 to avoid making an unwanted connection to the rest of that strip elsewhere on the board that I didn't do here. If you see an unexpected rats nest line, check the other 2 views for an error.

[KjellMorgenstern]

@vanepp "...and if you then click on the new rats nest line in schematic, in some cases corrupt the routing database in such a way that the only solution is to restart by clearing all connections."

Do you have an example for this? Database corruption would indeed be a bug, but I did not yet see it happening here. Or did you mean #3580 ?

[vanepp]

@KjellMorgenstern Unfortunately not that I can reproducible dependably. The fzz in #3615 initially showed this behavior, deleting all wires in all views then redoing breadboard initially added spurious rats nest lines which is the sign of data base corruption. Now however starting from the original fzz (and not making the error in 3615, although I don't think that is involved) I can't get the spurious rats nest line to appear again. There have been a handful of cases of this over the yeas in the forums and our usual advise has been to start fresh and don' repeat the mistake. I have never been sure if the cause is a bug, or the fact that incorrectly shorting two nets is not reversible, it may be either. I was hoping to start from the fzz in 3615, delete all the errors in schematic and then re introduce them to be able to reproduce the failure from the start so we can see what happens, but so far haven't even been able to reproduce the problem on the original file except for the first time (which may have something to do with the order that I did things in or I may have missed a wire.) I'll keep poking, because if it is a bug it would be a good one to fix, and knowing how it occurs we may find another cure.

[daxliniere]

Hey Vanepp, thank you for looking into this as well.

It is best practice to make all your connections in one view (breadboard, schematic or pcb.)

Yes, I'm aware of this and that's exactly what I was trying to do. In fact, I think it should be possible to 'lock' a circuit from being able to be modified in a secondary view. (This is essentially being able to set a 'master editor view' as I suggested earlier).

[daxliniere]

@vanepp that bridged track was well-spotted. I have to admit, that wasn't a connection I had intended to make. I have found it all too easy to accidentally make bridged connections on the stripboard.
Is there a way we can change that UI? Perhaps you have to CTRL+click in order to bridge and cut the strips? That would help a lot.

But yes, I had situations where the corruption happened, I would undo several steps, move one of the components sitting off the stripboard and try again and it worked.

[daxliniere]

At the very least, can we get an alternate stripboard layout with high contrast colours, please? Flat, non-shiny copper on phenolic board doesn't really have much contrast.

[vanepp]

@daxliniere "In fact, I think it should be possible to 'lock' a circuit from being able to be modified in a secondary view. (This is essentially being able to set a 'master editor view' as I suggested earlier)."

Unfortunately that isn't likely to be easy to do. The code is set up to reflect changes in one view in to the other two views, and selectively stopping that may not be easy. It may be possible to cause a dialog box to appear if a change in a view is different than a current rats nest line, requiring confirmation that the change is intended but I'm not sure how easy that would be either. The code is complex and changes may have unanticipated results.

"Is there a way we can change that UI? Perhaps you have to CTRL+click in order to bridge and cut the strips? That would help a lot."

Yes almost anything can be done. The problem has been finding someone capable and willing to do the work. Development has stopped for so long that no one is even making pull requests any more (I think around a dozen got included in the 0.9.4 release over the 4 years from the last release. The hope is with increased donations to be able to hire professional developers to move forwards (the code base is too complex for amateurs to deal with easily.) To that end you should likely file enhancement requests for the features you want added. No guarantee they will make it in, but they can be up voted by folks here (al;though I'm not clear on how you do that) to indicate interest. If there is a lot of interest in an enhancement it presumably will get priority.

"At the very least, can we get an alternate stripboard layout with high contrast colours, please? Flat, non-shiny copper on phenolic board doesn't really have much contrast."

While again an enhancement, this one should be relatively easy, just change the colors in the source (or better yet, make them user settable from the UI, more work but more flexible too.)

" that bridged track was well-spotted. I have to admit, that wasn't a connection I had intended to make. I have found it all too easy to accidentally make bridged connections on the stripboard."

That one was fairly east to find. All I did was drag D1 off the strip board like this:

and then look where the rats nest lines go. In this case that indicated the diode was connected to the wrong end of the resistor (causing a short in schematic.) I had assumed the jumper was intentional (although in the real world would need to be a wire as perf board won't do the jumper, because the diode won't fit directly between the resistor and the strip it wants to connect to and you thus need to wire to another strip to provide the needed distance, or use a top view diode which will fit in a .1in pair of holes (I think I or someone else made one some time back, it should be in the forums). Probably again a change to the UI to allow the user to select whether or not the jumper can be done is probably the answer (I think the intention for the jumper is to create custom perf board layouts, rather than to serve as a jumper.) There are likely to be people who want the current method to still work and making the new behavior user setable with the current the default is probably the best way forward. As well you can click on a strip (or any connection) and it will light up everything connected to that in yellow which would also have indicated that connection.

[KjellMorgenstern]

I think the original issue is resolved (better: explained) as good as possible. I'd suggest to close this issue. If you want, please open new issues for the findings made during this discussion.