Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Duplicating a net label in schematic view causes phantom ratsnest connections to appear. Cannot be deleted either. #3340

Closed
NormanDunbar opened this issue Jun 4, 2017 · 13 comments
Milestone

Comments

@NormanDunbar
Copy link

Description

When I add a net label to the schematic view, give it a name etc, then duplicate it, edit the name and move it elsewhere, there are no rogue connections between the two labels in schematic view (as seen if I click and hold the "connector" in one of them) but on the breadboard and PCB views, there are now new ratsnest lines between the two points where the labels are, clicking on one end of the resistor "lights up" the other end.

Project showing problem

I have attached a simple project showing the problem described above with a single resistor and two net labels. It is called NetLabelPossibleBug.fzz.zip - you will simply need to drop off the .zip extension, GitHub doesn't cope with *.fzz files, so I had to give it an additional extension that GitHub liked!

NetLabelPossibleBug.fzz.zip

Fritzing Version

0.3.9 Beta.

Steps to reproduce

  • Start a new project.
  • On Schematic view, add a resistor, for example.
  • Add a net label, and name it D1, for example.
  • Duplicate it and name it F2, for example.
  • Connect D1 to one end of the resistor.
  • Connect F2 to the other end.
  • Switch to either Breadboard or PCB view and notice a ratsnest line connecting both ends of the resistor.

This is the simplest way to reproduce, I discovered the problem when I duplicated a 5 pin female header connected to D0,D1, D2, D3,D4 on an ATMEGA328 and with net labels on each of the 5 pins, to a 6 pin for the A0 through A5 pins. On the breadboard and PCB views, I had ratsnest lines connecting D0 to A0, D1 to A1 ... D4 to A4.

I suspect that the problem is caused when the duplication takes place, the internal "I am connected to this point" data of the source net label is not cleared out when duplicated as the second one??? (Just guessing!)

Kind regards,
Norman.

@NormanDunbar
Copy link
Author

NormanDunbar commented Jun 4, 2017

Of course, this might be the expected behaviour in that net labels behave slightly differently from other components when duplicated in this way.

I often duplicate resistors, capacitors etc with no problems, and change names and/or values and I thought that net labels would be similar. However,if I had given it some thought, duplicating a net label should indeed 'connect' both labels. (Although they should disconnect if the name or label text is edited.)

The only problem is that you don't see this connection on the schematic diagram, only on the other two views.

Cheers,
Norm.

@KjellMorgenstern
Copy link
Member

Indeed, that might be a feature. However, when renaming, I think either: The connection should be removed. Or both labels should be renamed ?

@NormanDunbar
Copy link
Author

I would go for removing the connection as the best option when a duplicated net label is renamed.

Cheers.
Norm.

@btb
Copy link

btb commented Oct 29, 2020

I'd say this really is a bug, not an enhancement request.
Workaround is to cut (onto the clipboard) the net labels (along with whatever they're attached to) and paste, then they will no longer be linked.
If the existing behavior was a feature then this workaround would be the bug.

@failiz
Copy link
Contributor

failiz commented Oct 29, 2020

I would say that the connection should be removed once the duplicated net label is renamed. The issue #1326 is related to this: how to handle schematic only components.

@jcalcote
Copy link

jcalcote commented Nov 30, 2020

I do this sort of thing for a hobby and I have limited "hobby time" that I steal from my "family time". Therefore the first thing I do when I discover a new application is look for power-user tricks that help me become more productive. The duplicate (ctrl-d) function is an incredible time saver because - in this case - you can create a port, flip it, change the label, and then duplicate it for all the pins down the left side of a microcontroller. Much faster than dragging out a new one from the tool box and flipping it.

However, I recently ran into this bug - and it truly is a bug - no one expects a renamed port to remain invisibly connected to the source port. The fact that it makes complete sense to the developer means nothing to a user. They expect the software to operate in a sane manner.

I can confirm that the problem still exists in 0.9.4b. I'm a software developer myself and wouldn't mind helping out. If I cloned the repo and worked on a fix for this, would anyone be interested in a PR?

@KjellMorgenstern
Copy link
Member

KjellMorgenstern commented Nov 30, 2020

A pull request would be welcome.
However, i think that it is common, that in the schematic view, labels have a specific meaning (not only in Fritzing)

If two labels are equal, they are connected. So, the ratsnest line in PCB and breadboard view is correct.

Before starting to code a new behavior, it must be clear how that behavior should change.

  1. How to better indicate that equal labels are connected.
    Suggestion1: Highlight connected labels on mouse button down. Suggestion2: Auto-Colorize labels. Could also apply both behaviors, allow auto color to be turned off. Suggestion3: Show a line between connected labels when a label is in focus

  2. How to make it clear/explicit when such a connection is created?
    Suggestion1: When a label is renamed, check if equal labels exist, and create the connection. Break the connection if one of equal labels is renamed.
    Suggestion2: If the connection is already routed in one of the views, we can not delete the ratsnest anymore. In that case, editing one label should rename the other labels, too (current behavior)

  3. I think you could even argue, that a label without a corresponding equal label is 'dangling'. When reading a schematic view, wouldn't you search for the counterpart of such a label?
    Suggestion1: Highlight and warn about dangling labels.

@jcalcote
Copy link

jcalcote commented Nov 30, 2020

@KjellMorgenstern - thank you for the clear picture of the problem space. These are all great ideas, However, I’m not sure you understand the actual bug. It’s easily reproduced with the following steps. Please try it out:

  1. New sketch, schematic view
  2. Add any component (A)
  3. Add a net-label to one of the component’s pins and give it any name; connect it to the pin.
  4. Add another component (B)
  5. Add another net-label to a pin of component B and name it the same as the first net-label so they belong to the same net; connect it to the pin.

At this point I think you’ll agree that there should be a ratsnest line between the two pins in the pcb view.

  1. Select the net-label on A and press ctrl-d to duplicate it
  2. Rename the new net-label so it’s part of a new net
  3. Place it on any unused pin and connect it to the pin.

There are now logically two distinct nets in the sketch but if you switch to the pcb view, you’ll note that there is only one net from Fritzing’s perspective, as all of the pins with ports are now tied together with ratsnest lines.

The only way to fix this is to delete the duplicated net-label and recreate it manually, instead of using the duplicate feature.

The fix for this bug is to ensure that duplicated net-labels, when renamed, drop their ties to the source label’s net. It’s as simple as that, I believe.

John

@KjellMorgenstern
Copy link
Member

@jcalcote Thanks for clearing this up. I agree this is a bug.

The problem even persist if you exchange step 7 and 8. If you
7b Place it on any unused pin and connect it to the pin.
8b Rename the new port so it’s part of a new net
Then the connection and ratsnest lines disappear. However
9 Connect the new port again. It sill is in the same net as the first port.
So, the port / net label remembers the net it was connected to once.

The new behavior (the fix):
A net label should forget about the net if the label is changed.

Not part of a fix:
Renaming a net was never a feature. It could be added, but
this is not in the scope of this issue. When used, changing
the label would rename all labels in the same net. I think this
is an edge case rarely needed.

@jcalcote
Copy link

jcalcote commented Dec 1, 2020

@KjellMorgenstern - I downloaded the source and built Fritzing. I read the developer section of the wiki. I've spent several hours today in QTCreator using gdb to walk through various code paths. The problem is I just don't have enough background in the data model to determine how an original net label and a duplicate are incorrectly connected after a duplication command.

I'm requesting someone with a bit more experience please look into this issue, if such a person can spare the time.

@bobwolff68
Copy link

I just wanted to re-enforce two items:
a) The only way a designer knows that a net is connected is either by a wire or by seeing an identical label in two places on a schematic. Renaming a label but keeping it (in a hidden way) connected to the prior name is not only a bug but really a schematic sin! :)
b) Someone noted that a dangling label (no corresponding same label elsewhere) might be a problem - and while I think the color coding of dangling labels is kinda nice, there is a real use case for such dangling labels. There are times in a schematic where a circuit isn't super obvious as to what it's purpose is. A dangling net label can be very helpful by giving an opportunity to have a name literally attached to the connection with a name.

I think you've already landed squarely in calling it a bug, but wanted to put my 2 cents in as an old designer. FWIW, this bug nailed me for a couple hours' worth of re-work today and in just trying to figure out what the heck was going on when my breadboard and pcb were looking totally screwy.

@failiz
Copy link
Contributor

failiz commented Jun 14, 2021

This is a duplicate of #2308. I would close this one and leave #2308 open as #2308 is more concise.

failiz added a commit to failiz/fritzing-app that referenced this issue Jun 16, 2021
@failiz
Copy link
Contributor

failiz commented Jun 16, 2021

I think I got a fix for this bug. @jcalcote (and others), if you are able to build Fritzing, it would be very nice if you can test this fix.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

6 participants